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

星球水友提問== 

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

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

上一位星球水友問的是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）使用适合海量資料的技術進行存儲；

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

思路比結論重要。

本文轉自“架構師之路”公衆号，58沈劍提供。