# DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
> 原文: [http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html](http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html)
![](https://img.kancloud.cn/8b/b0/8bb0bc3137a14241c18b1d7c76a2b15b_202x160.png) *这是对 [Gabriel Weinberg](https://twitter.com/yegg) , [Duck Duck Go](https://duckduckgo.com/) 的创建者和一般[的创始人的访谈,内容涉及创业大师](http://www.gabrielweinberg.com/blog/),关于 DDG 的架构是什么样的 在 2012 年。*
创新的搜索引擎新贵 DuckDuckGo 在 2012 年 2 月获得了 [3000 万次搜索](https://duckduckgo.com/traffic.html) ,平均每天超过 100 万次搜索。 [超级投资者 Fred Wilson](http://www.avc.com/a_vc/2012/02/duck-duck-go-passed-1mm-searches-per-day.html) 将其定位为干净,私有,公正且快速的搜索引擎。 与加布里埃尔交谈之后,我喜欢弗雷德·威尔逊(Fred Wilson)先前所说的话,这似乎更接近问题的核心: [我们为 Reddit,Hacker News 无政府主义者](http://venturebeat.com/2012/05/21/fred-wilson-duckduckgo-reddit-hacker-news/) 投资了 DuckDuckGo。
选择 DuckDuckGo 不仅可以视为一项技术选择,而且可以视为一场革命的投票。 在这个时代,您知道自己的本质不关乎爱情或友谊,而是更有效地将您卖给广告商,因此 DDG 将自己定位为 [不追踪替代方案](http://whatisdnt.com/) , [隐私标记](https://duckduckgo.com/privacy)。 当然,您仍然可以通过获利来获利,但方式会更加文明和匿名。
推进隐私权是一种与 Google 等人竞争的利基市场的好方法,因为从定义上讲,他们永远无法在隐私权上竞争。 我明白了。 但是我发现最引人注目的是 DDG 的强大愿景,即将一群垂直数据供应商捆绑到他们的搜索框架中,从而使众包插件网络提供更广泛的搜索范围。 例如,有一个专门的 Lego 插件,可针对完整的 Lego 数据库进行搜索。 例如,在您的搜索查询中使用香料的名称,然后 DDG 会识别出它的名称,并可能触发对高度调整的配方数据库的更深入的搜索。 每次搜索都可以触发许多不同的插件,这些插件都可以实时处理。
无法搜索 Open Web 提供所有这些数据吗? 不完全是。 这是具有语义的结构化数据。 不是 HTML 页面。 您需要一个能够对更丰富的数据集进行分类,映射,合并,过滤,确定优先级,搜索,格式化和消除歧义的搜索引擎,而关键字搜索无法做到这一点。 您需要 DDG 在其搜索引擎中内置的智能工具。 当然,现在的问题之一是,数据已经变得非常有价值,许多成年人不再愿意共享它们。
获得广告支持会使 DDG 处于棘手的位置。 定向广告更有利可图,但具有讽刺意味的是,DDG 不跟踪政策意味着它们无法收集定向数据。 对于那些对隐私感兴趣的人来说,这也是一个卖点。 但是,由于搜索是出于意图驱动而著名的,因此 DDG 的对查询进行分类并将其与数据源进行匹配的技术已经成为一种高价值的定位方式。
看到这些力量如何发挥作用将令人着迷。 现在,让我们看看 DuckDuckGo 如何实现他们的搜索引擎魔力...
## 信息源
* 对 Gabriel Weinberg 的个人采访。
* 在 **相关文章下列出的资源。**
## 统计资料
* 2012 年 2 月的 3 千万次搜寻
* 每天平均超过一百万次搜索
* 每天 12M API 请求
## 平台
* EC2
* Ubuntu
* Perl & CPAN
* [服务器密度](http://www.serverdensity.com/) -监控
* Solr
* PostgreSQL
* Memcached
* [Bucardo](http://bucardo.org/) -异步 PostgreSQL 复制系统
* [全球流量管理器](http://www.dnsmadeeasy.com/services/global-traffic-director/) -区域之间的负载平衡
* Nginx
* [getFavicon](http://getfavicon.appspot.com/) -提供收藏夹图标
* [daemontools](http://en.wikipedia.org/wiki/Daemontools) -用于管理 Unix 服务的免费工具
* 转到
* [Asana](http://asana.com/) -项目管理。
* HipChat-内部通讯
* Yammer
* JavaScript
* YUI(移至 jQuery)
## 内部内容
* Gabriel 喜欢他们的系统:
* 非常简单,尽管随着时间的推移它们变得越来越复杂。 一切都是模块化的,可以减轻复杂性。 Daemontools 用于保持服务运行,一切都通过 Nginx 运行。 有很多不同的服务,但是架构使它们都保持不变。
* 主要目标是 100%的正常运行时间和速度。 降低复杂度有助于实现这两个目标。
## 走出地下室并进入 AWS(主要是)
* DuckDuckGo 过去耗尽了加百利的地下室。 现在,大多数组件(包括所有前端组件)都在 AWS 上。
* 一些“持久性机器”仍然存在于地下室,因为没有令人信服的理由来移动这些组件,例如 Git 存储库,爬网以及更新[零点击连接](http://dhruvbird.com/ddb/zc.html)的实时 Wikipedia 索引。
* Linode 用于托管一些社区功能,例如翻译。
* 作为迁移到 AWS 的一部分,从 FreeBSD 迁移到 Ubuntu。
* 移动到多个区域以获得更好的前端性能。 使 DDG 遍地快速,用户将来。
* 用户抱怨的一项是速度。 通过在 4 个 AWS 数据中心(加利福尼亚,弗吉尼亚,新加坡,爱尔兰)中运行,DDG 可以更接近其全球用户。
* 相同的软件在所有数据中心中运行。
* Global Traffic Director 用于其 DNS,并在区域之间平衡用户负载。 DDG 希望使用更多的区域(南美和另一个亚洲数据中心),但是 Traffic Director 目前仅在四个区域工作。
* 由于 EBS 参与了大多数大型故障,因此完全退出了 EBS。 EBS 也经历了性能差异。
* 本来应该可以使用新的 Provisioned IOP,但是在体系结构中具有较少的额外移动部件会更好。
* 尽管当前的非 EBS 体系结构运行良好,但将来可能会尝试使用 PIOP。
* 主要在超大型计算机上运行,因为它们似乎是网络高 IO 的最佳选择,并且它们具有 4 个临时磁盘。
* 基准测试表明,超大型机器的性能差异最低。
* 发现 4 个临时磁盘的性能比条带化 8 个 EBS 磁盘的性能要好。
* 对高 IO 实例类型不感兴趣,因为目标是在内存中保留尽可能多的数据。 高事务处理率不是问题,并且数据将尽快缓存。 另外,机器的 IO 使用率也不高。
* 中型实例用于开发人员计算机。 每个人都有自己的中等开发实例。 临时实例用于测试,足以模拟实际环境。
* 数据中心同步。
* 主要处理只读数据。 更新会一直发布,但不必立即发布。 意味着数据中心之间的同步不是数据中心问题。 确实没有任何一致性问题。
* 后端系统(非 AWS)具有主数据库,可将更新推送到区域。
* 分布式缓存系统使用 memcached。
* 高内存 m2.xlarge 用于缓存。
* 大小约为 100GB,在 m2.xlarge 机器上分片。
* 缓存某些内容时,它将推送到所有其他缓存系统。 没有主人。
* 自定义 Perl 解决方案。
* 缓存是通过 Nginx 路由的,因此如果数据在缓存中,请求将完全绕过 Perl 后端。
* 不受大小限制,它们可以根据需要添加任意数量的缓存计算机,挑战是弄清楚要放入缓存中的内容,这样将很有用,并且不会产生不良结果。
* 研究更智能的缓存老化算法。 查看返回的有机链接。 您可以从其相关的代码片段和域中找到很多有关链接的信息。 问题在于此信号仅在结果返回后才可用,因此 UI 速度较慢,但对缓存非常有用。
* 优先考虑的是在所有区域中正确同步。 现在,他们将致力于制作更智能的缓存。
* 使用了许多数据库,包括 PostgreSQL,Solr,Berkeley 和平面文件。
* Bucardo 用于 PostgreSQL 复制。
* Solr 同步是通过自己的过程进行的,而不是内置的复制。
* PostgreSQL 主服务器在地下室,而从服务器在每个区域。
* PostgreSQL 保存即时答案和实体数据。 例如,如果您输入“ duckduckgo”,那么您会从 Wikipedia 中获得某些东西,而这是来自 PostgreSQL 的。
* PostgreSQL 数据库有大约 100 个数据源。 这些由后端爬网并存储在数据库中。
## 搜寻-非常复杂
* 高级别:尝试弄清楚查询的含义,然后将其路由到适合该查询的适当数据存储区和 API。 在某些情况下,请将其带回,并行化并混合在一起。
* 零点击实例答案框可以由 PostgreSQL,Solr,即时 API,平面文件或组合提供动力。
* 链接结果是由 API 驱动的,尽管顶部链接可能来自其他来源。 [链接源包括](http://help.duckduckgo.com/customer/portal/articles/216399-sources) :Bing,Yahoo,Yandex,Blekko,WolframAlpha 等。
* 所有解析和合并逻辑都在 Perl 中。
* 合并的两个级别:后端和客户端。
* 在后端,将来自不同 API 的对链接结果的异步请求合并,然后再将其返回给客户端。
* 在客户端上,向可能在不同计算机上的模块化组件发出了异步 JavaScript 请求。 包括广告请求,搜索结果,搜索建议。 由于它们具有不同的延迟,因此将它们保持分开。
* 这些请求均独立缓存。 可以缓存的所有内容都会被缓存。 任何涉及外部请求的操作都可能很慢。 如果来自他们的数据存储区,Instant Answer 将很快返回。
* 通过流水线化和缓存可以更快地发出请求。
* 缓存服务器是按区域划分的,它们会尝试尽可能多地填充它们。 大大缩短了响应时间。
* 目标缓存命中率为 50%。 目前为 30%。 问题是结果被缓存的时间长度。 结果会发生变化,因此,当您遇到突发新闻时,您不希望出现 5 天前的结果。 他们正在尝试提高 差异缓存 的性能,学习何时将某些内容缓存一周而不是更长或更短。
* 搜索建议的缓存命中率更高,因为并非每次查询都出现,并且可以缓存更长的时间。
* 广告未缓存。 供应商具有点击欺诈检测功能。 广告会留有空间,因此,当广告可用时,页面显示不会出现毛刺。 缓存有关搜索的内部指标,以便更好地呈现页面。
* Nginx 仍然可以提供所有服务。
* 由于出于隐私方面的考虑,他们不想在其域外拨打电话,因此所有路由和代理均通过其 Nginx 服务器进行路由。 最大的示例是 URL 的图标。 getFavicon 服务用于获取网站图标。 它们被缓存了大约一天,因此速度很快,因此搜索结果不会 [泄漏给提供者](http://www.gabrielweinberg.com/blog/2011/01/search-leakage-is-not-fud-google-et-al-please-fix-it.html) 。
* Nginx 缓存由于错误而受到限制。 大小约为一档。
* [DuckDuckHack](http://duckduckhack.com/) 是新的即时应答平台。
* 4 种插件类型。 Fathead 类型(查询空间的胖头)是 PostgreSQL 存储,它实际上是关键字数据库。
* 比赛不一定要完全击中。 它是定义,链接类别,消歧页面以及它们具有的许多其他功能的大数据存储。
* 梦想是吸引更多的细分受众,以更好地为关心特定主题的人们提供服务。 例如:乐高零件。 例如,有一个乐高零件数据库。 零件图片和零件编号可以通过搜索自动显示。
* 很难集成插件,因此尽管有很多需求,但采用速度比他们希望的慢。 仍在学习如何使其最佳发挥作用。
* 对结果进行两个级别的过滤。 如果使用了严格的触发器,并且插件返回某些内容的可能性很高,那么结果的页面上将留有空间,并在结果返回时进行填充。 如果相关性很低并且结果经常被过滤掉,那么就不会再有空格了,因为页面上似乎有很大的空白。 涉及很多个案逻辑。
* 引擎的核心正在决定如何将搜索路由到正确的后端组件。
* 这个主题上有一个知识产权墙,但仍有许多细节。
* 两种查询:长尾巴和胖尾巴。 粗尾查询针对 PostgreSQL,长尾查询针对 Solr。 对于较短的查询,PostgreSQL 优先。 长尾填补了“实例答案”的所有其他内容。
* 不像其他搜索引擎那样以机器学习为中心。 启发式用于将查询空间划分为不同的部分,它们专注于那些特定的部分以找出如何最好地对其进行分类。
* 示例:输入豆腐生姜。 香料插件会根据 DDG 认为这是食谱搜索的事实,即时获取结果。 DDG 与插件提供商合作,从其抓取中提取好成分关键字。 为它们的数据存储区构建了一个非常具体的分类器,它们在每个查询上运行。
* 有时会触发多个类别,并且它们必须是优先顺序才能对结果进行排序。 会变得很复杂。
* 一些分类器要简单得多。 插件接口支持关键字触发器,这相对简单。 比赛不一定是准确的。 例如,匹配可以在单词的开头或结尾。 它是哈希系统。 您查看所有单词并根据哈希进行匹配。 真快。
* 正则表达式插件较慢。 尝试转换为哈希,或在其下使用带有正则表达式的更广泛的哈希。
* 核心代码在插件执行之前运行,以进行分类。 像“豆腐”这样的单词查询更多地依赖于 the 头。 首先运行,其余所有短路。
* 有很多情况,您很快就会陷入困境。
* 诸如“ 60 分钟”之类的查询会产生歧义,这意味着它询问您是指哪个“ 60 分钟”,这是来自 PostgreSQL 的。 还触发了一个插件,可在节目实际播放时为您提供。
* 存在用于调整插件的元语言。 例如,假设数据是否与此插件匹配,那么即使有另一个即时答案,数据也足以显示。
* 赞助商链接被联合到 Microsoft Yahoo! 搜索联盟。
* 在我们的示例查询页面中,“即时答案”框可能转到 PostgreSQL 和 Solr 数据库以及其他存储。 “ 60 分钟”部分,该部分实时进行服务,以使用 JavaScript API 提取数据。
* Dream 要在 Instant Answers 中获得 80%的覆盖率,每个初创公司都将创建一个插件,以利用其专业的数据来改善搜索结果。收益是流量,因为即时答案甚至显示在广告上方。 并非所有信息都显示在框中。 预计点击率将达到 50%。
* 搜索建议来自一个完全不同的本地组件。
* 有些人对事物使用不同的单词。 目标不是重写查询,而是提供有关如何做得更好的建议。
* 例如,“电话评论”将用电话代替电话。 这是通过 NLP 组件发生的,该组件试图弄清楚您的电话意思以及查询中是否应该使用任何同义词。
* 希望探索更多此查询构建组件,但尚未找到最佳的 UI。
* 许多盲人用户写有关可用性问题的文章。 由于信息隐藏在脚本中,因此很容易意外破坏可用性。 屏幕阅读器可能对呈现的内容感到困惑,因为需要适当的标题标签。 例如,很容易忘记放入 ALT 标签。
* 目标是通过添加 1000 多个来源以提供所有内容的即时解答,以达到 80%的搜索覆盖率。 维基百科使您达到 20%。 添加更多的长尾巴,您最多可以得到 30%。 长长的尾巴表示它与任何内容都不完全匹配,但是 Wikipedia 中有一段与该问题完全匹配。 它不会直接打到 Wikipedia 主题,而是在 Wikipedia 中。
* Google 收购了 MetaWeb 作为填写其知识图谱的手段。
* Google 在页面右侧有更多信息,并显示更多信息。 DDG 将信息推到顶部,而信息却更少。
* 何时显示即时答案的标准是,它们应该比链接要好得多。 在 DDG 右手边扔很多可能对某人感兴趣的东西。
* 滤泡。 当您单击一个链接时,会显示更多类似该链接的链接。 您的点击和搜索历史记录将您锁定在过滤器气泡中。 您会看到越来越多的内容。 搜索和点击历史记录不用于定位结果。 过滤器气泡破裂。 他们可能会在将来提供此功能,但必须选择加入。
## 开发
* 团队处于 50%远程状态。 全职 10-15 人。 20 至 25 人是固定供款人。 有些人在兼职做非常具体的功能。 对他们来说很棒。
* 用于源代码控制的 Git。 使用标签发布。 部署系统可以访问所有计算机并安装软件。 自插件启动以来,情况更加复杂。
* 每个开发人员都有一个中等云实例。
* Asana 用于项目管理。
* HipChat 和 Yammer 用于内部通信
* 前端开发使用很多底层 JavaScript。 从 YUI 迁移到 jQuery 的思考。
## 获利策略- [广告](http://help.duckduckgo.com/customer/portal/articles/216405-advertising)
* 目标是避免混乱,因此请尽量减少广告。 如果广告有用,那么它们实际上可以改善结果。
* 在广告定位更精准之前,不会有更多的广告。 这将需要更好的广告网络后端。
* 搜索广告供稿不多,因此选择不多。 要在搜索空间中实际投放广告,您需要大量的广告客户。 可以将整个查询类别组合在一起,例如财务查询,但随后广告变得不那么相关了。
* 考虑到与其他搜索引擎相比,广告商在 DDG 上投放广告系列的动机仍然很低。
* 开放数据比以往任何时候都多,但是仍有一些数据被锁定并且无法通过插件获得:飞行,电影和体育。 有些公司对数据拥有垄断权,这就是他们的业务。 初创企业通常更愿意共享数据。
* 搜索供应商没有要求使用特定的广告网络。
## 观众提问
* 延迟管理?
* 可能时管道请求。
* 受亚马逊网络的限制,但主要的事情是将事物分成不同的区域。
* 使用异步。
* 使用内存缓存。
* 为 Nginx 评估 SPDY。
* 最大的扩展挑战?
* 没什么大不了的,主要是因为他们已经对架构进行了模块化。 拆下组件并放入其自己的堆栈很简单。 前端需求是单独完成的。 只需更改主机名,然后指向其他位置即可。
* 降低必要的数据集复制的复杂度,并尝试使其尽可能保持只读。
* 如果 Yahoo 和 Bing 关闭您会怎样?
* 还有其他提供商,因此没有即时问题。
* 总体而言,风险随着时间的推移而降低,因为 DDG 是这些公司的资产,因为 DDG 正在从 Google 手中抢占份额。 DDG 正在使用他们的广告网络。
* 未被视为威胁,因此不太可能出现结果。
* 您会赚足够的钱生存吗?
* 不用担心!
* 搜索广告可赚钱。 他们希望通过减少他们的 cr 脚,使他们更有利可图。
* 他们的方法并没有那么昂贵。 他们不需要赚大笔的钱就可以继续营业。
* 从长远来看,您如何计划与 Google 脱颖而出?
* 专注于 Google 无法轻松复制的功能,并非出于技术原因,而是出于商业和文化原因。
* 长尾答案功能。
* 真正的隐私。
* 缺乏混乱-链接结果不会因其他属性的插入而混乱,因此请保持干净。
* 更积极地删除垃圾邮件。 Google 做得不好。
* 即时答案在移动设备上很棒。 构建新的移动应用程序,但是移动设备在发行方面更具挑战性。 所谓分发,是指电话具有内置的搜索提供程序,这是使用阻力最小的途径。 即使使用非常出色的搜索应用,也很难吸引人们使用它们。 Siri 是使搜索难以使用的另一个示例。
## 获得的经验教训
* **保持简单** 。 他们没有大量的负载均衡器和许多子系统。 模块化组件,使其独立。
* **用户关心性能** 。 通过复制到多个区域并包括一个缓存层,使其更接近用户,从而大大提高了性能。
* **缓存只是故事的开始** 。 缓存后,您必须找出如何最好地构造缓存以及何时使数据过期。 保留数据的时间过长,用户将获得不良结果。 因此,必须将数据仔细分类为特定的缓存策略。
* **只读架构很不错** 。 DDG 方法的强大功能是因为它们具有很大程度上只读的数据集。
* [**众包插件**](http://idealab.talkingpointsmemo.com/2012/05/duckduckgo-wants-developers-to-hack-its-search-results.php) **获得更大的搜索范围是一个好主意**。 实时集成这么多数据源将是一个很大的挑战,但是拥有一个能够正确处理这么多种不同类型数据的搜索引擎的愿景真是太棒了。 希望世界不会破坏计划。
* **使用这么多第三方服务是优势和劣势** 。 之所以有实力,是因为这些联盟使 DDG 能够访问比以往更多的数据。 就像一个较弱的国家与其他较弱的国家结盟,共同对抗一个较大的国家。 不利之处在于,由于信息源具有更高的延迟,必须将它们合并在一起以使一切看起来像一个统一的整体,因此使系统的设计更加困难。
* **启发式工作** 。 您最终会遇到一个复杂的基于规则的体系结构,但是启发式方法可以让您微调所有不同搜索结果源之间的关系。 诀窍是获取查询并将其正确映射到所有插件。 与普通的机器学习方法相比,做得好是一个非常有价值的解决方案,当它碰上时会很棒,但是错过时会卡住。
* **与巨人** 竞争时,您需要一个角度。 DDG 正在追求他们不希望 Google 复制的功能,并保持较低的成本,以便他们有能力继续获得更合理的收入。
* **移动是挑战和机遇** 。 移动设备上的搜索引擎锁定使其难以竞争。 具有讽刺意味的是,“即时答案”是一项出色的移动功能,因为您无需分页浏览大量文本即可找到所需内容。
非常感谢 Gabriel Weinberg 抽出宝贵的时间进行采访。 他非常有耐心,对答案很开放。 我们花了很长时间,但我认为结果值得。 如果您有兴趣,DuckDuckGo 正在寻找移动开发人员。
## 相关文章
* [关于黑客新闻](http://news.ycombinator.com/item?id=5129530)
* [Duck Duck 在 Twitter 上转到](https://twitter.com/duckduckgo)
* [2009 Duck Duck Go Architecture](http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-architecture.html) ( [Hacker News](http://news.ycombinator.com/item?id=525048) )
* [2011 架构更新](http://help.duckduckgo.com/customer/portal/articles/216392-architecture)
* [DuckDuckGo 过去用光了我的地下室](http://www.gabrielweinberg.com/blog/2011/12/duckduckgo-used-to-run-out-of-my-basement.html)
* [用 Perl 编写的 Duck Duck Go](http://news.ycombinator.com/item?id=1500487)
* [用 Bucardo 复制 PostgreSQL](http://www.gabrielweinberg.com/blog/2011/05/replicating-postgresql-with-bucardo.html)
* [PostgreSQL 技巧和窍门](http://www.gabrielweinberg.com/blog/2011/05/postgresql.html)
* [nginx JSON 骇客](http://www.gabrielweinberg.com/blog/2011/07/nginx-json-hacks.html)
* [我是我自己经营的搜索引擎(Duck Duck Go)的创始人,AMA](http://www.reddit.com/r/IAmA/comments/bbqw7/i_am_the_founder_of_a_search_engine_duck_duck_go/)
* [DuckDuckGo 爆炸](http://news.ycombinator.com/item?id=3770958) -关于 DDG 流量增加的黑客新闻讨论
* [Gabriel Weinberg 的博客](http://www.gabrielweinberg.com/blog/) -在创业公司和其他主题上经常要说的有趣的事情
* Tech Spot [DuckDuckGo 创始人加布里埃尔·温伯格的访谈](http://www.techspot.com/article/559-gabriel-weinberg-interview/)
* [DuckDuckGo 创始人加布里埃尔·温伯格(Gabriel Weinberg)谈论创建更多私有搜索引擎](http://techland.time.com/2012/03/23/duckduckgo-founder-gabriel-weinberg-talks-about-creating-a-more-private-search-engine/)
* [在搜索引擎中隐藏 Google](http://articles.washingtonpost.com/2012-11-09/business/35505935_1_duckduckgo-search-engine-search-results)
* [没有目标广告的 Google 的免费跟踪替代品](http://www.heavychef.com/search-engines-a-track-free-alternative-to-google-with-no-targeted-ads/)
* [Duck Duck Go 开源](https://github.com/duckduckgo/duckduckgo/wiki) -DDG 是封闭源,但具有一些开放源代码组件
* [DataSift 架构:每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html)
* [Google 和搜索的未来:阿米特·辛格(Amit Singhal)和知识图](http://m.guardiannews.com/technology/2013/jan/19/google-search-knowledge-graph-singhal-interview)
* [DuckDuckGo 可以挑战在位搜索冠军吗?](http://www.business2community.com/seo/can-duckduckgo-challenge-the-reigning-champions-of-search-0382883)
@Gabriel Weinberg:
好的帖子。 谢谢! :)
为什么不将 Rout 53 用于全局 DNS? 我认为它的区域比 Global Traffic Director 多,不是吗?
这肯定是一篇精彩的文章! 大量和合成。 深入了解 DDG 使我意识到每个方面都有多么复杂。
首先,我已经进行了 6 个月的测试,最后才恢复使用 Mountain View 的功能。 用英语使用 DDG 通常是准确的,但是以我的语言(法语)显示的结果不够可靠。 现在,我了解到,映射和合并数十个源以及它们的元数据,实时翻译所有内容都是一项艰巨的任务。
然后,让我将“一个投诉用户**认为**太快”改成“加布里埃尔,请到欧洲旅行,每次搜索都享受±.5s-±.8s 的时间。我认为亚马逊的网络速度更快( 好吧,考虑到我当地的 Amazon 商店的性能),但是一天要进行±50 次搜索,有时我不得不重新输入“!g < search >”,以便在非常简单的搜索(例如商店名称, 知名品牌或艺术家)。
最后,几乎没有与法语查询相关的广告。 这非常舒适,但我想还不能使收入最大化。
我希望 DDG 能够在所有语言和所有大洲不断进步,并且我会不时检查...
感谢您的采访!
感谢您的文章。 它们用于离线数据处理?
很棒的文章! 对您为什么选择 Ubuntu 而不是 AWS 中提供的其他免费 Linux 操作系统有任何见解? 例如,Fedora,OpenSUSE,Amazon Linux?
很生气的 DDG 不支持 IPv6。 bing,yahoo 和 google 支持 IPv6。...DDG 向后。
Gabriel-您愿意在 Lucene / Solr Revoltuion 上发表有关 DDG 如何使用 Solr 的论文吗? 我很肯定社区会很感兴趣。 Lucene / Solr Revolution 将于 4 月底在圣地亚哥举行。 我们已经将您的博客发布到 SearchHub.org 上,这是所有 Lucene / Solr 的地方。
theipv6guy:
就我而言,就 IPv6 而言,这是一些相当有力的评论。 DuckDuckGo 使用 AWS,仅在某些产品上支持 IPv6。 正如我希望 DDG 赶上潮流一样,我不怪他们没有转换托管服务提供商,甚至只是在一切面前 shoe 脚 Akamai 或双栈 ELB。
您应该将怒火引向亚马逊。
(不过,是否在其 Linode 上启用了 IPv6?:D)
很棒的帖子,谢谢。 有关我所遇到的问题和我没有遇到的问题的许多详细信息。
优秀的文章。 我不了解所有技术,但细节令人着迷。
很难击败 Google。 干净利落。
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训