==提問==

沈老師，你好，想請教一個身份證資訊檢索的問題。

公司有一個每秒5萬併發查詢的業務，（假設）根據身份證MD5查詢身份證資訊，目前有1000億條資料，純文字儲存，前幾天看你寫LevelDB，請問這個業務能利用LevelDB記憶體資料庫進行儲存麼？有沒有其他最佳化方案？

畫外音：LevelDB《記憶體KV快取/資料庫》。

==問題描述完==

上一位星球水友問的是36億日誌後臺分頁查詢，緊接著又來了一位1000億文字MD5查詢，這次的業務，至少需要解決：

（1）查詢問題；

（2）高效能問題；

（3）儲存問題；

一、查詢問題

文字資訊的查詢與檢索，效率很低，第一個要解決的問題是：將文字過濾轉變為結構化查詢。

由於檢索條件是MD5，可以結構化為：

(MD5, data)

這樣可以KV查詢，或者資料庫裡的索引查詢。

需要注意的是，MD5一般為字串表示，字串作為索引效能會降低，可以將字串型的MD5轉化為兩個uint64_t進行儲存，以提高索引效率。

(md5_high, md5_low, data)

兩個長整形做聯合索引，或者KV中的聯合key。

該業務有一個很強的特點，都是單行資料主鍵上的查詢，拋開資料量不說，即使不使用快取，傳統的關係型資料庫儲存，單機也能扛至少1W的查詢。

畫外音：但其實單機存不下，後文細說。

二、高效能問題

每秒5W併發，吞吐量很大，第二個要解決的是：效能的提升。

身份證查詢的業務有兩個很強的特點：

（1）被查詢的資料是固定的；

（2）只有查詢請求，沒有修改請求；

很容易想到，快取非常非常適合這種場景，不僅如此，還可以提前將資料載入到記憶體裡，規避快取的“預熱”。

畫外音：根據業務特點做設計，任何脫離業務的架構設計都是耍流氓。

如果記憶體足夠大，提前載入資料，可以做到快取命中率100%；即使不提前載入，每條資料也最多一次cache miss，資料一旦入cache，由於沒有寫請求，後續將永遠不會被換出。

記憶體足夠大的前提成立麼？

假設每張身份證資訊0.5K，1000億大約：

1000億*0.5K = 50000G = 50T

畫外音：沒有算錯吧？

如此來看，如果不是特別土豪，快取裝不下所有資料，只能承載熱資料。

每秒5W的吞吐量是瓶頸麼？

線性擴充容量的方法很多：

（1）站點、服務冗餘10份以上；

（2）儲存（主鍵單行查詢）水平切分10份以上；

可以看到，5W的併發並不是問題。

三、儲存問題

如上一個部分分析，1000億身份證資訊，50T的資料，資料量實在太大，傳統的關係型資料庫，LevelDB此類單機記憶體資料庫不是特別合適，人工水平切分，拆分例項會非常多，較難維護。

還是使用Hbase這類適合大資料量的儲存技術吧。

最終，結合本例，建議：

（1）千萬不能文字檢索，務必要結構化；

（2）單行查詢，只讀不寫，快取+冗餘+水平切分能極大提升吞吐量；

（3）使用適合海量資料的技術進行儲存；

經驗有限，歡迎大家貢獻更多更好的方案。

思路比結論重要。

1000億文字資訊，高併發MD5查詢，這麼大資料量的業務怎麼弄？