码迷,mamicode.com
首页 > 其他好文 > 详细

1000亿文本信息,高并发MD5查询,这么大数据量的业务怎么弄?

时间:2020-11-10 11:30:25      阅读:10      评论:0      收藏:0      [点我收藏+]

标签:查询   leveldb   信息   怎么办   很多   提前   图片   inf   png   

==星球水友提问==
沈老师,你好,想请教一个身份证信息检索的问题。

公司有一个每秒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)使用适合海量数据的技术进行存储;

经验有限,欢迎大家贡献更多更好的方案。
思路比结论重要。
技术图片
欢迎大家继续提问,有问必答。

答球友问:

《MQ如何实现平滑迁移?》
《30亿日志,检索+分页+后台展示》

课后习题:

1000亿数据,不同的身份证号可能导致MD5重复,怎么办?

1000亿文本信息,高并发MD5查询,这么大数据量的业务怎么弄?

标签:查询   leveldb   信息   怎么办   很多   提前   图片   inf   png   

原文地址:https://blog.51cto.com/jyjstack/2548557

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!