英文原文：DuckDuckGo Architecture - 1 Million Deep Searches A Day And?Growing

本文是对Gabriel Weinberg进行的一个访谈，他是 Duck Duck Go的创始人，也是一位大众型的全方位创业导师, 访谈的话题是，2012年中DDG的体系结构是怎样的。

2012年2月份，创新型搜索引擎的新星DuckDuckGo总计有3千万次的搜索，平均一天1百万次。超级投资者Fred Wilson正将其定位为一个干净、专有、公平的快速搜索引擎。 经过同Gabriel的交谈，我赞同Fred Wilson说过的一句话，这句话似乎更加贴近问题的本质：我们是为Rddit以及Hacker News上的无政府主义者才对DuckDuckGo进行投资的。

选用DuckDuckGo不仅仅可以看做是一种技术上的选择，而且也是一种对全面革新的支持。在一个并不是为了爱和友谊，而是为了更加有效地将你卖给广告主才去深入了解你的时代，DDG将自己定位为另辟蹊径不做跟踪的隐私权之守护者。 当然你仍旧要被货币化，但会以一种更加文明和匿名的方式进行。

突出隐私权是个好办法，可藉此找出同Google等搜索引擎相比的竞争优势，因为别的搜索引擎明显在隐私权方面毫无竞争能力。这个我明白。但我发现更值得关注的是DDG在来自大众的（crowdsourced）插件集合方面的强烈愿景。在该愿景中，DDG可以通过将一大群垂直数据供应商结合到DDG的搜索框架中，从而获得更加广泛的搜索覆盖范围。举例来说，专为乐高定制的插件可以针对完整的乐高数据库进行搜索。再比如，如果在你要搜索的内容中有一种香料的名字，DDG就可将其识别出来并可能会触发针对高度优化的菜谱数据库进行更加深入的搜索。每次搜索可以触发多种不同的插件，而且这一切都是实时进行的。

难道所有这些数据不能通过搜索开放的Web获得吗？真的不能。这些数据是具有语义的结构化数据。可不是HTML页面。你需要的搜索引擎是能够对更加丰富的数据集进行分类、映射、整合、过滤、定序、搜索、排版后还要消除歧义，只进行关键字搜索可办不到这些。你需要的是DDG所嵌入他们搜索引擎中的这种智慧。当然这里还有个问题，既然数据已经变得很珍贵了，许多已经成长起来的公司就再也不愿意将这些数据分享出来了。

DDG支持广告，这使DDG处于一种微妙的境地。定向广告（Targeted Ads）赚钱更多，但与此矛盾的是，DDG不做跟踪的策略意味着他们不能收集定向数据。 这个策略对那些关心隐私权的人来说还是一个卖点。但既然搜索是人尽皆知的目的驱动的，DDG将查询进行分类并将它们同数据源进行匹配的技术早已具有了高价值定向的形式。

看看这些因素将产生怎样的效果会非常有意思。但现在让我们先来看看DuckDuckGo是如何实现他们的搜索引擎魔法的……

信息源

• 与 Gabriel Weinberg 的個人访谈。
• 相关文章 下列举的资源。

统计

• 2012 年 02 月的30,000,000 次调查
  
• 平均每天超过 1,000,000 次调查
• 平均每天1,200,000次 API 请求
  

平台

• EC2
• Ubuntu
• Perl & CPAN
• Server Density - 监控
• Solr
• PostgreSQL
• Memcached
• Bucardo - 异步数据库复制系统
• Global Traffic Director - 区域间的负载均衡
• Nginx
• getFavicon - 服务器图票
• daemontools - 管理 Unix 服务的免费工具
• Git
• Asana - project management.
• HipChat - internal communication
• Yammer
• JavaScript
• YUI （正在向 jQuery 迁移）

里面是什么

• Gabriel 这個系统到底是什么样的：
  • 很简单，尽管他们随着时间推移变得越来越复杂。复杂的是所有的壹切都是模。监控工具用于保持服务的运行，所有的壹切都通过 Nginx 运行。有很多不同的服务，但是架构上他们都能够长时间运行。
  • 主要的目标已经 100% 快速达成。降低复杂度有助于达成目标。

源自地下室，搬入AWS（大部分）

• 以前，DuckDuckGo是运行在Gabriel家地下室的. 现在，包括所有前端组件在内的大部分组件都运行于AWS之上。
  • 有些“做持久化的机器”仍在地下室里，象Git库、爬网、Wikipedia实时索引等等这些对零点击连接（zero-click connects）进行更新的部分没有什么不得不搬的理由。
  • 采用了Linode作为翻译之类的一些社区功能的主机。
  • 因为药搬到AWS之上所以从FreeBSD换成了Ubuntu。
• 为了获得更佳的前段性能搬到了多地。这让DDG在哪里速度都很快，这样用户才会来。
  • 速度是用户原先抱怨的原因之一。通过运行在AWS的4个数据中心（位于加利福尼亚、弗吉尼亚、新加坡和爱尔兰），DDG现在可以距离全世界用户更近了。
  • 所有数据中心都运行完全一样的软件
  • DNS使用了全球流量导向器（Global Traffic Director），能够在各区域做负载均衡。DDG倒是想使用更多的区域（南美和另外一个亚洲数据中心），但流量导向器现在仅支持4个区域。
• 完全舍弃了EBS，因为大部分比较大的故障都牵扯到了它。使用EBS时还遇到了性能变化无常问题。
  • 想的是用新的IOP代替它，但体系结构中需要额外更换的部分越少越好。
  • 可能会在将来试用一下PIOP，尽管现在的非EBS体系结构运行得还不错
• 主要运行在超大型的机器之上，因为它们才嘴适合处理较高网络IO流量。总共有4个临时磁盘
  • 超大型机器在基准测试中显示出具有最小的性能波动。
  • 发现用4个临时磁盘（ephemeral disk）比用8个条带（striping）EBS磁盘性能要好。
  • 对高IO实例类型不感兴趣，因为把尽可能多的数据保持在内存中才是我们的目标。高事务处理速率不是问题，数据缓存的也是越快越好。添加机器并也没有发现对IO利用率的提高。
• 中等实例（Medium Instance）用作为开发人员的机器使用。每位开发者都有他们自己的介质开发实例。Staging实例用于测试，足够用来模仿实际环境了。
• 数据中心同步
  • 主要处理只读数据。更新始终都会出来，但不必立即进行。意味着数据中心间的同步不是数据中心的问题。这里没有什么真正的一致性问题。
  • 后端系统（非AWS）有一个主数据库，由它向各区域推送更新。
• 分布式缓存系统采用的是memcached。
  • 高内存的m2.xlarge用于缓存。
  • 大小约100GB, shard到了多台m2.xlarge机器
  • 无论把什么内容放入缓存后，都会让所有其它的缓存系统对相同的内容进行缓存。没有主从之分。
  • 自己定制的Perl解决方案
  • 缓存的通过Nginx分发处理的，所以当数据已在缓存中时的请求将被Perl后端完全忽略。
  • 不受数量约束，可以按需添加很多缓存机器。最难的是找出要把什么放入缓存，缓存才有用并且不会有不好的效果。
  • 致力于更加智能的缓存老化算法（cache aging algorithm）。要看返回的有机链接。一个链接，可以从它相关的片段和域，得到有关它的很多细节。问题是这个信号只有在结果返回回来之后才能拿到，这样的话UI会有点慢，但这对缓存来说意义重大。
  • 在以前，在个区域间正确的同步被给予了较高的优先级。现在，他们正致力于打造更智能的缓存。
• 用到了多种数据库，包括PostgreSQL、Solr、Berkeley以及平面文件（flat file）
  • PostgreSQL replication采用了Bucardo。
  • Solr通过它们自己的进程进行同步，而不是内嵌的replication。
  • PostgreSQL猪服务器放在地下室里，从服务器放在每个区域中。
  • PostgreSQL保存的是即时答案和实体数据。比如，如果你键入的是“duckduckgo”, 你就能得到来自Wikipedia的相关内容，这些来自PostgreSQL
  • PostgreSQL数据库约有来自100个来源的数据。这些数据是由后端出去爬回来后保存到数据库中的。

搜索 —— 情况很复杂

• 高层描述: 设法推测要查询的是哪方面的东西并将该查询交由适当的数据存储（datastore）和API进行处理。在有些情况下还要将其拿回来对其进行并列混合处理。
• 零点击，也即建议性答案框，可采用PostgreSQL、Solr、即时（on the fly）API, 扁平文件（flat file）或者以上技术的某种组合来实现。
• 链尽管顶层链接可能是来自其它来源的，但整个的链接结果都是由API驱动的。链接源包括：Bing、Yahoo、Yandex、Blekko、WolframAlpha等等其它一些搜索引擎.
• 所有的语法分析（parsing）和合并（merging）逻辑都是用Perl实现的。
• 合并的两个层次：后端和客户端。
  • 在后端，对于从不同API获得链接结果的异步请求，都是在它们返回客户端之前进行合并的。 
  • 在客户端，由JavaScript向很可能在不同机器上的模块化的组件发出异步请求，包括广告求求、搜索结果请求以及搜索建议请求。这些请求要分别发送是因为它们具有完全不同的延迟特性。
  • 这些请求中的每一个请求都会被独立到放入缓存。所有能够进行缓存的都要进行缓存。涉一旦涉及外部请求，处理起来都会很慢。立即答案如果已经存在于数据源中，那么返回的速度会非常之快。
  • 通过使用流水线和缓存对请求进行加快处理。
  • 缓存服务器是按区域进行部署的。它们会将尽可能多的数据放入缓存直到缓存慢了为止。这大大提高了响应速度。
  • 缓存命中率的目标是50%。当前是30%。问题出在搜索结果的缓存时长上。当有爆炸性新闻时，搜索结果已经发生变化了，5天前的旧结果没人想要。他们正在试图改进差分式缓存算法（Differential Caching）,也在学习什么时候可以把某些东西缓存一周而不是更长或更短的时间。
  • 搜索建议有较高的缓存命中率，因为他们并不是每个查询都需要进行建议，而且它们还能够缓存更久的时间。
  • 广告不会被缓存。提供商有点击欺骗探测机制。要为广告预留显示的地方，这样当广告可以进行显示时，不会造成整个页面显示的暂时混乱。 对搜索进行内部性能度量（Internal Metrics）要进行缓存，这样页面绘制过程会好很多。
• 仍有Nginx提供所有服务。
  • 由于隐私权方面的原因，他们不进行域外调用，因此所有的东西都是经由他们的Nginx服务器进行代理的。最大的一个例子就是收藏夹图标（favicon）的URL。getFavicon服务用于获得收藏夹图标。收藏夹图标缓存时长为一天，所以不但速度快，而且搜索结果也不会 泄露给内容提供者。
  • Nginx缓存由于有一个bug所以大小很有限。大小大约是一个G。
• DuckDuckHack是个新的立即答案（Instant Answer）平台。
  • 4中插件类型。傻瓜（fathead）型（查询空间中的傻瓜（fat head））指的是PostgreSQL数据存储，基本上就是个关键字数据库。
  • 匹配不要求必须完全一致。立即答案就是个数据库，里面保存着定义、链接分类、歧义消除页面以及他们所支持别一些特色内容。
  • 梦想着吸引更多的小众用户，为这些关心某一特定话题的小众用户提供更好的服务。比如：乐高零件。他们有个乐高零件数据库，因此可以直接在搜索中自动显示零件的图片和零件号。
  • 尽管需求量一直很大，但插件集成起来很困难，因此插件的采用速度比他们预期的要慢。他们还在了解怎么才能让这部分更好的运作起来。
  • 在两个层次上对结果进行过滤。如果使用的是比较严格的触发器（trigger），而且某插件返回一些结果的可能性很高，那么就会在结果页面留有一定空间，在插件将结果返回后就可以将这些结果填入前面留下的空间中。如果相关性很低并且结果往往会被过滤掉，那么就不会在页面中留任何地方，否则看上去页面会有一块打的空白区域。这个过程当中涉及了大量具体问题具体分析的逻辑。
• 搜索引擎的核心决定着如何将搜索交由正确的后端组件进行处理。
  • 这个话题涉及到了知识产权壁垒（Intellectual Property Wall），但可以讨论的细节还有很多。
  • 两种查询：长尾型(long tail)和l胖尾型(fat tail). 胖尾型查询是指针对PostgreSQL进行的查询 而长尾型查询是指针对Solr进行的查询。对于较短的查询，PostgreSQL具有优先权。长尾型在没有别的命中的情况下会填写建议性答案框。
  • 和其它搜索引擎不同，不以机器学习为中心。试探法用于将查询空间划分为几个不同的部分，致力于这些特定的部分以找出如何才能将它们以最好的方式进行分类。
  • 例如：输入Tofu Ginger（豆腐和姜）。基于DDG认为这是个有关香料的查询的事实，香料插件会即时（on the fly）拉进搜索结果，DDG同插件提供商一起协作从DDG的抓取结果中找出比较好的配料关键字。他们的数据存储建有非常具有针对性的分类器，每次搜索时都要运行该它。
  • 有是会触发多个分类。为了对结果进行排序就必须要有一个优先级规则。情况可能会非常复杂。
  • 有些分类器相对简单的多。插件接口支持关键字触发，这个相比较而言就很简单。匹配无须完全一致。比如，相匹配的可以是单词的开头或者结尾部分。这是个哈希（hash）系统。针对所有单词进行基于哈希的匹配。速度真的很快。
  • 正则表达式插件要慢一些。设法转换为哈希或者使用其下包含该正则表达式的更加宽泛的哈希。
  • 核心代码在插件之前运行以进行分类。单个单词的搜索，比如“tofu”（豆腐），更加依赖于傻瓜型插件，而且会首先得到运行并跳过所有其余组件。
  • 情况如此之多，以至于很快就会碰到边界情况（edge case）。
  • 类似“60 minutes”（60分钟）这样的搜索将返回一个歧义消除页面，也就是说，会问你想找哪个“60 minutes”。这个页面来自PostgreSQL。另外会触发一个插件，告诉你叫这个名字的电视剧实际上是在什么播出的。
  • 有对插件进行微调的元语言（meta-language）。比如，可以规定如果数据同该插件匹配，那么，即使已存在另外的即时答案（Instant Answer)，这个数据也很重要，必须显示出来。
  • 赞助商链接并入了微软雅虎搜索联盟（Microsoft Yahoo! Search Alliance）。
  • 在我们例子中所示的查询页面的即时答案框可能会到PostgreSQL和Solr数据库以及其它数据存储进行搜索。 “60 minutes”里的部分，使用JavaScript API到某个service那里去拉取数据。
  • 梦想着即时答案框能有80%的覆盖率，每个创业公司都构建一个插件，以改善针对该创业公司所擅长领域中的数据的搜索结果。其回报就是即时答案所带来的流量，而即时答案还是限于广告显示出来的。并不是所有的信息都显示在即时答案框中。期望能有50%的点击率。
• 搜索建议来自一个完全不同的自制组件（component）。
  • 有些人就是要用与别人不同的词来描述相同的事物。目标是为了不对查询进行重写，只建议怎么做才更好。
  • 比如在“phone reviews”（电话复查）里，将会用telephone代替phone。这步发生在NLP（自然语言处理）组件中。该组件试图找出你说的phone是什么意思，并找出在查询中是否有别的同义词。
  • 想要在这个查询构造组件方面进行更多的探索，但还没有为它找到最佳的UI。
• 有很多盲人发邮件告诉我们有很多可用性方面的问题。很容易一不小心就破坏了可用性，因为很多信息是埋藏在脚本中的。如果弄丢了应当有的标题标签，屏幕阅读器（Screen reader）就可能会很迷惑不知道该读什么了。例如，很容易就把ALT标签忘了放上去了。
• 目标是，通过添加成千上万的搜索源，为所有的东西提供即时答案，从而达到80%的搜索覆盖率。Wikipedia贡献20%。添加更多的长尾可能会升至30%。长尾意味着要搜索的东西没有别的能够完全准确的匹配，但在Wikipedia里的某一段文章中有同要搜索的内容完全匹配的部分。它并不直接同Wikipedia中的某个题目相同，但它出现在Wikipedia之中。
  • Google收购了MetaWeb，藉此来丰富其知识图（knowledge graph）。
  • Google在页面的右侧给出了更多信息。DDG把信息推到了上面部分，给出的信息比Google要少。
  • 何时显示即时答案何时来显示的度量办法是即时答案应该比链接明显好很多才行。把一大堆东西扔到页面右边可能引起某些人的兴趣，但这种做法可不感兴趣。
• 过滤器泡泡（Filter Bubble）。当你点击了一个链接后，就会有更多类似这个链接的链接显示给你。你的点击和搜索历史将你锁定到了一个过滤器泡泡之中了。你会看到越来越多的你所认可的东西。搜索和点击历史不用来定位结果，过滤器泡泡就破了。他们可能会在将来提供这个功能，但这需要该功能入选之后才能进行。

开发

• 团队中50%的员工远程工作，10-15全职，20-25员工兼职。
• Git 作为版本控制工具。使用tags作为发布标记。一套复杂的部署系统可以将软件部署到所有机器安装。
• 每个开发者都有一个中等云端环境的实例。
• 使用Asana作为项目管理工具
• 使用HipChat 和 Yammer 即时交流
• 前端开发直接使用javascript，考虑迁移到YUI或者是JQuery

货币化侧率策略 ——  广告

• 目标是不添乱，因此要将广告量减到最少的程度。要是广告能有用，它们实际上还能对搜索结果起到改善的作用。
• 广告在能更好的定向之前，不会再增加了。这需要有得到更好的广告网络后端的支持。
• 还没有太多好的搜索广告反馈，所以选项还不太多。要真正的在搜索空间分发广告，还需要大量的广告主。可以将一整类的查询，比如金融类的查询，组成一组，但这样一来，广告习惯性就会变得不太高了。
• 对广告主在DDG上进行竞争的激励还不高，因为相对其它搜索引擎来讲，他们在DDG得到的回报也不高。
• 具有比以往更多的开放性的数据，但仍有一些类型的数据还处于被封锁状态，无法通过插件获得，比如：机票、电影、体育赛事等数据。还有公司垄断了一些数据，因为这些数据涉及其核心业务。通常创业型公司更愿意分享他们的数据。
• 搜索提供商还没有要求必须使用某特定的广告网络。

听众所提的问题

• 延迟管理？
  • 尽可能对请求进行最大程度的管道化。
  • 受Amazon的网络的限制，但主要问题在于将主要的东西分割到不同的区域。
  • 使用异步策略。
  • 利用缓存。
  • 正在Nginx之上对SPDY协议进行评估
• 伸缩性方面最大的挑战？
  • 还没有碰到那么大的事，主要因为他们对整个体系结构进行了模块化。拿下一个模块并让其独立运行相当的直截了当。前端的需求进行了单独处理。只需改变主机名，将前端部分指向别处即可。
  • 降低必需的数据集（dataset）复制（replication）方面的复杂性，尽最大可能让数据集保持为只读状态。
• 如果Yahoo和Bing停止向你们提供服务怎么办？
  • 除了他们还有别的一些提供商，所以短期讲这不是问题。
  • 一般来说，随着时间推移这种风险会逐渐降低，这是因为DDG正在从Google手中夺取市场份额，这对这些公司来讲也是有价值的。还有，DDG使用的就是他们的广告网络。
  • DDG没有被视作对他们的一个威胁，所以不太可能出现这种情况。
• 将来你们能挣够维持生计的钱吗？
  • 不用担心！
  • 搜索广告很赚钱。他们希望通过让广告变得更有价值，以赚取更多的钱。
  • 他们采用的方式费用没有那么高昂，也不需要亿万美元才能运营下去。
• 你们计划怎么做才能长期的与Google保持不同？
  • 集中注意力于Google无法轻松拷贝的那些特性和功能，Google无法拷贝这些特性和功能的原因不在由于技术问题，而是因为业务和文化方面的原因它做不到。
    • 长尾答案功能
    • 真正的隐私权
    • 页面干净整洁 —— 链接结果里不插入从其它特性获得的链接，所以可以保持整洁。
    • 更积极的移除垃圾信息（spam）。Google在这方面做的不够好。
  • 即时答案对移动设备来讲非常棒。正在编写新的移动设备应用程序，但在应用分发方面移动设备更具挑战性。说应用分发有挑战是因为手机都有内置的搜索提供商，内置是在使用方面具有最小抗拒性的路径。即时搜索真的真的不错的应用，让人们使用它的难度也不小。Siri就是另一个让你的搜索变得更加难以为人们作用的例子。

经验教训

• 保持简单. 他们没有使用一大堆的负载均衡器和大量的子系统。对组件进行模块化使得它们可以具有相对独立性。
• 用户很关心性能。通过在多个区域进行复制拉近同用户的距离，采用一个缓存层可以大大提高性能。
• 启用缓存仅仅是万里长征第一步。一旦开始使用缓存，就不得不找出缓存的最佳结构以及缓存数据的有效时长。缓存中的数据保持的时间太长后用户得到的结果会很糟糕。所以数据应该按照具体的缓存侧率进行分类。
• 最大只读（Read-mostly）体系结构非常好。 DDG所采用的方法的健壮性（robustness）很大一部分原因就是因为他们有大量只读数据集。
• 来自大众的插件（crowd sourcing plugin）可以得到更广泛的搜索覆盖率，这个主意非常好。将来自如此之多的数据源以实时的方式集成起来非常具有挑战性，但是，做一个能够适当地处理如此众多类型数据的搜索引擎，这个愿景非常美好。让我们祝愿大家不会毁了这个计划吧。
• 使用如此众多的第三方服务既有优势也有劣势。优势之处在于有了这些联盟DDG就能得到他们以前无法得到的更多的数据。这有点象弱国联合了其它更弱的国家以对比较强大的国家进行抗衡。劣势在于这使得系统比较难以设计。因为信息的各个来源都具有比较高的延迟，还必须将它们合并到一起，让它们看起来好戏是一个统一的整体一样。
• 启发式的工作方式。 最后得到的体系结构基于了一套非常复杂的规则，但采用启发式的方法就可以对来所有不同搜索结果源之间的关系进行微调。其中的技巧在于拿到一个查询后要将其正确的分给所有的插件。干得好的话就能得到一个同通用的机器学习方式相比更好的解决方案，但如有闪失就会陷入困境。
• 同巨头进行竞争时需要的是竞争角度。  DDG追求的功能和特性是他们认为Google不想拷贝的功能和特性，他们也在将费用保持在较低水平，从而能够在更加合理的收益情况下有足够的经费保持正常运营。
• 移动设备挑战和机遇并存。 移动设备内置了搜索引擎，这样竞争起来就很困难。具有讽刺意味的是，即时答案是移动设备最好的一个功能，因为无需查看页面里大量的文字就能得到想得到的内容。The irony is Instant Answers is a great mobile feature because you don’t need to page through a lot of text to get to what you want.

非常感谢Gabriel Weinberg花时间做了此次访谈。他既耐心又坦率，回答了很多问题。我们有点超时，但我想结果表明这是值得的。DuckDuckGo正在寻找一点应用开发人员，看看你有没有兴趣。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务