原理

传统搜索引擎的基本原理是遍历整个互联网上开放的HTML页面。随后，对这些页面的内容数据进行拆解、分词，把它们作为索引项存储在数据库中。那么在用户进行搜索时，就会利用pagerank算法，根据字频、网页日期、网站权重、是否为客户购买的关键字、是否为作弊网页、是否为标题文字等一系列规则将内容排序并呈现出来。

第一点不同：在后端，DuckDuckGo对所得到的数据进行了清洗、合并、分类、映射、排序和消除歧义的工作，将这些数据按照类别存放在PostgreSQL,、Solr、Berkeley和flat files这些关系型数据库中。当用户进行搜索时，DuckDuckGo做的不仅仅是关键词匹配，而是分析用户的语义，了解用户真正想要什么。再针对用户的搜索意愿调用关系型数据库中的内容。

第二点不同：你用搜索引擎查东西想要的当然是答案，而不是一堆的蓝色链接。DuckDuckGo 一开始就想到专注于为网上的信息查找打造出色的体验。它把脏累活（web 信息索引）留给了不同来源的第三方搜索引擎，而致力于为人们的查询提供即时答案。在即时答案的下方，DuckDuckGo 还聚合 Bing、Yandex 等第三方搜索的连接，并对其进行过滤和重组，减少了垃圾链接。通过接入许多其他网站的搜索API，这些网站能帮助其提供相关领域较为精准的内容。同时，通过简单的“内容+！Bang”命令选择你需要调用的API，可以做到站内搜索。例如我在搜索框内输入“Kindle ！a”，就能直接搜索Amazon内与Kindle相关的内容，输入“Ray Allen !gi”就能直接利用Google Image搜索Ray Allen的照片，输入“DuckDuckGo ！W”就能直接呈现其维基百科页面。在这一层面上，我认为可以把DcukDuckGo想象为许多个垂直搜索引擎的合集。

第三点不同：DuckDuckGo 的查询不需用户账号，默认情况下不记录 IP，也没有搜索 cookie 跟踪用户搜过什么，在网上逛过什么地方，DuckDuckGo 不会保留用户的搜索历史，用户点击 DuckDuckGo 搜索结果上的链接时，目标网站也看不到用户使用的搜索词，DuckDuckGo 甚至还配备了自己的 Tor 出口中继，帮助 Tor 用户提高搜索性能。

第四点不同：DuckDuckGo 依靠第三方数据来源的糅合以及日益壮大的用户及开发者社区的深厚知识来帮助让答案更准确。

除了上述四个方面外，DuckDuckGo还推出了针对对细分领域的搜索——DuckDuckHack，开发者可以为DuckDuckGo开发这些搜索插件，当你安装这些插件后，就可以利用它直接进行一些垂直搜索，例如歌词搜索、Twitter搜索等。

搜索

• 高水平：首先弄清楚用户查询的是什么，然后将其路由到相应的存储数据或者适当的API，在某些情况下还需要把它带回来，对其进行并行化或者混合处理。
• 链接结果是由API驱动，虽然顶部链接可能来自于其他来源。这些 链接的来源包括：Bing, Yahoo, Yandex, Blekko, WolframAlpha以及其他的很多源。
• 所有的解析以及合并逻辑都是通过Perl。
• 两个层次的融合：后台和客户端。
• 一切路由通过Nginx服务器。这样搜索结果就不会泄露给供应商。
• DuckDuckHack是一个新的即时回答平台。
• 搜索引擎的核心在于把搜索请求路由到正确的后端组件。
• 搜索建议来自一个完全不同的“自家生产”的组件
• 搜索的目标是覆盖80%的搜索范围，并且通过增加1000个来源来提供即时问题回答，维基百科可以帮你达到20%，增加更多的“长尾”有可能会达到30%。长尾理论意味着并不是非常准确的进行答案匹配，但是维基百科中的某个段落可能会匹配该问题。
• “过滤器泡沫（Filter Bubble）”，当用户点击某个链接的时候，系统可能会展示很多相似的链接。用户的点击历史或者搜索记录可能会把用户锁定到“过滤器泡沫”，如果用户同意该操作，就会有更多的内容会展现。但是搜索和点击历史不会被用于目标结果。过滤器泡沫破灭，也许未来会提供该功能，但是它必须是可选择的。

DuckDuckGo平台

• EC2
• Ubuntu
• Perl & CPAN
• Server Density——监测
• Solr
• PostgreSQL
• Memcached
• Bucardo- 异步的PostgreSQL复制系统
• Global Traffic Director——地区之间的负载均衡
• Nginx ——一个高性能的HTTP和反向代理服务器
• getFavicon—— 图标服务
• Daemontools—— 管理Unix服务器的免费工具
• Git
• Asana —— 项目管理
• HipChat —— 内部通信
• Yammer
• JavaScript —— 很多代码
• jQuery
• perl —— 很多代码

DuckDuckGo的内在

系统设计非常简单，尽管他们已经随着时间的变化而变得更加复杂。得益于所有的一切都是模块化的设计，复杂度已经得到缓解。

最主要的目标是100%的运行时间以及100%的速度，降低复杂度显然帮助实现了这两个目标。

走出地下室 拥抱AWS

DuckDuckGo过去的运行环境都是在Gabriel的地下室。现在，大多数组件，包括所有的前端组件都部署在AWS之上。

• 为了更好的前端性能，部署多个可用区，这样就可以让快速的DDG无处不在，用户自然源源而来。
• 彻底摆脱EBS，这是由于EBS卷入了几次很大的宕机事件之中。同时也经历了EBS性能的变化。
• 都是在一些大型机之上运行。
• 开发人员的计算机上部署中等的实例。分段实例用于测试，这足以模拟实时的环境。
• 数据中心同步。
• 分布式缓存系统使用Memcached。
• 使用多种数据库，包括 PostgreSQL, Solr, Berkeley以及Flat Files。

开发相关

• 团队的50％属于远程办公；10-15人是全职工作；20-25人属于定期的贡献者；有些人是兼职，负责非常具体的功能。这项伟大工程凝聚了团队成员共同的努力。
• 使用Git作为版本控制系统；为每个发行版添加标签；使用一个部署系统为所有机器安装软件，自插件系统启动后该系统变得更为复杂。
• 每个开发人员都拥有一个中等的云实例。
• Asana用于项目管理。
• HipChat以及Yammer用于内部通信。
• 前端的开发大量采用了JavaScript，使用jQuery。

我们可以从中学到什么？

• 保持简单：不需要大量的负载均衡，也不需要众多的子系统，模块化的设计可以让各个组件保持独立。
• 用户关心的是性能：贴近用户体验，备份信息到多个使用区域，包括部署一个缓存层，这样能大大的提高性能。
• 高速缓存仅仅是故事的开始：一旦部署高速缓存，你就必须合理的进行安排，而且还必须考虑时效性，如果数据保存的太久，用户的体验就会很糟糕，所以数据必须仔细的进行分类（特定的缓存策略）。
• 只读为主的架构还是不错的：很多DDG的路径是非常健壮的，这得益于它们有一个只读为主的数据集。
• 使用众包插件的形式去扩大搜索的范围是一个很好的想法：实时地整合如此多的数据信息绝对是一个很大的挑战，希望未来的世界不会摧毁这个计划。
• 使用如此多的第三方服务有优势也有弱点：正是“联盟”的力量，让DDG获得了比以往更多的数据信息，但是必须承认，这就像很多弱小的国家联合在一起抗衡一个强大的帝国。当然弱点也是很明显，由于信息的来源不同，这样会产生更高的延迟，而且信息还需要整合在一起形成一个整体，那么在设计系统时就会变得更加的困难。
• 跟巨头竞争，你需要从一个新的角度“出击”：DDG追求的特点，谷歌是不会进行拷贝的，因为谷歌需要保持一个低成本的运营来实现合理的收入。
• 移动，是挑战也是机会：锁定在移动设备上的搜索引擎难分高下，具有讽刺意味的是，即时答案是一个伟大的功能，因为用户并不需要大量的文字页面来寻找自己想要的东西。