探讨 - 缓存存储方案:mysql vs memcached

2014-01-06 20:16:12 +08:00
 Tianpu
key使用md5特征字符串

方案一:
使用mysql:

CREATE TABLE IF NOT EXISTS `keys` (
`key` varchar(32) NOT NULL,
`time` int(12) NOT NULL,
UNIQUE KEY `key` (`key`),
KEY `time` (`time`)
) ENGINE=MyISAM;

CREATE TABLE IF NOT EXISTS `tmp0` (
`key` varchar(32) NOT NULL,
`value` blob NOT NULL,
`time` int(12) unsigned NOT NULL,
KEY `key` (`key`)
) ENGINE=MyISAM;

.... tmp1 -> tmpf;

一共17个表

逻辑上这么处理

key的首字符用来分表到 tmp0 -> tmpf

添加数据:添加key和有效时间到keys表;添加key value 有效时间到tmp0-f的数据表
读取数据:根据key直接从tmp*读取数据 做下有效时间判断 过期则删除缓存
过期处理:使用计划任务从keys表读取过期数据索引 批量删除


方案二:

使用memcached

添加数据:添加key value 过期时间到memcached
读取数据:根据key从memcached直接读取数据
过期处理:memcached自动维护


我想问的是方案一有什么明显的缺陷吗? 跟方案二相比 系统瓶颈在哪里?

如果1000万数据缓存的话 单挑数据压缩后3K 方案一索引大小是32*10000000/16=20M 也不会卡的 方案二如果有优势在哪里?

我想到的可能是内存读取速度比硬盘快 那如果SSD做RAID10 使用内存的memcached还有优势吗?

实际测试中 方案一速度是0.0008 方案二是0.0004

不考虑非常海量的并发
4800 次点击
所在节点    程序员
24 条回复
lecher
2014-01-07 13:16:05 +08:00
@likuku
memcached 有个日本人作的版本,支持两台memcached双向自动同步,假若一台坏掉,之后恢复运作会自动从活着的那台抓回数据复活。

这个插件有个坑都在网络连接上面:
一个是网络连接传输过程如果阻塞了,会一直挂起.

局域网可能不容易被坑到,但是如果服务器负载太高,可能会踩到第一个坑.
远程的话,要评估一下数据一致性的要求有多高了.
Tianpu
2014-01-07 13:26:38 +08:00
@likuku 负载基本0.01的单机 我就是想页面渲染速度更快点 php脚本都在内存里了 想了想也就数据库读取慢 所以就全部尽量所有进入内存了

远程的话仅仅持久化一点 就首选Mysql了 redis的持久化貌似容易有坑?比如同步到磁盘的时候是不是会一顿一卡的?

memcacedb挺好的 就是太持久了 不能自动过期 缓存对象太多 担心性能有下降或者占用磁盘太多

比较好的方式 觉得是使用memcachedb做持久化,同时维护一个Key表 手工清理过期缓存 这样子坏处是系统太复杂了
Ever
2014-01-10 14:58:24 +08:00
@mahone3297 innodb_file_format=barracuda, 适合有变长大blob字段的row

@Tianpu 你要带持久化的memcached, 可以用tokyo tyrant或者kyoto cabinet, 都支持memcached协议。
Tianpu
2014-01-19 02:04:17 +08:00
更新下,某个对于时间要求不高的mysql缓存的统计信息,差不多10天了:

Cache:
keys 2781521
tmp0 173826
tmp1 174125
tmp2 174395
tmp3 173631
tmp4 173336
tmp5 174308
tmp6 174062
tmp7 173443
tmp8 173672
tmp9 173556
tmpa 174011
tmpb 173744
tmpc 173170
tmpd 173886
tmpe 173940
tmpf 174416
offset 0

缓存失败,如写keys、写缓存、或者两个一起失败,差不多有500来次,比例可以接受

目前仍旧是飞速,占用数据库7G了,刚把过期时间改成32天,预计最终稳定态是占用20多G数据库,到时候继续更新看看是不是还能稳定运行。

keys索引有100多M了 的确是个瓶颈 在考虑keys表是不是只做时间的索引 放弃一致性 然后随机读取 随机删除过期的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/95901

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX