惊了 redis 还能这样玩？？

[johnsneakers]

接手新项目，那个程序把 hash 当 MySQL 来用，给我说他们以前项目都这样搞。具体是：所有玩家的个人信息放在 user 这个 key 里面，hset user 10000 用户个人信息 json。 第一次见这样玩的 ，我太菜了，怎么给对方说都不听。

[limitsy]

看懂了。。意思就是。hash 作为一张表用？社会社会。。

[jyf]

这样做其实挺好的 我记得 instgram 还是 flickr 曾经分享过一个心得 是把他们的数据从你那种方式转换成提问里这种方式 内存省了好多好多
另外你没想到这样清理方便么

[mentalidade]

跟我这个很像，不过我不要哈希，就 key-value，/t/450596

[myyou]

用 hash 据说可以让内存使用减小到是 string key 的 1/10，而且 hash 的查询速度也很快。现在的 redis 已经很稳定了，架构设计合理，作为很持久化使用，并没有什么不妥。

[jyf]

http://nosql.mypopescu.com/post/1010844204/redis-memory-usage

[OneNian]

居然有人觉得一个 hash 这样用很合理，持久化也很合理？……用过 redis 没？

[ylcc]

@ioth 如果你能提出你的理由那是合理反驳，如果你不加最后一句，我会把你当个人，但是我现在只能当你是条狗

[tylerdurden]

既然都是程序员，咱们数据说话好不好，来个对比呗，不要臆断可以么

[changnet]

@johnsneakers 没说这是最好的方案啊，具体业务不知道，你们项目成员经验也不知道，不好说。通常都是 redis 做缓存，后面 mysql 落地。一个 key 的问题，这个设计有点奇怪，一般都是分开的吧。

[youxiachai]

@changnet redis 其实也能做落地...
人家实践过.应该是信得过,redis 的落地

[gotanaka4869]

http://carlosfu.iteye.com/blog/2254572

[changnet]

@youxiachai 是能做落地。但是实际操作起来团队的经验不够，运维的经验不够，容灾不如 mysql 成熟，不好做。还要考虑后续优化，维护啊。

[youxiachai]

@OneNian instagram 了解一下

http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value

[nooper]

https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c.
真是少见多怪，人家设计的没问题。

[9684xtpa]

不过如果是集群的话，这么做会导致热点 key，然后并发高的话，会有问题的

[imherer]

这样做应该也没什么大问题吧
不过我的做法和你一样，也是一个 user 一个 key

[youxiachai]

看了一下...instagram 那篇文章居然是 2011 年的....
一些...大厂的博客..还是值得去翻翻啊..

[youxiachai]

@ylcc 其实..instagram .. 2011 年就分享过这样的操作了......

[darklowly]

假设按照
users:id 的模式存储
那么 id 为 10000 的用户的存储 key 是:
users:10000,key 大概需要 11 个字节
同时 id 为 10001 的用户的存储 key 是:
users:10001,key 大概需要 11 个字节

如果是按照 hash 来存储
则两个用户,一共需要 len(users) + len(10000) + len(10001) = 5 + 5 + 5 = 15 个字节
依此类推。


@9684xtpa

如果是集群的话，
给 user 分片就可以了，例如 users_1,users_2

[jwdstefani]

这种玩法 直接上 mongo 啊