社交网站可能会为用户,朋友和活动维护表格......
他们如何使用这些表以高效且可扩展的方式计算朋友事件?
答案 0 :(得分:39)
Twitter之类的许多社交网站根本不使用RDBMS,而是使用Message Queue应用程序。很多人都是从像RabbitMQ这样的应用程序开始的。他们中的一些人变得足够大,他们必须大量定制或建立自己的。 Twitter正在第二次这样做。
消息队列应用程序通过为一个或多个其他服务保留来自一个服务的消息来工作。例如,服务Frank将消息发布到队列foo。 Joe和Jill订阅了Franks foo队列。应用程序将跟踪Joe或Jill是否收到了消息,并且一旦队列中的每个订阅者都收到了丢弃它的消息。弗兰克发出消息并忘记它。 Joe和Jill向foo请求消息并获取他们尚未得到的任何消息。乔和吉尔做了他们需要做的任何事情。或许保持它可能不是。
消息队列应用程序保证每个应该获取消息的人都可以在他们请求消息时获取消息。发布者可以发送消息,确信订阅者最终可以获得它们。这样做的好处是完全异步,不需要昂贵的连接。
编辑:我还要提一下,通常情况下,大规模存储这些东西会严重失真。所以乔和吉尔可能正在存储完全相同的消息的副本。这被认为是可以的,因为它可以帮助应用程序扩展到数十亿用户。其他阅读:
答案 1 :(得分:8)
社交网站的主要数据结构是graph。在Facebook上,图表是无向的(当你是某人的朋友时,他们就是你的朋友)。在Twitter上,图表是定向的(你跟随某人,但他们不一定跟着你)。
表示图表的两种常用方法是adjacency lists和adjacency matrices。
邻接列表只是图表上的边缘列表。考虑具有整数用户ID的用户。
User1, User2
1 2
1 3
2 3
这些记录的无向解释是用户1是用户2和3的朋友,用户2也是用户3的朋友。
在数据库表中表示这一点很简单。这是我们熟悉的多对多关系连接表。用于查找特定用户的朋友的SQL查询非常容易编写。
现在您已了解特定用户的朋友,您只需将这些结果加入更新表即可。此表包含用户标识索引的所有用户更新。
只要所有这些表都被正确编入索引,您就可以非常轻松地设计有效的查询来回答您感兴趣的问题。
答案 2 :(得分:2)
Travis写了一篇很棒的帖子,
答案 3 :(得分:0)
对于在users.friends和users.events和查询缓存上进行连接的小规模可能很好,但随着朋友和事件的增长,确实会很快减速。您还可以尝试基于事件的模型,其中每次用户创建事件时,都会在连接表中创建条目(可能称为“friends_events”)。因此,每当用户想要查看他们的朋友创建了什么事件时,他们可以简单地在他们自己的id和friends_events表之间进行连接并找出答案。通过这种方式,您可以避免使用朋友抓住所有用户,然后通过事件表加入他们的朋友。