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)使用适合海量数据的技术进行存储;

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

思路比结论重要。

Image placeholder
hua20126
未设置
  78人点赞

没有讨论,发表一下自己的看法吧

推荐文章
96秒100亿!如何抗住双11高并发流量?

今年双11全民购物狂欢节进入第十一个年头,1分36秒,交易额冲到100 亿 !比2018年快了近30 秒,比2017年快了近1分半!这个速度再次刷新天猫双11成交总额破100亿的纪录。那么如何抗住双1

分层存储超详细解读,为什么大数据时代它已不可或缺

如今,分层存储已成为了一种常见的存储方法,它将数据存储在具有不同特性(如性能、成本和容量)的不同存储介质上。不同的存储媒介被分配到不同的层次结构中,其中最高性能的存储媒介被认为是第0层或第1层,然后是

高并发业务场景下的秒杀解决方案 (初探)

文章简介 本文内容是对并发业务场景出现超卖情况而写的一片解决方案。主要是利用到了Redis中的队列技术。 超卖介绍 所谓的超卖,就是我们的售卖量大于了物品的库存量。该情况一般出现在电商系统中促销类的业

1万属性,100亿数据,每秒10万吞吐,架构如何设计?

有一类业务场景,没有固定的schema存储,却有着海量的数据行数,架构上如何来实现这类业务的存储与检索呢?58最核心的数据“帖子”的架构实现技术细节,今天和大家聊一聊。一、背景描述及业务介绍什么是58

10亿美元!苹果收购Intel大部分芯片业务,晚半步布局5G芯片能赶上华为高通么?

大数据文摘出品作者:易琬玉、曹培信2200名英特尔员工,17000项无线技术专利,伴随着苹果在今天凌晨官宣收购英特尔大部分5G基带业务,都将逐渐流向苹果。这也意味着,继高通、华为、三星、联发科、紫光展

到2025年,SDN市场将达到1000亿美元

虽然NFV不断发展,但软件定义网络(SDN)也在服务提供商的网络中蓬勃发展。根据GlobalMarketInsights的报告显示,到2025年,SDN市场将从去年的80多亿美元增加的1000亿美元。

写数据库同时发mq消息事务一致性的一种解决方案

一、引子《事务注解(@Transactional)引起的数据覆盖故障》一文收到不少反馈。事务里不要有rpc,基本原则,sb封装的太好了,把很多人养傻了,function级别的事务,坑太大。网友一这个是

一通骚操作,我把SQL执行效率提高了10000000倍!

场景我用的数据库是mysql5.6,下面简单的介绍下场景课程表:create table Course(c_id int PRIMARY KEY,name varchar(10))数据100条学生表:

AWS计划扩大其在中国市场的业务规模

近日,AWS首席云计算企业顾问张侠表示,AWS希望在中国快速发展的云计算市场中占有更大的份额。  AWS首席云计算企业顾问张侠(Digitimes的AaronLee摄)AWS在全球云计算市场中占有40

区块链如何改变当今的业务安全

区块链已经扩展到多个行业,正在颠覆商业世界。下面是区块链如何改变当今的业务安全性。对区块链技术的需求持续增长。全球区块链技术市场的规模预计将增长,到2023年最终将达到233亿美元:区块链已经攻克的行

如何将网站的php版本信息隐藏起来

当我们把网站上线之后,我们可以通过curl的如下命令显示指定网站的头信息,curl的安装方法参考:https://www.wj0511.com/site/d...curl-Ihttps://www.w

MySQL 百万级数据量分页查询方法及其优化

作者|大神养成记原文|  http://t.cn/RnvCJnm方法1:直接使用数据库提供的SQL语句语句样式: MySQL中,可用如下方法:SELECT*FROM表名称LIMITM,N适应场景: 适

万字长文|1分36秒,100亿,支付宝技术双11答卷:没有不可能

2019年双11来了。1分36秒100亿,5分25秒超过300亿,12分49秒超500亿……如果没有双11,中国的互联网技术要发展到今天的水平,或许要再多花20年。从双11诞生至今的11年里,有一个场

价值100亿美元!微软刚刚击败亚马逊,拿下美国国防部十年云计算基建订单

大数据文摘授权编译自《纽约时报》编译:李雷、曹培信、刘俊寰为期10年,价值100亿美元。经过长达一年的竞标,微软接连击败了谷歌、IBM、Oracle和亚马逊,拿下了美国国防部云计算这宝贵的一单。上周五

阿里巴巴为什么能抗住90秒100亿?看完这篇你就明白了!

1、概述本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。2、

如果有人再问你怎么实现分布式延时消息,这篇文章丢给他

1.背景上篇文章介绍了RocketMQ整体架构和原理有兴趣的可以阅读一下,在这篇文章中的延时消息部分,我写道开源版的RocketMQ只提供了18个层级的消息队列延时,这个功能在开源版中显得特别鸡肋,但

PB级数据实时查询,滴滴Elasticsearch多集群架构实践

Elasticsearch是基于Lucene实现的分布式搜索引擎,提供了海量数据实时检索和分析能力。Elastic 公司开源的一系列产品组成的ElasticStack,可以为日志服务、搜索引擎、系统监

慌了,居然被问到怎么做高并发系统的限流

来源:uee.me/cDuRD在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流。本文结合作者的一些经验介绍限流的相关概念、算法和常规的实现方式。缓存缓存比较好理解,在大型高并发系统中,如果没

万万没想到,HashMap默认容量的选择,竟然背后有这么多思考!?

集合是Java开发日常开发中经常会使用到的,而作为一种典型的K-V结构的数据结构,HashMap对于Java开发者一定不陌生。在日常开发中,我们经常会像如下方式以下创建一个HashMap:Map ma

判菜系、调众囗、打分数,这一回,我们用大数据烧菜?

大数据文摘投稿作品作者:blmoistawinde年前,文摘菌曾经扒下了全网所有“年夜饭”菜谱,找到了最有年味的一道菜的一文,对于菜谱数据分析产生了浓厚的兴趣,遂自己也写了个爬虫爬取了某美食网站的一些

高并发设计笔记

基础篇 高并发系统:它的通用设计方法是什么? 高并发系统设计的三种通用方法:Scale-out、缓存和异步。 这三种方法可以在做方案设计时灵活地运用,但它不是具体实施的方案,而是三种思想,在实际运用中

高并发设计笔记

基础篇 高并发系统:它的通用设计方法是什么? 高并发系统设计的三种通用方法:Scale-out、缓存和异步。 这三种方法可以在做方案设计时灵活地运用,但它不是具体实施的方案,而是三种思想,在实际运用中

Redis为什么是单线程、及高并发快的3大原因详解

Redis的高并发和快速原因 1.redis是基于内存的,内存的读写速度非常快; 2.redis是单线程的,省去了很多上下文切换线程的时间; 3.redis使用多路复用技术,可以处理并发的连接。非阻塞

高并发设计笔记(续篇)

感谢大家对上篇的阅读和点赞,由于内容比较多,选择分开记录。 如果想深入了解,还是建议去购买学习该门课程《高并发系统设计》 分布式服务篇系统架构:每秒1万次请求的系统要做服务化拆分吗?了解实际业务中会

高并发下的接口幂等性解决方案!

一、背景我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果。例如:前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果。我们发起一笔付款请求,应该只扣用户账户一