Memcached大量数据缓存策略探讨使用Memcached。需求是这样的：系统需要把大量的关键常用数据（十万条以上，在
Memcached大量数据缓存策略探讨
使用Memcached。需求是这样的：系统需要把大量的关键常用数据（十万条以上，在不断增长中）放到缓存中，为提高程序执行效率。那么这些数据在缓存中的存储方式是怎样的时候，效率最高？站在目前的缓存工具角度来想，假设要缓存的数据为手机的订阅关系，可以有下面两种做法：
一，在缓存中建一个Cache,键为subsription，值则是一个大哈希表，哈希表存放所有的数据，以唯一的手机做Key，相关订阅信息做Value。
如此要查询一个手机的订阅数据，要先从Cached里拿到到key为subscription的缓存，这是个大哈希表，然后再从哈希表里按手机拿出订阅信息：
Map datas = memcached.get("subscription");Subsciption s = datas.get(mobile);这样的缺点就是查询客户端会从Memcached的Server拿到一个巨大的Map。不仅网络开销大，并且客户端也要开辟大块内存来存放这个临时的Map。
二，每一个订阅关系作为一个缓存实体放到Memcached中。那就意味着查询极为方便：
Subscription sub = memcached.get(mobile);
但是在Memcached里就会有几十万个缓存实体了，不知道是否会给查询带来速度上的影响。另一个不便的地方就是从缓存里拿不到订阅关系的总数（当然这个需求显得很鸡肋）。
下面是我自己的一些幻想。假如我按照做法一来存放数据。查询能这样就好了：
Subscription sub = memcached.get(“subscription#” + mobile);
不需要担心服务器端给客户端返回一个大Map，又占用客户端巨大的内存资源。所有的嵌套查找工作交给服务器去做，最后返回我想要的订阅关系即可。当然，我依然可以使用get("subscription")拿回一个大Map。
不过看起来我这样的想法应该是有点不实际。更多的是我想请教下大家，在大数量缓存的情况下，大家会使用什么样的缓存策略？毕竟做了电信两年多了, 处理几千万的手机号相关的数据时, 这是一个很常规的方法.
不过也许确实 用在缓存里有些多于 毕竟缓存里的数据不会太多
风往北吹在扯淡, 我是吃饱了撑着没事干
那您的高见是????
9 楼 fins 2007-06-27 lz
"查询客户端会从Memcached的Server拿到一个巨大的Map。不仅网络开销大，并且客户端也要开辟大块内存来存放这个临时的Map"
这里的客户端是指什么???? 不是浏览器吧??
还有 我没明白这个和网络开销有什么关系
Memcached的Server端直接取得最终要查询的数据,然后传给客户端就可以了啊,没理解你的具体的场景 10 楼 我想我是海 2007-06-27 @ fins
客户端是指Memcached Client。
如果按照第一种做法，Client会从Server端拿回一个大Map，然后从Map里面拿自己想要的数据。这时候要从Server那边反序列化出一个Map对象，并且此对象是相当巨大的。
BTW：这种需求的确跟命中率没关系的。 11 楼 fins 2007-06-27 Client会从Server端拿回一个大Map
那为什么不在 Server端 就对大Map进行筛选 只把客户端需要的传过去呢?
12 楼 我想我是海 2007-06-27 请看看我贴子里下面一段关于我的幻想。跟你问的是一样的。
我说的Server端是指Memcached Server。假如它本来就有这样的功能那就好了。实际上不是。我们需要通过Client API拿到Map再进行筛选。在通过Client API获得MAP的时候，网络传输、占用内存的情况就自然出现了。:)
除非Memcached加入支持嵌套查询的代码。不过使用做法二就不需要考虑这样的情形了。也罢。
