Twitter新搜索架构和功能的实现方案

今天（2011年5月31日），Twitter 发布了能够帮助我们的用户找到最相关的推文、图片和视频的 个人化搜索体验。要创造这个产品，我们的基础架构需要支持两项主要的功能：搜索结果的相关性过滤和对于相关图片以及视频的识别。两项功能都需要我们完全重写我们搜索架构，他们的核心就是 Blender 和 Earlybird。

搜索上的投入

自从我们在2008年收购了 Summize 以来，Twitter 不断在搜索上面加重了投入。我们的搜索团队从 3 人增长到了 15 人，并且把实时搜索引擎的可扩展性提高了两个数量级——这一切对于搜索基础架构的替换，都是在对既有服务没有主要任何干扰的情况下做到的。

搜索的进化背后的工程开发故事非常激动人心。原来的 Summize 基础结构使用 Ruby on Rails 作为前端以及 MySQL 作为后端（Twitter 和很多别的 startup 公司都用了同样的架构）。同时，Lucene 以及其他开源搜索技术并不支持实时搜索。结果就是，我们在 MySQL 里面构造了我们的倒排索引，利用其并发事务和 B-tree 数据结构来支持我们的并发索引和搜索。通过把索引分拆到多个数据库中以及使用多个前端副本（replication），这个基于 MySQL 的解决方案走得意想不到地远。2008 年的时候，Twitter 搜索的流量大概是 20 TPS（每秒推文）以及 200 QPS（每秒搜索）。在 2010 年 10 月的时候，当我们把 MySQL 换成了 Earlybird，这个系统平均能处理 1,000 TPS 以及 12,000 QPS。

Earlybird 是一个基于  Lucene 的实时倒排索引，在实时搜索上，它不仅给了我们比MySQL高一个数量级的性能，而且倍增了我们的内存使用效率，并提供了增加相关性过滤的灵活性。然而，我们还是需要换掉 Ruby on Rails 前端，因为它只能对 Earlybird 进行同步调用，并且在多年的扩张和向 Earlybird 的转移中，欠了一大堆技术债。

2011 年 4 月，我们发布了一个替代品，叫做 Blender。他把我们的搜索时延减到了原来的三分之一，带宽提高了 10 倍，并让我们终于能够从搜索基础架构里面去掉 Ruby on Rails。今天（2011 年 5 月）我们每秒大概索引 2,200 条推文，并提供 18,000 QPS 的搜索服务 （每天 16 亿次搜索！）。更重要的是，Blender 填补我们基础架构里面的一个空白，我们正需要这个东西来作一项自收购 Summize 以来最重要的面向用户的改动。

从 Hack-week 到产品化

当我们的团队发布 Earlybird 的时候，我们为其潜力而兴奋——它速度惊人，并且代码非常干净，且便于扩展。我们的一位工程师，Michael Busch，在德国休假的时候，实现了一个图片和视频搜索的演示。一周后，在 Twitter 的第一次 Hack-week，搜索团队以及其它团队的一些成员完成了我们新的搜索体验的第一个演示。来自公司内部的反响非常积极，这个演示就成为了我们的产品规划的一部分。

寻找相关推文

Twitter 上有很多信息——平均而言，每秒钟有 2,200 条新推文产生！在重大事件发生的时候，比如日本海啸时，这个数字还会增加二到三倍。一般来说，我们只对最值得回忆的或是那些用户互动最多的推文感兴趣。在我们的新的搜索体验中，我们只把与某个特定的用户最相关的结果显示出来。所以，搜索结果被个人化了，我们也滤掉那些和其他用户不产生共鸣的推文。

为了支持这项相关性过滤和个人化功能，我们需要三类信号：

• 静态信号，在索引时加入
• 共鸣信号，随时间变化动态更新
• 关于搜索者的信息，搜索时提供

带有相关性支持的 Twitter 搜索基础架构