|
精华帖 (0) :: 良好帖 (12) :: 新手帖 (2) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-10-12
liuye 写道 linliangyi2007 写道 gh_aiyz 写道 SNS的话，NoSQL才是王道，上面提到Mongo的兄弟说得很好。基于数据库太麻烦了。
针对SNS的一些特性功能，如：新鲜事，通知等，我们使用cassandra来解决的，但是数据库在存储用户信息方面还是有相对的优势的。 一个SNS系统，肯定不是单一K-V数据库，或者单一的RDB能搞定的，本文仅对多数据库应用方面提供一个入门思路。 大家有好想法的，都说出来讨论一下  sns还是用nosql，是王道，试试mongodb吧，查询功能挺强大的 我们使用cassandra啊，几大SNS运营商都在使用啊 |
| 返回顶楼 | |
|
发表时间：2010-10-12
确实应该考虑日后数据迁移的问题，如果按hash算法切分用户，需要保证切分的稳定性，不能出现日后增加数据库节点的时候造成用户分配的不一致。
和前面一个兄弟说的类似，给数据库编号，然后建立用户-数据库映射表，应该比较灵活，只是会牺牲一点性能，多访问一次数据库。 |
| 返回顶楼 | |
|
发表时间：2010-10-12
coffeesweet 写道 确实应该考虑日后数据迁移的问题，如果按hash算法切分用户，需要保证切分的稳定性，不能出现日后增加数据库节点的时候造成用户分配的不一致。
和前面一个兄弟说的类似，给数据库编号，然后建立用户-数据库映射表，应该比较灵活，只是会牺牲一点性能，多访问一次数据库。 从设计的角度上看，我绝对赞同楼上两位的观点。 但从工程实现的角度看，我们一个库是500万用户上限，16个库是8000万用户，如果我们的系统真能达到5000万的常规用户时，我想系统是需要重新设计了。因此，目前的设计是根据现实目标考虑的。 |
| 返回顶楼 | |
|
发表时间：2010-10-12
动不动横切，切坏了怎么办？
|
| 返回顶楼 | |
|
发表时间：2010-10-12
很有意思，显然很多人都有这样的需求。
用数据库仍然是最成熟，最稳妥，可维护性，扩展性最好的方案。 有兴趣听听楼主对cassandra的使用经验 |
| 返回顶楼 | |
|
发表时间：2010-10-12
不错的文章，哈哈，还是楼上那位说得好，别切坏了，哈
|
| 返回顶楼 | |
|
发表时间：2010-10-12
最后修改：2010-10-12
其实我感兴趣的是你的UserID的hash生成算法是怎么样的.如何最大可能的保证用户的均匀分布情况.
这个问题以前看过一篇很好的文章,可惜啊,忘了... ... |
| 返回顶楼 | |
|
发表时间：2010-10-12
楼主的拆库的思路不错，同时也可以使用在用户少的时候节约服务器，不过500W的用户量系统是否能够承受，当用户量大的时候怎么再次拆分呢？
还有，使用nosql的朋友能否简单说说是怎么设计的呢？ |
| 返回顶楼 | |
|
发表时间：2010-10-13
unas 写道 楼主的拆库的思路不错，同时也可以使用在用户少的时候节约服务器，不过500W的用户量系统是否能够承受，当用户量大的时候怎么再次拆分呢？
还有，使用nosql的朋友能否简单说说是怎么设计的呢？ 目前我们是考虑了4000万用户量，并做了1倍的冗余设计，也就是16台8000万的总量。 实验中500万数据对mysql而言，性能还是可以接受的 |
| 返回顶楼 | |
|
发表时间：2010-10-13
JE帐号 写道 其实我感兴趣的是你的UserID的hash生成算法是怎么样的.如何最大可能的保证用户的均匀分布情况.
这个问题以前看过一篇很好的文章,可惜啊,忘了... ... userid对数据库的映射，通常是先取hashcode，这个算法就比较灵活了，目前我们使用java自带的hashcode算法，没有特别设计。然后就是对数据库总数取模，把hashcode隐射到数据库中。 这部分的算法不需要太复杂，关键是每次计算的一致性，不要造成找不到用户信息就好 |
| 返回顶楼 | |
