好吧，我不确定是否是 MapReduce 解决了这个问题，但肯定不会只有 MapReduce 才能解决您提出的所有这些问题。但这里有一些重要的事情需要考虑，这使得对来自不同机器上所有这些 TB 数据的查询具有如此低的延迟是可行的：

1. 分布式计算：分布式并不意味着索引简单地分布在不同的机器上，它们实际上是沿着不同的集群复制的，这允许大量用户执行不同的查询，检索时间很短（是的，大公司可以负担得起这么多机器）；
2. 缓存：缓存极大地减少了执行时间，无论是用于爬取步骤，用于检索页面，还是用于结果的排名和展示；
3. 大量调整：所有上述和非常有效的算法/解决方案只有在实施也有效的情况下才能有效。有大量（硬编码）优化，例如引用位置、压缩、缓存；它们通常都适用于加工的不同部分。

考虑到这一点，让我们尝试解决您的问题：

但我认为对每一个可能的查询的结果进行索引是不可行的

是的，它会，实际上是不可行的，为每一个可能的查询都有结果。世界上有无数个术语（即使您假设只会输入正确拼写的术语），并且来自这些n -> inf术语的查询数量呈指数级增长（2^n）。那么做了什么？缓存。但是如果有这么多查询/结果，哪些要缓存？缓存策略。最频繁/流行/与用户相关的查询是缓存的查询。

谷歌硬件的硬件延迟不会很大吗？即使 Google 中的数据都存储在 TB/s SSD 中

如今，有了如此高度发达的处理器，人们倾向于认为每一个必须在一秒钟（或更短）内完成并且处理大量数据的可能任务，都必须由具有多核和大量内存的极其强大的处理器处理。然而，支配市场的一件事是金钱，投资者对浪费它不感兴趣。那么做了什么？

偏好实际上是拥有大量机器，每台机器都使用简单/可访问（就成本而言）的处理器，这降低了构建大量集群的成本。是的，它确实有效。如果您考虑简单的性能测量，主要瓶颈总是归结为磁盘。但是一旦有这么多机器，就可以负担得起将东西加载到主内存，而不是在硬盘上工作。

存储卡对我们这些普通人来说很贵，但对于一次购买大量此类卡的企业来说却非常便宜。由于成本不高，因此拥有大量内存来加载索引并保持缓存在手边不是问题。而且由于机器太多，不需要超快的处理器，因为您可以将查询定向到不同的地方，并拥有负责处理特定地理区域的机器集群，这允许更专业的数据缓存，甚至更好的响应次。

MapReduce 是否有助于解决这个问题？

虽然我不认为使用或不使用 MapReduce 是 Google 内部的受限信息，但我并不熟悉这一点。但是，Google 的 MapReduce 实现（肯定不是Hadoop）必须有很多优化，其中很多都涉及到上面讨论的方面。因此，MapReduce 的架构可能有助于指导计算的物理分布方式，但还有许多其他点需要考虑以证明查询时间的这种速度是合理的。

好的，所以我知道热门搜索可以缓存在内存中。但是不受欢迎的搜索呢？

下图显示了各种查询如何发生的曲线。您可以看到有三种主要类型的搜索，每一种都拥有大约 1/3 的查询量（曲线下方的区域）。该图显示了幂律，并强化了较小的查询最受欢迎的事实。后三分之一的查询仍然可以处理，因为它们包含的单词很少。但是，通常由非经验用户的查询组成的所谓模糊查询集合，并不是查询中可以忽略的部分。

并且存在新解决方案的空间。由于不仅仅是一两个查询（而是其中的三分之一），它们必须有相关的结果。如果您在 Google 搜索中输入的内容过于晦涩难懂，则返回结果列表不会花费更长的时间，但很可能会向您显示它推断您想说的内容。或者它可能只是声明没有包含此类术语的文档 - 或者甚至将您的搜索减少到 32 个单词（这只是在我这里的随机测试中发生的）。

有数十种适用的启发式方法，可能是忽略某些单词，或者尝试将查询分解为更小的单词，并收集最流行的结果。所有这些解决方案都可以进行定制和调整，以尊重可行的等待时间，比如不到一秒钟？:D

MapReduce 与实时无关。它是一个面向批处理的框架，适用于一些离线任务，如 ETL 和索引构建。谷歌现在大部分工作都不再使用 MapReduce，甚至 Hadoop 生态系统也在做同样的事情。

低延迟的答案通常是将预先计算的索引保存在内存中。任何涉及磁盘的东西都很难快速和扩展。这就是像Impala这样的新一代基于 Hadoop 的 SQL 引擎与Hive等基于 MapReduce 的基础设施相比如何获得如此多的速度。

搜索基础架构无法缓存每个查询的结果。但它肯定可以缓存中间结果，或者，为顶级查询缓存更完整的结果。通过一点缓存，您可以为所有查询中的一小部分提供结果。

搜索也跨服务器拆分。因此，一台机器可以委托 100 人，每人获得一部分结果，然后将它们组合起来。

您也可以通过某种程度的近似来摆脱困境。谷歌并没有真正形成一千页的搜索结果。它只需要让第一页正确。

请记住，Google在全球拥有数百万台计算机。您的查询将发送到地理位置靠近您的数据中心，该数据中心仅服务于您的地理位置。这减少了大部分延迟，这是网络而不是数据中心的处理时间。

MapReduce 不用于搜索。很久以前用来建索引的；但它是一个批处理框架，大部分 web 并不会一直在变化，所以较新的架构都是增量的，而不是面向批处理的。

Google 中的搜索在很大程度上与 Lucene 和 Elastic Search 中的相同，除了许多微调的额外权重和优化。但实际上，他们会使用某种形式的倒排索引。换句话说，当您输入搜索查询时，它们不会搜索几 TB（即使它没有被缓存）。他们可能根本不看实际文件。但他们使用查找表列出哪些文档与您的查询词匹配（词干、拼写错误、同义词等均已预处理）。他们可能会检索每个单词的前 10000 个文档的列表（10k 个整数 - 仅几个 kb！）并从中计算最佳匹配。只有当这些列表中没有很好的匹配时，它们才会扩展到下一个这样的块等。

常用词查询可轻松缓存；通过预处理，您可以构建前 10k 结果的列表，然后根据用户配置文件重新排列它们。计算“准确”的答案也无济于事。查看前 10k 的结果可能就足够了；没有正确答案；如果错过了位置 10001 某处的更好结果，没有人会知道或注意到（或关心）。它可能已经在预处理中排名下降，并且不会进入最后呈现给用户的前 10 名（或前 3 名，用户实际查看）

另一方面，稀有术语也不是什么大问题——其中一个列表只包含几个匹配的文档，您可以立即丢弃所有其他文档。

我推荐阅读这篇文章：

大型超文本 Web 搜索引擎的剖析
Sergey Brin 和 Lawrence Page
计算机科学系，斯坦福大学，斯坦福，CA 94305
http://infolab.stanford.edu/~backrub/google.html

是的，这就是写这篇文章的谷歌创始人。这不是最新的状态，但它已经在相当大的范围内工作了。