Holding Collections in memcache

A better way to deal with this kind of thing is with a two-phase fetch. So
instead of directly caching an array of event data, instead cache an array
of event IDs. Query that list, then use it construct a list of the keys of
individual event objects you want to fetch, then multi-get that list of
keys.

In addition to greatly increasing the maximum size of the list (memcached
has a 1-megabyte hard limit on item size, and obviously you can fit a lot
more IDs than full data in that limit) you will also, if you're using
multiple memcached servers, spread the load around by virtue of your
multi-get hitting basically every server once your key list is a certain
size. If you stick all the data in one frequently-requested item, then you
will pound the particular server that happened to get that item while all
the others sit idle.

Another advantage of a scheme like this is that you can update an item's
data without having to read then write every list that contains that item.
Just update it by ID (like you'd do in your database queries) and all the
lists that contain it will magically get the correct information.

All the above said, it is true that dealing with lists of things is not
currently memcached's strong suit. For example, there is no "append"
operation. It is much better at caching individual objects.

-Steve
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值