关于memcache的key的管理,徘徊中

张映 发表于 2010-05-05

分类目录: cache, nosql, php

标签:, ,

一,在说出我的困惑时,先罗嗦一下memcache

memcache是一个高性能的分布式的内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。Memcache是danga.com的一个项目,最早是为 LiveJournal 服务的,最初为了加速 LiveJournal 访问速度而开发的,后来被很多大型的网站采用。目前全世界不少人使用这个缓存项目来构建自己大负载的网站,来分担数据库的压力。起初作者编写它可能是为了提高动态网页应用,为了减轻数据库检索的压力,来做的这个缓存系统。它的缓存是一种分布式的,也就是可以允许不同主机上的多个用户同时访问这个缓存系统, 这种方法不仅解决了共享内存只能是单机的弊端,同时也解决了数据库检索的压力,最大的优点是提高了访问获取数据的速度!基于memcache作者对分布式 cache的理解和解决方案。 memcache完全可以用到其他地方 比如分布式数据库, 分布式计算等领域。

二,memcahce的key如何关理,更合适

 

大家都知道,memcache缓存的数据放在内存中,用的key=>value的方式,来查找和更新value的值,从这里可以看出对于key的管理直接影响到value的值,影响到内存的利用率和效率,以及程序员写代码的难度,怎么样才做到最优化呢,这也是我一直思考的问题,我想了二种方案,但是觉得都不完美。先说一说我的方案吧

1,对单表进行缓存

优点:

a,对于key的维护很简单

key对应一张表的数据,所以key是根这张表有关的sql或者其他。如果是我,我会用取整表的sql语句经过hash后来当key。注意一点hash过程中,如果sql有一点点不同,hash出来就会不同,包括空格,字母大小字等。所以建议将sql建行封装。

b,就同一张表来说,内存中不会有重复数据

缺点:

a,加大程度开发难度

举个例子来说,如果我想对二张表或者更多表,进行联合查寻时,正常情况,我可以用left join或者其他来进行查寻就行了,也许一个sql语句就能搞定,但是现在对单表进行缓存时,就要把单表的数据取出来,用php的循环进行查找数据了。这样对于程序员来说是一件很痛苦的事。

b,加大系统负担,影响memcache效果

这个缺点很明显,因为多表操作时,用php的循环套循环,会加大系统负担,如果一张表有几百M, 另一张表也有几十M,你用php循环来把你想要的数据找到时,所花的时间也许比直接用联合查寻访问数据库所用的时间更长,这样我就没必要用memcache,这个也是致命缺点。

个人觉得这种对key进行管理的方式,比较适合写入,或者更新操作比较多的网页,因为对于key的update很容易,key根表名是一一对应关系,这样找起来就容易多了。

2,对数据段,数据点进行缓存

优点:

a,查找效率高

我想memcache设计的目的也就是这个了,通过key找到value,就是我们所要的数据,不要进行任何处理。不要对数据库进行操作,不要用php循环来取数据,可以说省了很多事情。

b,开发效率高

对于程序员来说,以前是怎么开发现在还怎么开发,就当memcache不存在就行了。

缺点:

a,内存利用率差

举个例子来说吧,数据段A和数据B有重复数据,内存中的二个数据段都会包括相同的数据,这对内存利用率来说是不好的。如果你的memcach所占内存是1G的话,并且你用这种方法来进行key的管理的话,1G内存中重复数据有可能占了一半。

b ,key的管理难

为什么对key的管理难呢,因为key受很多因素的影响。不像上面的那种方法,key和表名是一对一关系。在这里,key受表名,可能是多个表名,where后面所带的参数所影响,所以管理起来相当的不方便。当你更新一个数据时,入库的同时,key对应的value就要相应的改动,不然用户会认为网站有bug。根这张表有关系的key很多,很有可能你就没有把所有key对应的value都更新掉

个人觉得这种对key的管理方式比较适合,读取比较多的,写入比较少的网站,如果经常写入的话,更新key所耗的资源也很大,不如用上面的那一种对key的管理方式。

如果读取比较大,写入也比较频繁呢,怎么办呢,个人觉得这二种方法都不合适,如果非要做个选择的话,我会选择第二种,有没有别的方法来,综合上面二种方法的优点,去除上面二种方法的缺点的方法呢。思考中



转载请注明
作者:海底苍鹰
地址:http://blog.51yip.com/php/729.html

6 条评论

  1. kimi 留言

    可以考虑一些介于sql和nosql之间的一些开源数据库,比如说:cassandra、mongodb等,比单纯的key-value要强一些,能作一些关联查询。

  2. 张映 留言

    nosql还不成熟,观望中

  3. lgsiban 留言

    web2.0的时代, 绝大多数网站都是用户参与产生内容的, 基本上都是读取比较大,写入也比较频繁.

    你所提到的两个方案我曾经也考虑过, 最终选择了第二种. 但是最大的问题就是你也提到的"KEY管理难", 始终没有很好的解决. 不知道现在LZ有没有更成熟的想法

  4. 王国清 留言

    memcache一个key只能存1m的数据,怎么能整表缓存呢?把表分成小于1m的数据段,然后再保存,倒是可以。

  5. 张映 留言

    1M是默认的最大存储大小。

  6. 暗影 留言

    能不能只针对表中的一条记录来设计key呢?比如 user表, key 就是 user_id