==提问== 

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

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

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

思路比结论重要。