Reddit搜索模块发展简史

Reddit的CTO Chris Slowe、工程副总裁Nick Caldwell和工程总监Luis Bitencourt-Emilio在Reddit网站上披露了Reddit搜索模块的发展史。以下内容翻译自博客内容，查看原文The Search for Better Search at Reddit。

在过去，新来的工程师总会问：“什么时候可以把我们的搜索引擎弄好？”在今年之前，我们的答案通常是：“到5楼去问问搜索引擎团队吧。”但实际上到5楼的电梯按钮根本不管用，而且根本不存在什么搜索引擎团队。

但时代在改变。我们现在很高兴地宣布，Reddit新的搜索模块诞生了。在过去几周，它已经承担了Reddit 50%的搜索流量，提供了将近5亿次搜索。现在我们很有信心可以让它承担起100%的流量，我们也希望你们能够喜欢这样更快也更稳定的搜索结果！

我们在Reddit开辟了一个与搜索相关的产品单元，并由工程总监Luis领导该产品。我们也意识到这些技术对Reddit的未来来说是至关重要的。我们的平台拥有世界上最有趣的内容，包括2.5亿个帖子，而且每天都在增长，但苦于难以对这些内容进行搜索。通过改善搜索体验，用户就可以直接在主页上定制想阅读的内容。

Reddit搜索模块简史

做好搜索不是件轻而易举的事情，在过去的12年中，我们的搜索架构经历了6次技术栈演化。

2005年，联合创始人（现在的CEO）Steve Huffman开始使用PostgresSQL的tsearch2。那个时候一切都还很简单，用Postgres就足够了。Postgres能够做很多事情，它的触发器真的很好用。不过它的缺点是不够灵活，我们很快就发现其中的少部分搜索会影响到其他大部分的查询操作。
2007年，工程元老（现在的CTO）Chris Slowe使用PyLucene重新实现了搜索模块。它是一个单进程的Python RPC服务器，建立在TCP之上，支持多线程。最初的版本支持搜索帖子的标题和评论，Lucene索引文件单独保存。在这一时期我们还没有迁移到AWS上，而且确实也考虑过使用Google Search Appliance。这一版本相对灵活，但伸缩性比较差。
2008年，Reddit的三号员工（现在是搜索工程师）David King使用Solr重新实现了搜索模块。他自己开发了一个叫作pysolr的工具，将最新的文档通过XML格式传给Solr，然后将响应封装成我们的查询模型可以识别的格式。最初版本不支持搜索评论，不过后来支持了。
2010年，David使用IndexTank代替了Solr。网站流量一直在增长，我们的PV达到了每月十亿的级别，而我们只有四个工程师在后面支撑。我们不断添加Postgre数据库作为读副本，添加缓存，还用上了早期版本的Cassandra，但是搜索体验仍然很糟糕。
2012年，LinkedIn关闭了IndexTank项目，于是Keith Mitchell开始使用CloudSearch。在LinkedIn收购IndexTank并将其关闭之后，我们不得不迁移到AWS CloudSearch上。后来我们又从旧的AWS CloudSearch迁移到新的CloudSearch上，但仍然存在性能问题，有将近三分之一的查询无法在5秒钟内完成，导致出现搜索错误页面。
现在，我们使用了Lucidworks的Fusion！我们要确保搜索模块能够满足三个方面的要求：快速、伸缩性和相关性。我们与来自Lucidworks的搜索专家合作，他们当中有好几位是Solr项目的贡献者。

数据摄取（ingest）

在进行搜索系统迁移的过程中，最大的挑战莫过于更新索引管道了。在进行第一次尝试时，我们为了加快速度，直接使用了我们的遗留ETL系统，这个系统由Jenkins和Azkaban组成，我们在上面运行很多Hive查询。从下图可以看出，将多个数据源并入单个点进行索引比我们预期的要复杂得多。

在进行第二次尝试时，我们使用了更简单的方案，也得到了更好的结果。我们把整个管道分成了四个简单地Hive查询，在索引帖子方面提升了33%的速度。另一方面，我们只索引新创建的帖子，同时实时地更新投票和评论的相关度。

提升相关性

低相关度的搜索是没有意义的。在发布搜索系统的时候，我们的主要目标就是要保证搜索结果的相关性不受影响。

我们将新系统和旧系统的搜索结果页面的点击率进行了对比。一个完美的搜索引擎，它提供的搜索结果（排名靠前的部分）会有100%的点击率。当然，我们知道完美的搜索引擎是不存在的，所以我们使用Mean Reciprocal Rank和Discounted Cumulative Gain算法来对比搜索结果的质量。