Facebook 如何保持即时自动建议的良好速度
Facebook 具有在各种情况下显示即时自动建议结果的功能，例如：搜索、消息发送等。
我认为我将该功能称为“自动建议”是正确的。
如果用户有 1000 个朋友，并且她/他希望向朋友发送消息，那么 Facebook 会在输入几个字符时建议他/她的名字。
我的问题是：当从数据库中提取数据来寻找朋友（或任何此类情况）然后对其进行处理时，FB 使用哪种技术来保持自动建议的速度？
是缓存变量还是什么？我想知道详细信息，因为我正在计划建立一个社交网站。我的脚本语言是php
Facebook has the feature to show instant auto-suggestion result in-various situations such as : searching , message sending etc.
i think I have been correct in terming the functionality as 'auto-suggestion'.
If a user has 1000 friends and s/he wishes to send message to a friend , then facebook will suggest his/her name on typing a few characters.
My question is: While pulling the data out of database to find friends (or for any such situation) and then handling with it, which technique does FB use to maintain the speed in auto-suggestion?
Is it caching the variable or what? I wish to know in details as i am planning to build a social networking site. My scripting language is php
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为其中很大一部分并不是 PHP，尽管众所周知 facebook 使用 hiphop 来编译 PHP。
在我看来，一个更重要的因素是数据库方面。查询可能已经尽可能优化，只返回它需要的内容，缓存也可能会发挥作用，即用户的朋友已经被检索到，很可能会返回最常联系的朋友。 Facebook 还拥有大量的数据库服务器，这确实有助于提高速度。
希望有帮助
I think a good chunk of it is not so much PHP, although facebook are known to use hiphop to compile the PHP.
A more important factor IMO would be the database side of things. The query is probably as optimised as it can be, only getting back what it needs, caching will probably also come into play, i.e. the user's friends have been already retrieved, quite likely getting back the most frequently contacted friends. Also facebook have tons and tons of database servers, which can only help speed really.
Hope that helps
可能是像 patricia-trie 或 三元搜索树。
一个
suggesttree，例如：suggesttree。Probably a data structure like patricia-trie or ternary search tree.
A
suggesttreelike: suggesttree.自动建议 1000 个甚至 5000 个条目并不难。你必须检索整个朋友列表，并将其存储在索引的 javascript 数组中（例如，我们使用第一个字母作为索引，所以 Friends['a'] = [andrey, albert] ），然后你实际上正在搜索内存中的一小部分。
邀请窗口以类似的方式构建 - 您构建名称索引 -> dom 元素，您可以离线执行 dom 操作 - 并且您只将结果附加到与搜索词匹配的人员。
好友列表很可能缓存在 memcached 中，并且 facebook 会尽早预热缓存 - 它不会等待以任何方式使用好友列表才能将其放入 memcache 中。因此，它在 memcached 中检索、存储在本地存储中并使用高效的 JavaScript。这里不涉及数据库。
PS 我不是代表 Facebook，而是代表我们设计了一个类似的解决方案，用于处理 5000 多个条目的快速自动建议/邀请对话框。
Auto-suggesting with 1000 or even 5000 entries is not that hard. You have to retrieve the whole friend list, and to store it in indexed javascript array (for example we did it using the first letter as index, so friends['a'] = [andrey, albert] ) and then you are actually searching in memory from a small subset.
The invite window is build in similar fashion - you build an index of names -> dom elements, you perform the dom manipulation offline - and you are attaching the results with only people that match the searched term.
The friendlist is most likely cached in memcached, and facebook warm up caches as early as it can - it does not wait to use the friend list in any way in order to put it in memcache. So - it's retrieven in memcached, stored in local storage and uses efficient JavaScript. No DB involved here.
P.S. I'm not speaking for facebook, but for a similar solution we've designed to handle fast auto-suggest / invite dialog on 5000+ entries.