==提问== 

沈老师,你好,想请教一个身份证信息检索的问题。

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

经验有限,欢迎大家贡献更多更好的方案。

思路比结论重要。

Comments are closed.