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

58沈劍發表於2022-12-06

==提問== 

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

公司有一個每秒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)使用適合海量資料的技術進行儲存;

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

思路比結論重要。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556838/viewspace-2654143/,如需轉載,請註明出處,否則將追究法律責任。

相關文章