Quantcast
Channel: 评论:节约内存:Instagram的Redis实践
Browsing latest articles
Browse All 9 View Live

来自:Hshqcn

请教哦: 《如何优化十亿数量级的key-value型数据的存储?》...

View Article



来自:Calvin622

谢谢nosqlfan让我学到了那么多知识 …… 可能的笔误如下 HSET “mediabucket:1155″ “1155315″ “939″ HGET “mediabucket:1155″ “1155315″ > “939″ 应该是: HSET “mediabucket:1155″ “315″ “939″ HGET “mediabucket:1155″ “315″ > “939″

View Article

来自:匿名

原文中确实是上面那样的,不是笔误。 当然你这个属于后面的改进方案中的第二点,是会比上面要省内存一些。

View Article

来自:Hoterran

给个邀请码吧.

View Article

来自:Hoterran

key如果是全数字会自动转化成long类型,较之字符串类型是节约了不少空间, 但全数字就缺少了meta信息,无法表达key的意义.

View Article


来自:匿名

嗯,确实是这样,不过我个人的倾向是愿意用可读性来换取空间。 另外还有朋友说可能多个业务都用数字会出现重复问题,这个我认为也可以用Redis的db号做命名空间的作用,不同业务的key存在不同的db中做隔离。

View Article

来自:Hshqcn

哦,还没开放注册么?

View Article

来自:lisafang

也不是什么很特别的技巧

View Article


来自:Shuoleo

“同样的,这里我们还是可以再进行优化,首先是将Hash结构的key值变成纯数字,这样key长度减少了12个字节,其次是将Hash结构中的subkey值变成三位数,这又减少了4个字节的开销”-难道一个字符占用 一个字节?字符和数字都是一个单位占用一个字节?是不是太浪费空间了?

View Article

Browsing latest articles
Browse All 9 View Live




Latest Images