近日，F(xiàn)acebook為post搜索添加了Graph Search。我們來看幾個驚人的數(shù)字：Facebook每天約產(chǎn)生10億條 post，post索引總數(shù)已上萬億條，數(shù)據(jù)量超700TB。為這些post建立索引和構(gòu)建實時查詢系統(tǒng)在工程上存在非常大的挑戰(zhàn)，那么Facebook 又是如何應(yīng)對這一挑戰(zhàn)的？以下為譯文：
數(shù)據(jù)收集
Facebook的底層數(shù)據(jù)結(jié)構(gòu)是為了滿足快速迭代網(wǎng)絡(luò)服務(wù)的需要，這卻也成為構(gòu)建實時查詢系統(tǒng)所面臨的最大挑戰(zhàn)。增加新功能往往需要改動這些數(shù)據(jù) 結(jié)構(gòu)，而Facebook一貫的作風(fēng)是變動不要給工程師平添煩惱。然而，由于wall post、photo、check-in等功能采用不同的數(shù)據(jù)存儲 機制，對底層數(shù)據(jù)結(jié)構(gòu)進行改動增加了以時間、地點和標(biāo)簽進行排序的難度。當(dāng)前，排序和索引的數(shù)據(jù)約有70種，其中很多種都是基于特定post類型的。此 外，數(shù)據(jù)存儲在一個用于生產(chǎn)環(huán)境的MySQL數(shù)據(jù)庫中。這也就意味著，當(dāng)數(shù)據(jù)庫同時支撐生產(chǎn)傳輸及數(shù)據(jù)收集時，負載將大幅度增加，因此這些過程必須被嚴(yán)格 監(jiān)控。
索引建立
數(shù)據(jù)收集來后，我們將其存儲在HBase集群中，然后執(zhí)行Hadoop map-reduce任務(wù)，高并行地為之建立索引。為原始數(shù)據(jù)建立索引后， 然后便傳輸給搜索的基礎(chǔ)Unicorn。我們將數(shù)據(jù)分為兩塊——文檔數(shù)據(jù)和反向索引（inverted index）。每條post的文檔數(shù)據(jù)包含用于排 序的相關(guān)信息。傳統(tǒng)意義上搜索索引有什么，反向索引就有什么。要建反向索引需要遍歷每一條post，并確定與假設(shè)中的哪種搜索過濾器相匹配。
索引更新
為了更新索引，我們使用Wormhole技術(shù)訂閱MySQL數(shù)據(jù)庫中的變更。一旦有新post，現(xiàn)有post被修改、刪除或與post有關(guān)的相關(guān)數(shù) 據(jù)被編輯等情況發(fā)生時，我們就會都對相關(guān)post進行更新操作。為了減少重復(fù)代碼，我們使用與在“數(shù)據(jù)收集”部分提到的相同邏輯來進行更新操作。不同之處 在于，我們在收集數(shù)據(jù)時有意避開緩存，因為我們想盡量避免請求沒有緩存過的數(shù)據(jù)。當(dāng)我們更新索引時，我們將會命中緩存，因為我們希望該數(shù)據(jù)是最近被訪問 過，并且還在緩存中。
索引存儲
post索引要比Facebook維護的其他搜索索引大得多。在開始搜索post之前，F(xiàn)acebook 所有的搜索索引都存儲在RAM中。對于快 速查詢來說，這再好不過了。對小型的搜索索引來說也是可行的。然而，將700多TB的數(shù)據(jù)存儲在RAM中所帶來系統(tǒng)開銷是難以想象的，因為它需要維護分布 在多臺機器上的索引。協(xié)調(diào)存儲索引的多臺機器使它們有序地工作給系統(tǒng)帶來了巨大的性能損耗，Unicorn團隊為此不得不尋找存儲post索引的新方法。 我們最終敲定的解決方案是用固態(tài)閃存存儲大部分的索引，用RAM存儲存取最為頻繁的數(shù)據(jù)結(jié)構(gòu)，性能得以維持。
結(jié)果排序
由于索引了1萬億條post，絕大多數(shù)查詢返回的結(jié)果數(shù)量之多是任何人都讀不完的。為此，F(xiàn)acebook開始設(shè)計對結(jié)果進行排序。為了使對用戶有 價值并與用戶相關(guān)的內(nèi)容浮到上面，主要采用了兩種主要策略：查詢重寫和結(jié)果動態(tài)打分。在執(zhí)行前，先重寫查詢，靈活增加子句，以確保查詢結(jié)果對用戶價值更 大。為搜索結(jié)果進行打分，包括基于一系列用于排序的特征進行排序和選擇文檔。排序特征是從文檔中抽取出來的，目前一共抽取了100多項特征，結(jié)合排序模 型，用于尋找最佳搜索結(jié)果。隨著用戶量的增長和用戶反饋的增多，排序模型必將得到進一步改善。
項目簡史
像 Facebook 的很多其他產(chǎn)品一樣，post搜索功能也是誕生于一個編程馬拉松項目。而在過去的一年中，Graph Search 團隊的幾十個人實現(xiàn)了post搜索的大部分功能——基礎(chǔ)架構(gòu)、排序和產(chǎn)品化。