近日，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)進(jìn)行改動增加了以時間、地點和標(biāo)簽進(jìn)行排序的難度。當(dāng)前，排序和索引的數(shù)據(jù)約有70種，其中很多種都是基于特定post類型的。此外，數(shù)據(jù)存儲在一個用于生產(chǎn)環(huán)境的MySQL數(shù)據(jù)庫中。這也就意味著，當(dāng)數(shù)據(jù)庫同時支撐生產(chǎn)傳輸及數(shù)據(jù)收集時，負(fù)載將大幅度增加，因此這些過程必須被嚴(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進(jìn)行更新操作。為了減少重復(fù)代碼，我們使用與在“數(shù)據(jù)收集”部分提到的相同邏輯來進(jìn)行更新操作。不同之處在于，我們在收集數(shù)據(jù)時有意避開緩存，因為我們想盡量避免請求沒有緩存過的數(shù)據(jù)。當(dāng)我們更新索引時，我們將會命中緩存，因為我們希望該數(shù)據(jù)是最近被訪問過，并且還在緩存中。

索引存儲

post索引要比Facebook維護(hù)的其他搜索索引大得多。在開始搜索post之前，F(xiàn)acebook 所有的搜索索引都存儲在RAM中。對于快速查詢來說，這再好不過了。對小型的搜索索引來說也是可行的。然而，將700多TB的數(shù)據(jù)存儲在RAM中所帶來系統(tǒng)開銷是難以想象的，因為它需要維護(hù)分布在多臺機器上的索引。協(xié)調(diào)存儲索引的多臺機器使它們有序地工作給系統(tǒng)帶來了巨大的性能損耗，Unicorn團(tuán)隊為此不得不尋找存儲post索引的新方法。我們最終敲定的解決方案是用固態(tài)閃存存儲大部分的索引，用RAM存儲存取最為頻繁的數(shù)據(jù)結(jié)構(gòu)，性能得以維持。

結(jié)果排序

由于索引了1萬億條post，絕大多數(shù)查詢返回的結(jié)果數(shù)量之多是任何人都讀不完的。為此，F(xiàn)acebook開始設(shè)計對結(jié)果進(jìn)行排序。為了使對用戶有價值并與用戶相關(guān)的內(nèi)容浮到上面，主要采用了兩種主要策略：查詢重寫和結(jié)果動態(tài)打分。在執(zhí)行前，先重寫查詢，靈活增加子句，以確保查詢結(jié)果對用戶價值更大。為搜索結(jié)果進(jìn)行打分，包括基于一系列用于排序的特征進(jìn)行排序和選擇文檔。排序特征是從文檔中抽取出來的，目前一共抽取了100多項特征，結(jié)合排序模型，用于尋找最佳搜索結(jié)果。隨著用戶量的增長和用戶反饋的增多，排序模型必將得到進(jìn)一步改善。

項目簡史

像 Facebook 的很多其他產(chǎn)品一樣，post搜索功能也是誕生于一個編程馬拉松項目。而在過去的一年中，Graph Search 團(tuán)隊的幾十個人實現(xiàn)了post搜索的大部分功能——基礎(chǔ)架構(gòu)、排序和產(chǎn)品化。