如题,我很好奇,像他们腾讯用户量这么大,时刻更新的数据也这么多,他们要怎么去设计数据库的表结构?怎么优化???如果用户量不大的情况下,日活200万,每个人可以关注5000个朋友,这个时候表结构得怎么设计才合理,有啥其他的优化方法吗?数据库用mysql。这个是一个实际项目问题。求各位大神。
1
J2eePro 2015-04-21 13:25:49 +08:00
Sphinx?
|
2
decken 2015-04-21 13:25:59 +08:00
应该用nosql了
|
3
huijiewei 2015-04-21 13:26:00 +08:00 via iPhone
这种一般都是 NoSQL 数据库
|
4
ipconfiger 2015-04-21 13:26:32 +08:00 1
关系型数据库不擅长处理这类结构
|
5
solaro OP 啊。。nosql。。monogdb??redis??
|
6
palytoxin 2015-04-21 13:28:38 +08:00 via iPhone
redmine中的项目动态设计思路挺有趣
|
7
arkilis 2015-04-21 13:31:28 +08:00 1
monogdb, I guess
|
9
Prothunder 2015-04-21 13:41:02 +08:00
redis
|
10
hahasong 2015-04-21 13:41:53 +08:00
用户量大就加机器呗,自建机房,北京,深圳,上海都有。一天光电费都要烧很多。上次新闻上海的还挖断过光缆
|
11
YORYOR 2015-04-21 13:50:31 +08:00
hbase
|
12
abscon 2015-04-21 13:52:25 +08:00 via iPhone
我猜是 Graph database
|
13
caoyue 2015-04-21 13:55:23 +08:00
瞎猜一个,如果是我可能这么设计:
假设 A 和 B 关注了 C,C 发布了一条更新 那么把这条更新同时写到 A,B 各自的关注表里面去 A 和 B 各自读自己的关注表就行了 这样算起来,单独看个人的数据量就没有那么大了=-= |
18
Kilerd 2015-04-21 14:31:11 +08:00
那么大的数据量,关系型的数据库已经不能用了吧。非关系型的会好很多。
不过我更喜欢mongodb |
19
xiaogui 2015-04-21 14:34:38 +08:00
redis,建议楼主搜下新浪微博分享出来的对 redis 使用的资料
|
20
zts1993 2015-04-21 14:55:57 +08:00
redis
|
21
wizardforcel 2015-04-21 15:01:03 +08:00 via Android
朋友圈、微博和说说都是一类东西,这种现成的解决方案应该早就烂大街了。
觉得扛不住就加机器。关系型数据库不合适,是因为,一张表很难以合适的方法切开,放到几台机子上。 |
22
caoyue 2015-04-21 15:01:40 +08:00
|
25
dbfox 2015-04-21 15:58:36 +08:00
hadoop
hbase 应该是与这些东西相关的 |
26
wanjun 2015-04-21 16:00:15 +08:00
分地区,分圈子,分时间
|
27
caoyue 2015-04-21 17:22:12 +08:00
@explon
从 *朋友圈* 看到和点头像进个人的 *Profile* 看到是 两个逻辑 测试方法: 1. A 和 B 是好友 2. A 和 B 互相删除好友 3. A 发布一条朋友圈 4. A 和 B 互相加为好友 5. A 刚发布的更新不会出现在 B 的朋友圈 6. B 在 A 的 Profile 页面可以看到 A 的更新 如果 A 和 B 本来就不是好友,1 和 2 可以忽略 |
28
cheng007 2015-04-21 19:01:30 +08:00
被自己过往经验把自己的思路堵死了
学点分布式构架吧。 |
30
xjx0524 2015-04-21 19:29:40 +08:00 via Android
|
31
zhuchaowe 2015-04-21 20:02:54 +08:00
最近也在做消息流,我的想法是这样的,当然采用的是nosql。
1.用户发布一条消息的时候,向所有的好友们的timeline里面都插入这条消息。虽然看上去数据量会很大,不过再仔细想想,这里的“每份”不需要存储完整信息,只需要存储消息的ID和时间(可能需要)。再说了以空间换时间,这种做法在nosql里还是很常见的。 2.这样做的缺点: 就导致了消息流不可以被编辑和修改,不然每个好友的timeline都要更新,所以微信仅仅提供了删除的功能。 3.微信还有一个消息屏蔽功能,发布的时候时候需要考虑屏蔽的人的话,那就还要去读取每个有权限阅读的人的屏蔽人清单,然后根据每个人的清单去决定是不是放到这个人的timeline中,显然这又会增加多大的计算量。但是仔细一想,都已经好友们每个人都有一份自己的timeline数据的话,那就简单了,客户端渲染的时候,读一下自己的屏蔽列表,然后该隐藏的隐藏,都不用做什么关联查询,也算这种做法的优点。 大概就是这么多,这样做可以实现多台服务器做分布式,牺牲一点空间还是很合算的。 |
32
xiaowangge 2015-04-21 20:02:59 +08:00 via Android
请搜索「腾讯 CMem」,我猜用得是它。←_←
|
34
wuyadong 2015-04-22 00:44:13 +08:00
大家多看看分布式相关的,会有好处的~~~
|
35
safilar 2015-04-22 08:25:09 +08:00 1
标准观察者设计模式,也能讨论成这样。需要表结构?
|
39
safilar 2015-04-29 08:40:03 +08:00
@solaro 不好意思,几天没上了。我只是认为这个状况很适合观察者设计模式,而且这根本就不是大的概念。23种设计模式之一而已,你去看 Head First 第二章,我记得就是说类似的一个样例。但是这种设计能否承受大数据量,我保持怀疑态度。
|
40
safilar 2015-04-29 08:40:32 +08:00
Head First 设计模式
|