Google怎么能这么快？
Google能够如此快速地提供查询的技术和编程决策是什么？
每次我search一些东西（每天几次中的一种），它总是令我惊讶的是，它们在接近或不到1秒的时间内如何提供结果。 他们可以采取什么样的configuration和algorithm来实现这一点？
附注：这是一种压倒性的想法，即使我把桌面应用程序，并在我的机器上使用它可能不会像谷歌一样快。 继续学习我说。
这里提供了一些很好的答案和提示：
- Google平台
- 地图减less
- algorithm精心制作
- 硬件 – 集群农场和大量的廉价电脑
- caching和负载平衡
- Google文件系统
延迟被磁盘访问所杀死。 因此，有理由相信用于回答查询的所有数据都保存在内存中。 这意味着数以千计的服务器，每个服务器复制许多分片之一。 因此，search的关键path不太可能触及其旗舰分布式系统技术GFS，MapReduce或BigTable。 这些将被用来粗略地处理抓取结果。
关于search的便利之处在于，不需要具有强烈一致的结果或完全最新的数据，所以Google不会阻止Google响应查询，因为更新的search结果已经可用。
因此，一个可能的架构很简单：前端服务器处理查询，规范化它（可能通过剥离停用词等），然后将其分发到拥有那部分查询空间的副本的任何子集（另一种架构是将数据由网页，所以每个副本集之一需要联系每个查询）。 很多很多复制品都可能被质疑，而最快的反应就是胜利。 每个副本都有一个索引映射查询（或个别查询条款）到文件，他们可以用它来快速查找内存中的结果。 如果不同的结果来自不同的来源，前端服务器可以sorting他们，因为它吐出的HTML。
请注意，这可能与Google实际上有很长的距离 – 他们将devise出这个系统的生命，所以在陌生的地方可能会有更多的caching，奇怪的索引和某种时髦的负载平衡scheme，以及其他可能的差异。
把它放在一个答案是有点太多了。 http://en.wikipedia.org/wiki/Google_platform
我一直觉得有趣的一个事实是，Google实际上是由生物信息学运行的（“凯，我觉得这很有趣，因为我是一个生物信息…）。 让我解释。
生物信息学很早就面临以巨大的stringsearch小文本的挑战。 对我们来说，“巨大的string”当然是DNA。 通常不是一个DNA，而是来自不同物种/个体的几个DNA的数据库。 小文本是蛋白质或其遗传对应物，一个基因。 计算生物学家的大部分工作都被限制在寻找基因之间的同源性。 通过注意与已知基因的相似性，build立新发现基因的function。
现在，这些DNAstring确实非常大，并且（有损！）search必须非常有效地完成。 大多数现代string查询理论都是在计算生物学的背景下发展起来的。
但是，相当一段时间以前，传统的文本search已经用尽了。 需要一种新的方法来允许在次线性时间内search大string，也就是说，不用查看每个单字符。 发现这可以通过预处理大string并在其上build立特殊索引数据结构来解决。 已经提出了许多不同的这种数据结构。 每个人都有自己的长处和短处，但有一个特别显着的因为它允许持续查找。 现在，谷歌运营的这个数量级不再是严格的，因为跨服务器的负载均衡，预处理和其他复杂的东西都必须考虑在内。
但实质上，所谓的q-gram索引允许在一段时间内进行查找。 唯一的缺点：数据结构变得非常大。 基本上，为了允许查找最多包含q个字符的string（因此需要一个名称），它需要一个表，每个可能的q个字母组合都有一个字段（即q S ，其中S是字母表的大小，说36（= 26 + 10））。 此外，索引string中的每个字母位置都必须有一个字段（或者对于每个网站，在谷歌的情况下）。
为了减小规模，Google可能会使用多个索引（事实上，他们的确提供拼写纠正等服务）。 最顶层的将不会在字符级别上工作，而是在字级上。 这减less了q，但它使S无限大，所以他们将不得不使用散列和碰撞表来应付无限数量的不同单词。
在下一级，这些散列的单词将指向其他索引数据结构，而这些结构又会散列指向网站的字符。
长话短说，这些q- gram索引数据结构可以说是Googlesearchalgorithm最核心的部分。 不幸的是，没有很好的非技术文件来解释q- gram指数是如何工作的。 我所知道的唯一包含这种索引如何工作的出版物是……我的学士论文 。
这里提供了一些很好的答案和提示：
- Google平台
- 地图减less
- algorithm精心制作
- 硬件 – 集群农场和大量的廉价电脑
- caching和负载平衡
- Google文件系统
他们已经实现了运行在大量硬件上的优秀的，分布式的algorithm。
其中一个最重要的延迟是web服务器正在将您的查询发送到networking服务器，并将响应返回。 这个延迟受到光速的约束，甚至Google也必须服从。 但是，他们拥有遍布全球的数据中心。 结果，与其中任何一个的平均距离都较低。 这使延迟下降。 当然，差异是以毫秒为单位来衡量的，但是如果响应必须在1000毫秒之内到达，这个问题就很重要。
每个人都知道这是因为他们使用鸽子 ！
哦，是的，那和Mapreduce。
他们几乎有一个互联网的本地副本caching在数以千计的个人电脑上的自定义文件系统。
Google聘用最好的。 IT部门的一些最聪明的人在谷歌工作。 他们几乎可以无限的投入硬件和工程师。
他们使用高度优化的存储机制来执行他们正在执行的任务。
他们在地理上位于服务器农场。
尝试一个广义列表（不依赖于您访问Google的内部工具）：
- 请求（例如，将一个请求分解成更小的集合）
- asynchronous （使尽可能多的不同步，例如不会阻止用户的请求）
- 内存 /caching（磁盘I / O速度较慢，请尽可能多地保留在内存中）
- 预先计算 （尽可能多的工作，不要等待用户要求数据/处理）
- 关心你的前端HTML （请参阅Yslow和朋友）
你可以在谷歌研究主页find一些关于一些谷歌的人写的研究论文的指针。 您应该从google文件系统和map / reducealgorithm的解释开始，试图了解Google页面背后发生了什么。
这个链接也非常丰富在谷歌查询的幕后
硬件。
很多很多的硬件。 他们使用大量商品PC作为服务器群。
TraumaPony是对的。 用于负载平衡/caching的服务器和智能体系结构的数量和瞧你可以在1秒内运行查询。 网上有很多文章描述谷歌服务架构。 我相信你可以通过Googlefind他们:)
HenryR可能是正确的。
Map Reduce不起到search本身的作用，但仅用于索引。 查看这个Map Reduce发明者的video采访 。
另一个原因似乎是他们在TCP慢启动algorithm上作弊。
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
和可以利用这种硬件能力的algorithm 。 像mapreduce例如。
如果您有兴趣了解更多有关Google集群如何工作的细节，我会build议他们的HDFS的开源实现。
它基于谷歌的Mapreduce 。
-
多阶段的数据存储，处理和检索
-
有效的分配（上千个机器的100个）以上任务
-
良好的框架来存储原始数据和处理结果
-
良好的框架来检索结果
问题摘要中的所有链接汇总了所有这些操作的完成情况
