社交网站可能会为用户,朋友和活动维护表格......
他们如何使用这些表以高效和可扩展的方式计算朋友事件?
许多像Twitter这样的社交网站根本不使用RDBMS,而是使用Message Queue应用程序.很多人都是从像RabbitMQ这样的应用程序开始的.他们中的一些人变得足够大,他们必须大量定制或建立自己的.Twitter正在第二次这样做.
消息队列应用程序通过为一个或多个其他服务保留来自一个服务的消息来工作.例如,服务Frank将消息发布到队列foo.Joe和Jill订阅了Franks foo队列.应用程序将跟踪Joe或Jill是否收到了消息,并且一旦队列中的每个订阅者都收到了丢弃它的消息.弗兰克发出消息并忘记它.Joe和Jill向foo请求消息并获取他们尚未得到的任何消息.乔和吉尔做了他们需要做的任何事情.或许保持它可能不是.
消息队列应用程序保证每个应该获取消息的人都可以在他们请求消息时获取消息.发布者可以发送消息,确信订阅者最终可以获得它们.这样做的好处是完全异步,不需要昂贵的连接.
编辑:我还应该提到,通常大规模存储这些类型的东西会严重非规范化.所以乔和吉尔可能正在存储完全相同的消息的副本.这被认为是好的,因为它有助于应用程序扩展到数十亿用户.
其他阅读:
http://www.rabbitmq.com/
http://qpid.apache.org/
社交网站的主要数据结构是图表.在Facebook上,图表是无向的(当你是某人的朋友时,他们就是你的朋友).在Twitter上,图表是定向的(你跟随某人,但他们不一定跟着你).
表示图的两种流行方式是邻接列表和邻接矩阵.
邻接列表只是图表上的边缘列表.考虑具有整数用户ID的用户.
User1, User2 1 2 1 3 2 3
这些记录的无向解释是用户1是用户2和3的朋友,用户2也是用户3的朋友.
在数据库表中表示这一点是微不足道的.这是我们熟悉的多对多关系连接表.用于查找特定用户的朋友的SQL查询非常容易编写.
现在您已了解特定用户的朋友,您只需将这些结果加入更新表即可.此表包含用户标识索引的所有用户更新.
只要所有这些表都被正确编入索引,您就可以非常轻松地设计有效的查询来回答您感兴趣的问题.