1.假如a有1000万粉丝,a发表了一篇博客,这个行为要通知这1000万粉丝,那么就会有两种情况,
(1) 这1000万粉丝每个人都有一个消息中心表,则发送1000万条信息在系统里通知这个1000万个粉丝,
(2) 系统只有一个消息表,这1000万粉丝固定来这个表里拉取自己的消息,那么这个消息是无状态的,怎么让这个消息在用户那里就是有状态了,未读的消息数,以读消息
(3)采用mongdb设计数据库,则消息表和用户粉丝表 该怎能么存储呢?
希望搞sns的人能给我点知道 多谢!!! 修改
(1) 这1000万粉丝每个人都有一个消息中心表,则发送1000万条信息在系统里通知这个1000万个粉丝,
(2) 系统只有一个消息表,这1000万粉丝固定来这个表里拉取自己的消息,那么这个消息是无状态的,怎么让这个消息在用户那里就是有状态了,未读的消息数,以读消息
(3)采用mongdb设计数据库,则消息表和用户粉丝表 该怎能么存储呢?
希望搞sns的人能给我点知道 多谢!!! 修改
这就是服务器缓存技术,有的使用推,有的使用拉。
比如新浪微博FEED使用了拉,但是讲拉做了很大程度的优化,每次拉取数据时参考上次拉取的时间,也就是说每次拉去的时候只是拉去新的,这样就减少了很多资源。每次拉出来的数据是暂存在缓存结构中。而且新浪微博将后台的数据按时间分区存储,这样冷热结合平衡资源配置。
再比如人人网使用的是推,因为每个人的好友一般都是三位数,并不像新浪那样,所以推可以满足人人网的需求。每当有action的时候就向所有的好友推送,每个用户的接受的feed表都是单独的,是现成的,如果有好友动作的话单独添加此用户的feed表
而twitter已经使用nosql来进行新的部署
google+的圈子又是另一种结构,所以存储和拉推的结构肯定又不一样
总之,具体看你的社交结构是怎么样子的所以具体情况使用,根据你的数据量进行分析。一开始用户少就没有必要考虑那么多,等到用户爆机之后才会优化。当用户10万以上的时候,数据库技术的优化就微不足道了,这时候往往开始使用其他手段优化。
互联网的海量存储与快速更新技术都是现在才出现的,所以,每个人都可以想出更多好的方法去实现。或者靠技术人员进行技术代码层次的优化。或者依靠强大的财力进行硬件层次的扩张。
比如新浪微博FEED使用了拉,但是讲拉做了很大程度的优化,每次拉取数据时参考上次拉取的时间,也就是说每次拉去的时候只是拉去新的,这样就减少了很多资源。每次拉出来的数据是暂存在缓存结构中。而且新浪微博将后台的数据按时间分区存储,这样冷热结合平衡资源配置。
再比如人人网使用的是推,因为每个人的好友一般都是三位数,并不像新浪那样,所以推可以满足人人网的需求。每当有action的时候就向所有的好友推送,每个用户的接受的feed表都是单独的,是现成的,如果有好友动作的话单独添加此用户的feed表
而twitter已经使用nosql来进行新的部署
google+的圈子又是另一种结构,所以存储和拉推的结构肯定又不一样
总之,具体看你的社交结构是怎么样子的所以具体情况使用,根据你的数据量进行分析。一开始用户少就没有必要考虑那么多,等到用户爆机之后才会优化。当用户10万以上的时候,数据库技术的优化就微不足道了,这时候往往开始使用其他手段优化。
互联网的海量存储与快速更新技术都是现在才出现的,所以,每个人都可以想出更多好的方法去实现。或者靠技术人员进行技术代码层次的优化。或者依靠强大的财力进行硬件层次的扩张。