# 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)  *這是對 [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。 干凈利落。