请教大神,关于类似新浪微博的后台问题

是奉壹啊 2015-02-10 04:21:52
前段时间公司做了一个类似新浪微博业务的手机应用,关于数据库设计有一些疑问:
1:类似新浪微博发布与转发,网上有介绍说是通过消息机制来的(ActiveMQ发布/订阅模式?),优先对当前在线的用户推送.但是它微博内容是数据库是怎么设计的呢?
比如,一条新微博: 编号,内容,关键词,时间,收藏数,点赞数,回复数,转发数,等等
那么,转发一条微博呢,是不是在同一张表中添加几个字段,比如:是否转发标志,转发自哪条微博(父编号),等等

我想如果是这样的话,在新浪微这样的平台上的话效率应该会低得可怕吧,各种索引分区分布应该都没用的吧?

2:同样还有回复也有这样的疑问.我知道新浪微博是全球最大的redis用户,那它是否全部采用这种非关系型数据库来保存数据的呢?
...全文
1039 7 打赏 收藏 转发到动态 举报
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
q徒步 2016-05-11
  • 打赏
  • 举报
回复
我最近也搞这功能。 你们是怎么实现的? 用缓存还是关系数据库?
  • 打赏
  • 举报
回复
当你敢于花几百万元买内存,把数T大的数据库都放到内存里,这时候再算一下“瓶颈”就知道了,真正的瓶颈在于 CPU。 如果你有1000颗CPU,并且任务之间有很好的隔离(就像进程那样隔离),那么效率就能提高。
  • 打赏
  • 举报
回复
引用 2 楼 XiaoCaiErDie 的回复:
[quote=引用 1 楼 skgary 的回复:] 完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。
好吧,其实本文重点只是把新浪微博作为一个例子,不是在探讨新浪微博的后台架构问题,我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目(当然,跟新浪微博完全不是一个量级的平台),在这种情况下,数据库怎么设计更为合理一点。 当然,新浪微博也不是一天两天练成的,肯定也是不断的升级的。在不同的用户量数据量并发量的情况下,架构肯定是在不断变化升级。只是请教一下,在这种相似的业务逻辑下,假设数据量并发量比较大的情况下(呃,这个还真不好量化,轻拍),牛人们是怎样来考虑这种数据库设计的!![/quote] 数据库怎样的结构都可以,为了速度你还可以选择内存数据库,或者干脆连“关系模式”都不要了(只要是文档型嵌套结构,根据顶层id直接向下查找子集合)。数据的结构对性能不起决定作用,决定这类程序“生死”的是异步并行算法,是集群上的分布式任务调度框架。
  • 打赏
  • 举报
回复
引用 楼主 XiaoCaiErDie 的回复:
前段时间公司做了一个类似新浪微博业务的手机应用,关于数据库设计有一些疑问: 1:类似新浪微博发布与转发,网上有介绍说是通过消息机制来的(ActiveMQ发布/订阅模式?),优先对当前在线的用户推送.但是它微博内容是数据库是怎么设计的呢? 比如,一条新微博: 编号,内容,关键词,时间,收藏数,点赞数,回复数,转发数,等等 那么,转发一条微博呢,是不是在同一张表中添加几个字段,比如:是否转发标志,转发自哪条微博(父编号),等等 我想如果是这样的话,在新浪微这样的平台上的话效率应该会低得可怕吧,各种索引分区分布应该都没用的吧? 2:同样还有回复也有这样的疑问.我知道新浪微博是全球最大的redis用户,那它是否全部采用这种非关系型数据库来保存数据的呢?
如果你仅仅从“静态数据结构”的角度看问题,永远也搞不清楚这个“诀窍”。如果换成动态的行为设计就好了!要知道,用户要的是“方便性”,而不是什么学术上的一致性,这就是诀窍所在。 假设一个人发了微博,假设有2万粉丝,假设系统先找一台闲置的机器去收集这2万粉丝基本资料,然后排个序(比如说查询“关系活跃度统计表”),然后分成40个单独的任务分给(1000台机器中反应最快的)40台机器“慢慢地”加消息数据,假设这个过程需要2分钟(别忘记了同时还有另外上万微博更新需要处理)。那么假设在1分10秒的时候某人看到了自己的消息、而另一个人没有看到消息,那么这两个用户会像学究一样找新浪论证一番吗? 不会的。因此推送消息是“长事务、非数据库事务、异步过程、中间不需要纠结数据一致性”的工作。只要能够复载均衡地保证任务被执行就好了。与其纠结于“一台机器、一瞬间”在数据库上做一个大事务,不如让一大堆机器慢一点去负载均衡地做。
skgary 2015-02-10
  • 打赏
  • 举报
回复
引用 2 楼 XiaoCaiErDie 的回复:
[quote=引用 1 楼 skgary 的回复:] 完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。
好吧,其实本文重点只是把新浪微博作为一个例子,不是在探讨新浪微博的后台架构问题,我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目(当然,跟新浪微博完全不是一个量级的平台),在这种情况下,数据库怎么设计更为合理一点。 当然,新浪微博也不是一天两天练成的,肯定也是不断的升级的。在不同的用户量数据量并发量的情况下,架构肯定是在不断变化升级。只是请教一下,在这种相似的业务逻辑下,假设数据量并发量比较大的情况下(呃,这个还真不好量化,轻拍),牛人们是怎样来考虑这种数据库设计的!![/quote] 把你的业务进行抽象,不要万事第一想数据库就是了。 数据库,只是你存数据的地方,你首先要做的是根据业务的需要来决定怎么存。 例如把数据分成高并发存取,但可靠性要求不高的数据;绝对要求可靠的数据;可分散处理的数。 然后再来想,每一块的数据应该怎么存,比如必须分割存,比如直接用内存缓存数据库等等
是奉壹啊 2015-02-10
  • 打赏
  • 举报
回复
引用 1 楼 skgary 的回复:
完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。
好吧,其实本文重点只是把新浪微博作为一个例子,不是在探讨新浪微博的后台架构问题,我还远远远远远远没有达到这种程度。只是公司有个类似新浪微博部分业务的项目(当然,跟新浪微博完全不是一个量级的平台),在这种情况下,数据库怎么设计更为合理一点。 当然,新浪微博也不是一天两天练成的,肯定也是不断的升级的。在不同的用户量数据量并发量的情况下,架构肯定是在不断变化升级。只是请教一下,在这种相似的业务逻辑下,假设数据量并发量比较大的情况下(呃,这个还真不好量化,轻拍),牛人们是怎样来考虑这种数据库设计的!!
skgary 2015-02-10
  • 打赏
  • 举报
回复
完全不是你想像的那样。 去百度文库或者InfoQ的访谈里去找找相应的PPT和架构介绍。

25,985

社区成员

发帖
与我相关
我的任务
社区描述
高性能WEB开发
社区管理员
  • 高性能WEB开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧