Google怎么能这么快？

哪些技术和编程决策可以使Google如此快速地提供查询服务？

每次我搜索某项内容（每天几次）时，总是让我惊讶，它们在不到1秒的时间内还是如何提供结果。他们可以采用哪种配置和算法来实现这一目标？

旁注：有点让人不知所措，即使我要放置一个桌面应用程序并在我的计算机上使用它也可能不会比Google快一半。我说继续学习。

以下是一些不错的答案和提供的指导：

• Google平台
• 地图缩小
• 精心设计的算法
• 硬件-集群场和大量廉价计算机
• 缓存和负载平衡
• Google文件系统

延迟被磁盘访问杀死。因此，有理由相信所有用于回答查询的数据都保存在内存中。这意味着成千上万的服务器，每个服务器都复制许多分片之一。因此，搜索的关键路径不太可能影响其旗舰级分布式系统技术GFS，MapReduce或BigTable。这些将用于粗略地处理搜寻器结果。

关于搜索的方便之处在于，既不需要具有高度一致的结果，也不需要具有完全最新的数据，因此不会阻止Google响应查询，因为已经有了更新的搜索结果。

因此，一种可能的架构非常简单：前端服务器处理查询，对其进行规范化（可能是通过去除停用词等），然后将其分发给拥有该查询空间部分的副本子集（另一种架构是拆分查询通过网页存储数据，因此每个查询都需要联系每个副本集之一。可能会查询许多副本，并且最快的响应会获胜。每个副本都有一个将查询（或单个查询词）映射到文档的索引，它们可用于非常快速地在内存中查找结果。如果从不同的来源返回不同的结果，则前端服务器可以在吐出html时对其进行排名。

请注意，这可能与Google的实际操作还有很长的路要走-他们会设计出该系统的生命，因此在奇怪的区域可能会有更多的缓存，怪异的索引以及某种时髦的负载平衡方案以及其他可能的差异。 。

将其放在一个答案中太多了。 http://en.wikipedia.org/wiki/Google_platform

我发现有趣的一个事实是Google实际上是由生物信息学经营的（'好吧，我觉得很有趣是因为我是一个生物信息学……东西）。让我解释。

早期的生物信息学面临的挑战是如何快速搜索巨大字符串中的小文本。对于我们来说，“巨大的字符串”当然是DNA。通常不是单个DNA，而是来自不同物种/个体的多个DNA的数据库。小文本是蛋白质或其遗传对应物，即基因。计算生物学家的大部分第一批工作仅限于寻找基因之间的同源性。这样做是通过注意与已知基因的相似性来建立新发现的基因的功能。

现在，这些DNA字符串确实变得非常大，并且（有损！）搜索必须极其有效地完成。因此，大多数现代的字符串查找理论都是在计算生物学的背景下发展起来的。

但是，很早以前，传统的文本搜索已经用尽。需要一种新方法，该方法允许在亚线性时间内搜索大型字符串，即无需查看每个字符。发现可以通过预处理大字符串并在其上构建特殊的索引数据结构来解决。已经提出了许多不同的这种数据结构。每种都有优点和缺点，但是有一个特别值得注意的地方，因为它允许在固定时间内进行查找。现在，在Google运作的数量级上，这已经不再完全正确了，因为必须考虑服务器之间的负载平衡，预处理和一些其他复杂的工作。

但从本质上讲，所谓的q-gram索引允许在恒定时间内查找。唯一的缺点：数据结构大得离谱。本质上，为了允许查找最多包含q个字符的字符串（因此具有名称），它需要一个表，该表对于q个字母的每种可能组合（即q ^S，其中S是字母的大小）具有一个字段，例如36（= 26 + 10））。另外，必须为索引中的字符串中的每个字母位置（或对于google，对于每个网站）中的每个字母位置都有一个字段。

为了减轻庞大的规模，Google可能会使用多个索引（实际上，它们会使用，以提供拼写更正等服务）。最上面的那些不会在字符级别起作用，而是在单词级别起作用。这减少了q，但使S无限大，因此他们将不得不使用哈希表和冲突表来应对无限数量的不同单词。

在下一个级别，这些散列的单词将指向其他索引数据结构，这些索引数据结构又将散列指向网站的字符。

长话短说，这些q- gram索引数据结构可以说是Google搜索算法的最核心部分。不幸的是，没有很好的非技术论文来解释q- gram索引如何工作。我所知道的唯一包含这种索引的工作方式的描述是……a，我的学士论文。

以下是一些不错的答案和提供的指导：

• Google平台
• 地图缩小
• 精心设计的算法
• 硬件-集群场和大量廉价计算机
• 缓存和负载平衡
• Google文件系统

他们已经实现了在大量硬件上运行的良好的分布式算法。

最重要的延迟之一是Web服务器将查询发送到Web服务器，然后将响应返回。延迟受光速限制，甚至谷歌也必须遵守。但是，它们在世界各地都有数据中心。结果，到其中任何一个的平均距离都较低。这样可以降低等待时间。当然，差异以毫秒为单位，但是响应是否必须在1000毫秒内到达很重要。

大家都知道是因为他们使用鸽子了！

哦，是的，那是Mapreduce。

他们几乎将Internet的本地副本缓存在自定义文件系统上的数千台PC上。

Google聘用最好的人才。一些IT界最聪明的人在Google工作。他们几乎有无数金钱可以投入硬件和工程师。

他们对执行的任务使用高度优化的存储机制。

他们在地理位置上具有服务器场。

尝试使用广义列表（不取决于您是否可以使用Google的内部工具）：

1. 并行化请求（例如，将单个请求分解为较小的集合）
2. 异步（使异步尽可能多，例如不会阻止用户的请求）
3. 内存 /高速缓存（磁盘I / O速度很慢，请尽可能在内存中保留）
4. 预计算（事前要做尽可能多的工作，不要等待用户要求数据/处理）
5. 关心您的前端HTML（请参阅Yslow和朋友）

您可以在Google研究主页上找到一些有关一些Google专家撰写的研究论文的指针。您应该从google文件系统和map / reduce算法的说明开始，以尝试了解google页面背后的情况。

此链接也非常有用 ，在Google查询的幕后

硬件。

很多很多的硬件。他们使用大型的商用PC群集作为服务器场。

TraumaPony是正确的。大量服务器和用于负载平衡/缓存的智能架构，您可以在1秒内运行查询。网上有很多描述Google服务架构的文章。我相信您可以通过Google找到它们：）

HenryR可能是正确的。

Map Reduce不会对搜索本身起作用，而仅用于索引。请与Map Reduce发明者一起观看此视频采访。

另一个原因似乎是它们欺骗了TCP慢启动算法。

http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html

以及可以利用该硬件功能的算法。例如，像mapreduce。

如果您对有关Google集群如何工作的更多详细信息感兴趣，我将建议其HDFS的这种开源实现。

它基于Google的Mapreduce。

1. 多阶段数据存储，处理和检索

2. 上述任务的有效分配（1000台机器中的100台）

3. 良好的框架来存储原始数据和处理后的结果

4. 检索结果的良好框架

您在问题摘要中拥有的所有链接概括了如何精确地完成所有这些操作