谷歌怎么能这么快？

【问题标题】：How can Google be so fast?谷歌怎么能这么快？
【发布时间】：2010-09-13 00:57:19
【问题描述】：

让 Google 能够如此快速地提供查询服务的技术和编程决策是什么？

每次我搜索某些东西（每天几次）时，我总是惊讶于他们如何在接近或不到 1 秒的时间内提供结果。他们可以采用什么样的配置和算法来实现这一点？

旁注：有点压倒性地认为，即使我要在我的机器上放置一个桌面应用程序并使用它，它的速度可能也不会像 Google 的一半。我说继续学习。

这里提供了一些很好的答案和建议：

【问题讨论】：

    标签： performance algorithm


    【解决方案1】：

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

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

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

    请注意，这可能与 Google 实际所做的相差甚远 - 他们将设计出这个系统的生命，因此可能会有更多奇怪区域的缓存、奇怪的索引和某种时髦的负载平衡方案其他可能的差异。

    【讨论】：

      【解决方案2】：

      把它放在一个答案中有点过分了。 http://en.wikipedia.org/wiki/Google_platform

      【讨论】：

        【解决方案3】：

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

        早期的生物信息学面临着快速搜索巨大字符串中的小文本的挑战。对我们来说，“巨弦”当然是 DNA。通常不是单个 DNA，而是来自不同物种/个体的几个 DNA 的数据库。小文本是蛋白质或它们的基因对应物，一个基因。计算生物学家最初的大部分工作仅限于寻找基因之间的同源性。这样做是为了通过记录与已知基因的相似性来确定新发现基因的功能。

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

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

        但本质上，所谓的q-gram index允许在恒定时间内进行查找。唯一的缺点：数据结构变得非常大。本质上，为了允许查找最多包含 q 个字符（因此得名）的字符串，它需要一个表，其中每个可能的 q 个字母组合都有一个字段（即 qS，其中 S 是字母表的大小，例如 36 (= 26 + 10 ））。此外，被索引的字符串中的每个字母位置都必须有一个字段（或者在 google 的情况下，对于每个网站）。

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

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

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

        【讨论】：

        • 我在生物信息学领域工作了 5 年，之后的搜索引擎——q-gram 并没有你想象的那么重要。 Google 所做的那种查找（在非常非常基础的层面上）的基本数据结构是倒排索引。
        • 这似乎是错误的。 Google 正在运行或正在运行倒排索引。 q-gram 对短语有用，但不是一般的
        • @Stefan：SquareCog 已经发表了同样的评论——我不否认倒排索引发挥了重要作用（并且可能比 n-gram 索引大得多）。我之所以选择这项技术，是因为 n-gram 是我的一种宠物数据结构，而且我认为关键的洞察力——谷歌速度很快，因为它实际上不需要“搜索”，它可以或多或少地进行直接查找——确实依赖于这样的索引（nb：这可能是通过散列完成的，但这仍然是一个 n-gram 索引）。这个索引也恰好是倒置的，这对我来说是偶然的（尽管可能不是谷歌;-)）。
        【解决方案4】：

        这里提供了一些很好的答案和建议：

        【讨论】：

          【解决方案5】：

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

          【讨论】：

            【解决方案6】：

            最重要的延迟之一是网络服务器将您的查询发送到网络服务器并返回响应。这种延迟受光速的限制，即使是谷歌也必须遵守。但是，他们在世界各地都有数据中心。结果，到其中任何一个的平均距离都较低。这可以降低延迟。当然，差异以毫秒为单位，但如果响应必须在 1000 毫秒内到达，这很重要。

            【讨论】：

              【解决方案7】：

              每个人都知道这是因为they use pigeons，当然！

              哦，是的，还有 Mapreduce。

              【讨论】：

              • 如果他们也让老鼠为他们工作，那么两个最无用和最烦人的生物就会有工作......
              • 这个我笑了很多哈哈
              【解决方案8】：

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

              【讨论】：

              • 访问基于磁盘的文件系统会在延迟方面付出很多代价（亚马逊在 Dynamo 中发现了这一点，并为此牺牲了一些弹性）；我怀疑关键路径上的所有内容都保存在内存中。
              【解决方案9】：

              Google 聘用最优秀的人才。一些 IT 领域最聪明的人在谷歌工作。他们几乎有无限的资金可以投入到硬件和工程师身上。

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

              他们拥有地理位置优越的服务器场。

              【讨论】：

                【解决方案10】：

                尝试一个通用列表（不取决于您是否可以访问 Google 的内部工具）：

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

                【讨论】：

                  【解决方案11】：

                  您可以在the google research homepage 中找到一些关于某些 google 人员撰写的研究论文的提示。您应该从 google file system 和 map/reduce algorithm 的解释开始，尝试了解 google 页面背后发生了什么。

                  【讨论】：

                    【解决方案12】：

                    这个链接也很丰富 Behind the scenes of a google query

                    【讨论】：

                      【解决方案13】：

                      硬件。

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

                      【讨论】：

                      • 只是为了澄清“大规模”：数十万台服务器。我猜除了 Google 之外没有人知道真实的数字，而且它肯定一直在变化。
                      【解决方案14】：

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

                      【讨论】：

                        【解决方案15】：

                        HenryR 可能是正确的。

                        Map Reduce 对搜索本身没有任何作用，仅用于索引。 检查this video interview with the Map Reduce inventors。

                        【讨论】：

                          【解决方案16】：

                          另一个原因似乎是他们在 TCP 慢启动算法上作弊。

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

                          【讨论】：

                            【解决方案17】：

                            还有algorithms 可以利用硬件功能。比如mapreduce。

                            【讨论】：

                            • MapReduce 不用于响应查询。
                            • MapReduce 在大型机器集群上运行并且具有高度可扩展性：典型的 MapReduce 计算在数千台机器上处理数 TB 的数据。已经实施了数百个 MapReduce 程序，每天在 Google 的集群上执行超过一千个 MapReduce 作业
                            • MapReduce 几乎肯定用于异步索引爬虫数据。如果它位于搜索的关键路径上，我会感到非常惊讶。启动 MapReduce 作业确实会消除延迟。
                            • Henry -- 他们可能会使用它来进行路线/地图的路线规划。但是，是的，对于一般情况。您不希望为了响应常规用户查询而进行任何核心计算。
                            【解决方案18】：

                            如果您对有关 google 集群如何工作的更多详细信息感兴趣，我会建议他们的HDFS 的这个开源实现。

                            它基于谷歌的Mapreduce。

                            【讨论】：

                            • HDFS 是一个分布式文件系统。 mapreduce 克隆称为 Hadoop，可以在 HDFS 或本地文件系统上运行。
                            【解决方案19】：

                            1. 多级数据存储、处理和检索

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

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

                            4. 检索结果的好框架

                            问题摘要中的所有链接总结了所有这些是如何完成的

                            【讨论】：

                              猜你喜欢
                              • 2016-03-19
                              • 1970-01-01
                              • 2013-02-15
                              • 2020-12-19
                              • 2011-06-02
                              • 2012-03-18
                              • 2014-02-21
                              • 1970-01-01
                              • 1970-01-01
                              相关资源
                              最近更新 更多
                              热门标签
                              Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode