如何成功构建大规模 Web 搜索引擎架构

Web搜索引擎十分复杂，我们的产品是一个分布式系统，在性能和延迟方面有非常苛刻的要求。除此之外，这个系统的运营也非常昂贵，需要大量人力，当然也需要大量金钱。

这篇文章将探讨我们使用的一些技术栈，以及我们做出的一些选择和决策。

作者 | Cliqz

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

在本文中，我们将系统地介绍我们的私有搜索产品，经过多年的迭代，来满足外部和内部的用户。

我们结合使用了很多有名的开源技术，以及云原生技术，这些技术都经受了严格的测试。对于哪些未能从开源或商业系统中找到解决方案的领域，我们只能深入研究，并自行从头编写系统。这种方式十分适合我们现在的规模。

免责声明：本文描述的只是系统现在的情况。当然最初的系统并非如此。多年来我们采用过多种架构，并不断思考诸如成本、流量和数据大小等约束。但本文并不是构建搜索引擎的指南，而只是我们目前正在使用的系统，高德纳曾说：

“过早优化是万恶之源。”

我们完全同意这句话。我们真心建议所有人不要一次性把所有食材都扔进锅里。但也不必逐个放，而是每次一小步，逐步增加复杂性。

搜索引擎的经验——下拉菜单和SERP

Cliqz的搜索引擎有两类客户，他们有不同的需求。

搜索提示

浏览器中的Cliqz下拉菜单

浏览器的地址栏中可以搜索，搜索结果显示在下拉菜单中。这类搜索要求的结果很少（通常是3条），但对于延迟的要求十分苛刻（一般在150毫秒以内），否则就会影响用户体验。

在SERP中搜索

Cliqz搜索引擎的结果页面 beta.cliqz

在网页上进行搜索，显示人所共知的搜索结果页面。这里，搜索的深度是无限的，但与下拉菜单相比，它对于延迟的要求较低（只需在1000毫秒以内就可以）。

全自动和近乎实时的搜索

考虑一个查询，如“拜仁慕尼黑”。这个查询似乎非常普通，但该查询会使用我们系统中的数个服务。如果考虑这个查询的意图，就会发现用户可能想要：

研究拜仁慕尼黑俱乐部（这种情况下显示维基百科的小窗可能会有用）

• 想订票、购物或者注册成为正式的粉丝（显示官方网站）

• 想了解有关该俱乐部的新闻：

• 赛前有关比赛的新闻

• 比赛中的信息，如实时比分、实时更新或解说

• 赛后分析

• 季后信息，如俱乐部的内部情况，转会期间的活动，聘用新教练等

• 搜索旧的网页和内容、俱乐部历史、过去的比赛记录等。

你也许会注意到，这些意图远非“相关网页”能概括。这些信息不仅从语义上相关，而且还与时间有关。搜索的时间敏感度对于用户体验非常重要。

为提供合理的用户体验，这些信息必须由不同的信息源提供，并以近乎实时的方式转换成可以被搜索的索引。我们要保证所有模型、索引和相关文件都是最新的（例如，加载的图像必须反映当前的事件，标题和内容也必须随时根据正在发展的事件而更新）。在大规模的条件下，尽管这一切看似很难，但我们坚持认为我们应该永远给用户推送最新的信息。这个理念贯穿了我们整个系统架构的基础。

Cliqz的数据处理和服务平台采用了多层的Lambda架构。该架构根据内容索引的即时性分成三层，分别是：

近乎实时的索引

• 完全自动，由Kafka（生产者、消费者和流处理器）、Cassandra、Granne和RocksDB负责提供