关于类似新浪微博的后台问题

前段时间公司做了一个类似新浪微博业务的手机应用，关于数据库设计有一些疑问： 1：类似新浪微博发布与转发，网上有介绍说是通过消息机制来的（ActiveMQ发布/订阅模式?）,优先对当前在线的用户推送.但是它微博内容是数据库是怎么设计的呢? 比如,一条新微博: 编号,内容,关键词,时间,收藏数,点赞数,回复数,转发数,等等 那么,转发一条微博呢,是不是在同一张表中添加几个字段,比如:是否转发标志,转发自哪条微博(父编号),等等 我想如果是这样的话,在新浪微这样的平台上的话效率应该会低得可怕吧,各种索引分区分布应该都没用的吧? 2:同样还有回复也有这样的疑问.我知道新浪微博是全球最大的redis用户，那它是否全部采用这种非关系型数据库来保存数据的呢？ 更多0 分享到：

对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理 回复次数：6

	#1 得分：0 回复于： 2015-02-10 16:28:00 完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。
	问答7月活动 大波C币等着你 对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理

	#2 得分：0 回复于： 2015-02-10 16:37:45 引用 1 楼 skgary 的回复: 完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。 好吧，其实本文重点只是把新浪微博作为一个例子，不是在探讨新浪微博的后台架构问题，我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目（当然，跟新浪微博完全不是一个量级的平台），在这种情况下，数据库怎么设计更为合理一点。 当然，新浪微博也不是一天两天练成的，肯定也是不断的升级的。在不同的用户量数据量并发量的情况下，架构肯定是在不断变化升级。只是请教一下，在这种相似的业务逻辑下，假设数据量并发量比较大的情况下（呃，这个还真不好量化，轻拍），牛人们是怎样来考虑这种数据库设计的！！
	下载优快云移动客户端 送50C币 对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理

#3 得分：10 回复于： 2015-02-10 16:44:53 引用 2 楼 XiaoCaiErDie 的回复: Quote: 引用 1 楼 skgary 的回复:  完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。 好吧，其实本文重点只是把新浪微博作为一个例子，不是在探讨新浪微博的后台架构问题，我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目（当然，跟新浪微博完全不是一个量级的平台），在这种情况下，数据库怎么设计更为合理一点。 当然，新浪微博也不是一天两天练成的，肯定也是不断的升级的。在不同的用户量数据量并发量的情况下，架构肯定是在不断变化升级。只是请教一下，在这种相似的业务逻辑下，假设数据量并发量比较大的情况下（呃，这个还真不好量化，轻拍），牛人们是怎样来考虑这种数据库设计的！！ 把你的业务进行抽象，不要万事第一想数据库就是了。 数据库，只是你存数据的地方，你首先要做的是根据业务的需要来决定怎么存。 例如把数据分成高并发存取，但可靠性要求不高的数据；绝对要求可靠的数据；可分散处理的数。 然后再来想，每一块的数据应该怎么存，比如必须分割存，比如直接用内存缓存数据库等等

听社区专家聊聊Android开发那些事 对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理

#4 得分：40 回复于： 2015-02-20 21:05:57 引用 楼主 XiaoCaiErDie 的回复: 前段时间公司做了一个类似新浪微博业务的手机应用，关于数据库设计有一些疑问： 1：类似新浪微博发布与转发，网上有介绍说是通过消息机制来的（ActiveMQ发布/订阅模式?）,优先对当前在线的用户推送.但是它微博内容是数据库是怎么设计的呢? 比如,一条新微博: 编号,内容,关键词,时间,收藏数,点赞数,回复数,转发数,等等 那么,转发一条微博呢,是不是在同一张表中添加几个字段,比如:是否转发标志,转发自哪条微博(父编号),等等 我想如果是这样的话,在新浪微这样的平台上的话效率应该会低得可怕吧,各种索引分区分布应该都没用的吧? 2:同样还有回复也有这样的疑问.我知道新浪微博是全球最大的redis用户，那它是否全部采用这种非关系型数据库来保存数据的呢？ 如果你仅仅从“静态数据结构”的角度看问题，永远也搞不清楚这个“诀窍”。如果换成动态的行为设计就好了！要知道，用户要的是“方便性”，而不是什么学术上的一致性，这就是诀窍所在。 假设一个人发了微博，假设有2万粉丝，假设系统先找一台闲置的机器去收集这2万粉丝基本资料，然后排个序（比如说查询“关系活跃度统计表”），然后分成40个单独的任务分给（1000台机器中反应最快的）40台机器“慢慢地”加消息数据，假设这个过程需要2分钟（别忘记了同时还有另外上万微博更新需要处理）。那么假设在1分10秒的时候某人看到了自己的消息、而另一个人没有看到消息，那么这两个用户会像学究一样找新浪论证一番吗？ 不会的。因此推送消息是“长事务、非数据库事务、异步过程、中间不需要纠结数据一致性”的工作。只要能够复载均衡地保证任务被执行就好了。与其纠结于“一台机器、一瞬间”在数据库上做一个大事务，不如让一大堆机器慢一点去负载均衡地做。

对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理

#5 得分：10 回复于： 2015-02-20 21:11:25 引用 2 楼 XiaoCaiErDie 的回复: Quote: 引用 1 楼 skgary 的回复:  完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。 好吧，其实本文重点只是把新浪微博作为一个例子，不是在探讨新浪微博的后台架构问题，我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目（当然，跟新浪微博完全不是一个量级的平台），在这种情况下，数据库怎么设计更为合理一点。 当然，新浪微博也不是一天两天练成的，肯定也是不断的升级的。在不同的用户量数据量并发量的情况下，架构肯定是在不断变化升级。只是请教一下，在这种相似的业务逻辑下，假设数据量并发量比较大的情况下（呃，这个还真不好量化，轻拍），牛人们是怎样来考虑这种数据库设计的！！ 数据库怎样的结构都可以，为了速度你还可以选择内存数据库，或者干脆连“关系模式”都不要了（只要是文档型嵌套结构，根据顶层id直接向下查找子集合）。数据的结构对性能不起决定作用，决定这类程序“生死”的是异步并行算法，是集群上的分布式任务调度框架。

对我有用[0]  丢个板砖[0]  引用 |  举报 |  管理

#6 得分：40 回复于： 2015-02-20 21:14:14 当你敢于花几百万元买内存，把数T大的数据库都放到内存里，这时候再算一下“瓶颈”就知道了，真正的瓶颈在于 CPU。 如果你有1000颗CPU，并且任务之间有很好的隔离（就像进程那样隔离），那么效率就能提高。