百家乐必知技巧
大數據

1000億文本信息,高并發MD5查詢,這么大數據量的業務怎么弄?

廣告
廣告

==提問== 

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

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

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

思路比結論重要。

我還沒有學會寫個人說明!

混戰的CLM市場法智易以AI亮劍

上一篇

滴滴大數據在汽車金融風控場景中的應用

下一篇

你也可能喜歡

1000億文本信息,高并發MD5查詢,這么大數據量的業務怎么弄?

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
百家乐必知技巧 好运彩3 31选7今天中奖号码 德甲直播在线 山东11选5 赚钱中英文 国电电力股票行情 时时彩网站建设 棒球比分2x 金庸3加强怎么赚钱快 广西快乐十分开奖结果