Memcached大量数据缓存策略探讨

cfb336

使用Memcached。需求是这样的：系统需要把大量的关键常用数据（十万条以上，在不断增长中）放到缓存中，为提高程序执行效率。那么这些数据在缓存中的存储方式是怎样的时候，效率最高？站在目前的缓存工具角度来想，假设要缓存的数据为手机的订阅关系，可以有下面两种做法：
一，在缓存中建一个Cache,键为subsription，值则是一个大哈希表，哈希表存放所有的数据，以唯一的手机做Key，相关订阅信息做Value。
如此要查询一个手机的订阅数据，要先从Cached里拿到到key为subscription的缓存，这是个大哈希表，然后再从哈希表里按手机拿出订阅信息：
Java代码

Map datas = memcached.get("subscription");  

Subsciption s = datas.get(mobile);  Map datas = memcached.get("subscription");
Subsciption s = datas.get(mobile);
这样的缺点就是查询客户端会从Memcached的Server拿到一个巨大的Map。不仅网络开销大，并且客户端也要开辟大块内存来存放这个临时的Map。
二，每一个订阅关系作为一个缓存实体放到Memcached中。那就意味着查询极为方便：
Java代码

Subscription sub = memcached.get(mobile);  Subscription sub = memcached.get(mobile);
但是在Memcached里就会有几十万个缓存实体了，不知道是否会给查询带来速度上的影响。另一个不便的地方就是从缓存里拿不到订阅关系的总数（当然这个需求显得很鸡肋）。
下面是我自己的一些幻想。假如我按照做法一来存放数据。查询能这样就好了：
Java代码

Subscription sub = memcached.get(“subscription#” + mobile);  Subscription sub = memcached.get(“subscription#” + mobile);
不需要担心服务器端给客户端返回一个大Map，又占用客户端巨大的内存资源。所有的嵌套查找工作交给服务器去做，最后返回我想要的订阅关系即可。当然，我依然可以使用get("subscription")拿回一个大Map。
我的意思是类似分治
从10万个对象中 挑出一个快, 还是 把10万个分类,然后从每类里取快呢
可能我确实是"吃包了撑着没事干",我只是对 "手机号码" 这个比较敏感
毕竟做了电信两年多了, 处理几千万的手机号相关的数据时, 这是一个很常规的方法.
不过也许确实 用在缓存里有些多于 毕竟缓存里的数据不会太多
如果数据量很大的话 也可以对手机号进行分类
例如 按前三位 做多个缓存
133 130 131 135 138 139 158..... 其他
或者按奇偶分
这样也可以提高一些命中率


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/18883/showart_1080496.html