blocks|key|2858645|text|我猜他们会把自己的friends表和likes表连接起来，同时统计普通点赞和好友点赞。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2858646|有了适当的索引，查询就一点也不慢了。大型数据库并不一定很慢，因此没有理由不将所有这些信息都存储在数据库中。诀窍是确保索引和分区(如果有)设置得很好。|2858647|entityMap^0|9|7|I|5|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

I would guess they outer join their <code>friends</code> table with their <code>likes</code> table to count both regular likes and friend likes at the same time.

With the proper indexes, it wouldn't be a slow query at all. Huge databases aren't necessarily slow, so there's really no reason to not store all of this information in a database. The trick is to make sure the indexes and partitions (if any) are set up well.

blocks|key|542807|text|Facebook至少在某些方面使用了NoSQL数据库Cassandra。下面是一些较大的社交媒体网站如何解决这些问题的更详细的讨论：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|542808|http://www.25hoursaday.com/weblog/2009/09/10/BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg.aspx|542809|如果你点击它的链接到Digg的博客帖子，等等，里面有很多有趣的阅读。|542810|entityMap|0|LINK|mutability|MUTABLE|url|http://incubator.apache.org/cassandra/|1^0|Q|9|0|0|0|35|1|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|E]]]]

Facebook uses <a href="http://incubator.apache.org/cassandra/" rel="noreferrer">Cassandra</a>, a NoSQL database for at least some things. Here's a more detailed discussion of what some of the bigger social media sites do to solve these problems:

<a href="http://www.25hoursaday.com/weblog/2009/09/10/BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg.aspx" rel="noreferrer">http://www.25hoursaday.com/weblog/2009/09/10/BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg.aspx</a>

Lots of interesting reading in there if you follow the links from it to the Digg blog post, etc.

blocks|key|2858695|text|是的，他们肯定会将数据保存在他们的数据库中，因为他们肯定有不止一台服务器需要访问数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2858696|至于可伸缩性，我确信他们使用了大量的缓存。|2858697|下面是一个示例：|2858698|如果您有一百万行要处理，那么索引可以执行O(logn)+=+20个操作(在最坏的情况下)，只是为了找到您需要的内容。|2858699|对于200万，你只需要21次操作(在最坏的情况下)就可以找到你需要的东西。|2858700|每次您要通过的用户数增加一倍，您只需要使用O(logn)索引再执行一次操作(在最坏的情况下)。|2858701|它们还具有分布式架构或集群数据库。|2858702|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

Yes they definitely keep it in their database as they definitely have more than 1 server that needs to access the data. 

As for scalability, I'm sure they use a lot of caching. 

Here is an example:

If you have 1 million rows to go through, an index can perform O(logn) = 20 operations (in the worst case) only to find what you need.

For 2 million, you only need 21 operations (in the worst case) to find what you need.

Every time you double the amount of users to go through you simply need only 1 more operation (in the worst case) with a O(logn) index.

They also have a distributed architecture or a clustered database.

blocks|key|872084|text|Facebook必须使用触发器(一旦事件发生，触发器就会自动执行)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|872085|例如，假设创建了一个触发器来存储喜欢该状态的人的数量和姓名，那么每当有人喜欢你的状态并且太隐式(自动)时，它就会被执行。|872086|这使得操作变得非常简单，Facebook不必为此手动更新数据库或存储巨大的数据库。而且，这种方法速度更快。|872087|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Facebook must be using a trigger(which automatically gets executed as soon as an event occurs).

For example, suppose a trigger is created to store the count and names of people who liked the status, then it will get executed every time when someone likes your status and that too implicitly (automatically).

This makes the operation way too easy and Facebook doesn't have to manually update the database or store a huge database for this. Also,this approach is a faster one.

blocks|key|2858794|text|在设计社交网络软件(mothsorchid.com)时，我发现解决这个问题的唯一方法是预先缓存通知流。一个人不会在页面加载时查询数据库来计算有多少朋友和其他人“喜欢”了这个，当有人“喜欢”记录在对象上的东西时，当检索对象时可以与当前用户的朋友列表进行比较。如果有人更新了他们的个人资料/发表了评论/等等，它会向朋友发送通知对象，这些对象已经预先缓存在他们的feed中。以磁盘空间为代价，极大地减少了数据库工作，但磁盘空间很便宜。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2858795|至于Facebook是如何做到这一点的，他们使用的是Cassandra+DBMS，这可能与您的想法略有不同。|2858796|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In designing social networking software (mothsorchid.com) I found the only way to address this is to pre-cache streams of notifications. One doesn't query the database at the time of page load to count how many friends and others 'liked this', when someone 'likes' something that is recorded on the object, and when retrieving the object one can compare with the current user's friend list. If someone updates their profile/makes a comment/etc it sends notification objects to friends which are pre-cached in their feeds. Cuts down tremendously on database work at expense of disk space, but disk space is cheap.

As to how Facebook does this, they use Cassandra DBMS, which is probably a little different to what you have in mind.

blocks|key|2858835|text|请记住，Facebook强烈利用memcached，所以他们在内存中保留了大量数据，只有在绝对必要的时候才会刷新。有关这方面的可扩展性讨论，请参阅此博客文章：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2858836|http://www.facebook.com/note.php?note_id=39391378919|2858837|entityMap|0|LINK|mutability|MUTABLE|url|http://www.danga.com/memcached/|1^0|G|9|0|0|0|1G|1|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@$A|P|B|Q|1|R]]|C|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|F|3|-4|5|6|7|W|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|E]]]]

Keep in mind that Facebook strongly utilizes <a href="http://www.danga.com/memcached/" rel="nofollow noreferrer">memcached</a>, so they're retaining a lot of data in memory and only refreshing it when absolutely necessary. See this blog post for some scalability discussion around this:

<a href="http://www.facebook.com/note.php?note_id=39391378919" rel="nofollow noreferrer">http://www.facebook.com/note.php?note_id=39391378919</a>

blocks|key|2858766|text|每个人可能喜欢的条目可能包含每个喜欢它的人的列表(所有这些当然都在数据库中)。当您查看该条目时，他们会将其与您的朋友列表进行匹配，以查看他们中的哪一个是您的朋友。瞧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2858767|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Each entry that somebody can like probably contains a list of everybody who does like it (all of this is of course in a database). When you view that entry, they match it against your friends list to see which of them is your friend. Voila.

blocks|key|2858842|text|Facebook的工程总监在这篇QCon演示文稿中解释了很多这一点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2858843|http://www.infoq.com/presentations/Facebook-Software-Stack|offset|length|2858844|一个不错的演示文稿值得一看……|2858845|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1M|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

A lot of this are explained by the Director of Engineering of Facebook in this QCon presentation :

<a href="http://www.infoq.com/presentations/Facebook-Software-Stack" rel="nofollow noreferrer">http://www.infoq.com/presentations/Facebook-Software-Stack</a>

A great presentation to watch.....

Have you ever noticed how facebook says “3 friends and 33 others liked this”? I was wondering what the best approach to do this is. I don’t think going through the friends list, and the list of users who “liked this” and comparing them is efficient at all! Do they keep a track of this in the database? That will make the database size very huge. 
What do you guys think?

Thanks!

How does Facebook do it?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

你有没有注意到facebook是怎么说的“3个朋友和33个人喜欢这个”？我想知道做这件事的最好方法是什么。我不认为浏览好友列表和“喜欢”的用户列表，并将它们进行比较是非常有效的！他们是否在数据库中对此进行跟踪？这将使数据库变得非常庞大。你们觉得怎么样？谢谢!

问Facebook是怎么做到的？
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Facebook是怎么做到的？EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Facebook是怎么做到的？
EN