对大型数据库的查询如何以可忽略的延迟返回？
Answers:
好吧，我不确定是否可以通过MapReduce解决问题，但是肯定不能仅靠MapReduce来解决您提出的所有问题。但是，这里需要考虑一些重要的事情，这使得对来自不同机器上所有这些TB数据的查询进行如此低的延迟变得可行：
- 分布式计算：通过分布并不意味着索引可以简单地分布在不同的机器上，它们实际上是沿着不同的集群复制的，这允许许多用户以较低的检索时间执行不同的查询（是的，大型公司可以负担得起这么多机器）；
- 缓存：缓存极大地减少了执行时间，无论是用于爬网步骤，用于页面检索还是用于结果的排名和展示；
- 大量的调整：以上所有和非常有效的算法/解决方案只有在实现也有效的情况下才有效。有大量的（硬编码）优化，例如引用的位置，压缩，缓存；它们通常都适用于处理的不同部分。
考虑到这一点，让我们尝试解决您的问题：
但是我想对每个可能的查询结果建立索引都是不可行的
是的，对于每个可能的查询都有结果，实际上是不可行的。世界上有无限数量的术语（即使您假设仅输入正确拼写的术语），并且从这些n -> inf术语中查询的数量也呈指数增长（2^n）。那怎么办？正在缓存。但是，如果有太多查询/结果，要缓存哪些？缓存策略。对于用户而言，最频繁/最受欢迎/相关的查询是缓存的查询。
Google的硬件中的硬件延迟会不会很大？即使Google中的数据全部存储在TB / s SSD中
如今，在拥有如此先进的处理器的情况下，人们倾向于认为必须在几秒钟（或更少）内完成且处理大量数据的所有可能的任务必须由具有多个内核和大量内存的功能强大的处理器来处理。但是，统治市场的一件事是金钱，而投资者对浪费金钱没有兴趣。那怎么办？
实际上，优先选择的是拥有很多机器，每台机器都使用简单/可访问的（就成本而言）处理器，这降低了构建大量集群的价格。是的，它确实有效。如果您考虑对性能进行简单测量，则主要瓶颈总是归结为磁盘。但是，一旦有如此多的机器，就可以负担得起将其加载到主存储器中，而不用在硬盘上工作。
存储卡对我们（仅是人类）来说是昂贵的，但对于同时购买大量此类卡的企业而言，它们却非常便宜。由于它并不昂贵，因此有足够的内存来加载索引并随时保留高速缓存不是问题。而且由于有如此多的计算机，因此不需要超快速的处理器，因为您可以将查询定向到不同的位置，并且拥有负责参与特定地理区域的计算机集群，从而可以进行更专业的数据缓存，甚至获得更好的响应次。
MapReduce是否有助于解决此问题？
尽管我不认为使用MapReduce是否是Google内部的受限信息，但我对此并不满意。但是，Google的MapReduce实现（肯定不是 Hadoop）必须进行许多优化，其中涉及到上面讨论的各个方面。因此，MapReduce的体系结构可能有助于指导计算在物理上的分布方式，但是还有许多其他方面需要考虑以证明这种速度在查询时间中是合理的。
好的，所以我知道流行的搜索可以缓存在内存中。但是不受欢迎的搜索呢？
下面介绍了该图的是如何曲线种查询的发生。您可以看到有三种主要的搜索类型，每种类型大约占查询量的1/3（曲线下方的区域）。该图显示了幂定律，并强化了以下事实：较小的查询最受欢迎。由于查询只包含很少的单词，因此后三分之一的查询仍然可行。但是，通常由无经验用户的查询组成的所谓模糊查询集，并不是查询中不可忽略的一部分。
而且还有新颖的解决方案的空间。由于不仅是一两个查询（而是三分之一），所以它们必须具有相关的结果。如果你输入一些东西过于模糊在谷歌搜索，不得需要较长时间才能返回结果的列表，但最有可能给你的东西它推断出你想说。或者它可能只是简单地声明没有包含此类术语的文档-甚至将您的搜索范围缩小到32个单词（这是我在此处的随机测试中碰巧看到的）。
有数十种适用的启发式方法，它们要么忽略某些单词，要么尝试将查询分解成较小的单词，并收集最受欢迎的结果。所有这些解决方案都可以进行定制和调整，以尊重可行的等待时间，例如不到一秒钟？：D
MapReduce与实时性无关。这是一个面向批处理的处理框架，适用于某些离线任务，例如ETL和索引构建。谷歌现在已经从MapReduce转移到大多数工作上，甚至Hadoop生态系统也在这样做。
低延迟的答案通常是将预先计算的索引保留在内存中。接触磁盘的任何事物都难以快速扩展。例如，与基于Hive的基于MapReduce的基础架构相比，像Impala这样的基于Hadoop的新一代SQL引擎具有如此高的速度。
搜索基础结构无法缓存每个查询的结果。但是，它肯定可以缓存中间结果，也可以缓存最热门查询的更完整结果。只需少量缓存，您就可以为所有查询中的极少数提供结果。
搜索也分散在服务器之间。因此，一台机器可以将100委托给每台机器，以得到一部分结果，然后将它们组合起来。
您也可以采用某种程度的近似。Google并不形成一千页的搜索结果。它只需要获取正确的第一页。
请记住，Google 在全球拥有数百万台计算机。您的查询将发送到您附近的数据中心，该数据中心仅对您的地理位置有用。这样可以减少大部分延迟，这是网络延迟，而不是数据中心的处理时间。
MapReduce不在搜索中使用。很久以前就用它来建立索引。但是它是一个批处理框架，并且大多数Web都不会一直更改，因此，较新的体系结构都是增量式的，而不是面向批处理的。
Google的搜索将在很大程度上与Lucene和Elastic Search的工作相同，除了许多微调的额外权重和优化。但从本质上讲，它们将使用某种形式的倒排索引。换句话说，当您输入搜索查询时，即使它们没有被缓存，它们也不会搜索几个TB。他们可能根本不看实际文件。但是他们使用查找表列出了与您的查询字词匹配的文档（包括词干，拼写错误，同义词等，均已预处理）。他们可能会为每个单词检索前10000个文档的列表（10k整数-仅几kb！），然后从中计算出最佳匹配项。仅当这些列表中没有好的匹配项时，它们才会扩展到下一个此类块等。
常见单词查询可以轻松地缓存；并可以通过预处理来构建前10k个结果的列表，然后根据用户个人资料对其进行排名。计算“精确”答案也无济于事。查看前10k个结果就足够了；没有正确的答案；如果错过了位置10001处更好的结果，则没人会知道或注意到（或关心）。它可能已经在预处理中排名较低，并且可能不会进入最后呈现给用户的前十名（或者实际上是用户所看到的前三名）
另一方面，稀有术语也不是什么挑战-列表中仅包含一些匹配的文档，您可以立即丢弃所有其他文档。
我建议阅读这篇文章：
大型超文本Web搜索引擎的解剖
Sergey Brin和Lawrence Page
计算机科学系，斯坦福大学，加利福尼亚州斯坦福94305
http://infolab.stanford.edu/~backrub/google.html
是的，这就是Google创始人写的。这不是最新的状态，但是已经可以大规模使用。