大数据查询

[BuGoooo]

需求：有 10 亿左右的数据需要做查询，想在毫秒内返回匹配结果

存入的内容如下

id	cardno	name	short	createtime
1	Dkmy48k7afjsG9T75BtTHOdssqCIyKtt	Jack Ma	DKyKtt	nowtime

数据库存入的是这些数据，但是我匹配的话是通过 short 来匹配的，有什么好用的软件或方法吗？

付费求指导

[cbythe434]

short 没啥含义直接 kv 查询的？ redis ？

[threeBoy]

单表大数据？ clickhouse

[shuangbiaog]

10 亿上 ES 吧

[BuGoooo]

@threeBoy 不一定单表，可以多表 可以用 short 的 前后来分一两百个表

[BuGoooo]

@shuangbiaog 可以用分表，10 亿条，es 能干毫秒内吗 铁铁

[BuGoooo]

@cbythe434 short 是要查询的内容，要么查全部 要么查后面四位， 只有这两个查询要求
redis 10 亿级的数据 带不动吧？

[COKETSANG]

是 short like 还是需要怎么查？单列查询感觉 clickhouse 的 prewehre 场景蛮合适的

[BuGoooo]

@COKETSANG like 应该不行吧，因为我的想法是 先查全部，如果不满足就只要后面 4 个
以我举例的为例，先查询 DKyKtt ，如果没查到则查询 yKtt 的数据 给返回

[COKETSANG]

@BuGoooo 你可以用 ck 测下，short 一列，sub_short 后 4 位一列。理论上适合 clickhouse 单列 prewhere 应该很快，但是 ck 的 qps 支持不会特别高，qps 比较高的场景建议你试试看 doris

[shuangbiaog]

@BuGoooo 内存给够，有啥不行的

[sunjiayao]

加一列 short_reversed 存数据 reverse(short), 分别给 short 和 short_reversed 加索引。10 亿数据洒洒水啦

[BuGoooo]

@COKETSANG 不需要 qps 很高，一天可能就最多几千次请求

[BuGoooo]

@shuangbiaog HAHA 是是是 内存够 啥都能干 ，哪像这种 10 亿级的数据，128g 的内存够不

[BuGoooo]

@sunjiayao 用 mysql 吗

[RandomJoke]

你要分表的话，如果能保证均匀分布，100 张表，单表不就 1kw 了，索引直出问题不大了吧。。如果你说 1ms 以内，感觉必须得内存了吧。。

[sunjiayao]

@BuGoooo #14 任意支持 btree 的数据库

[BuGoooo]

@RandomJoke mysql 分表，单表 1kw 的数据，100 张就够了 。但是你的意思是这种情况下最好就是数据能均匀分布到每个表里，如果想提高查询效率，我服务器的内存得拉起来吗

[RandomJoke]

@BuGoooo 数据在硬盘里的话，怎么估计也不能 1ms 以内，你拉高内存加快本质上不就是从内存出。。

[BuGoooo]

@RandomJoke 上云也可以，只要做到响应毫秒级内返回就行

铁铁方便 v X 吗 付费求指导 哈哈

[BuGoooo]

@sunjiayao 我看看 pgsql

[guanhui07]

建议上 ES 吧 。

[RandomJoke]

@BuGoooo 毫秒内还是毫秒级别啊- -，你说的 1s 以内的话，单表 1000w ，走索引应该都行，关键在于你怎么尽量保证他均匀分布，常见的列式存储和倒排查询比如 ES CH 1s 以内还是比较轻松的

[BuGoooo]

@RandomJoke 1s 不是 1ms 哈哈 1 秒内

[hashakei]

字节 redis 不行么？ key 是 short, value 是一个这一行值的 json

[BuGoooo]

@hashakei 但是还要返回 cardno name 这些值 如果光靠 redis 查 会慢吗

[COKETSANG]

@BuGoooo 简单用我本地笔记本生成 1 亿数据测试了下，ck 一天几千次请求轻轻松松

[xinyewdz]

如果一天只有几千的查询，clickhouse 可以的。ES 查询估计够呛

[hashakei]

@BuGoooo #25 可以用 redis 的 hash ，或者 redis 的 string ，存的是 json 格式，不会慢的，redis 的 kv 查询跟数据量没啥关系，就是比较费内存。

[hashakei]

[BuGoooo]

@hashakei 哇哦 这个可以，redis 的 kv 支持模糊吗？ 比如我的查 DKyKtt 的时候，如果没有符合的 我就再查 yKtt （降低条件）这样来寻找匹配的数据

[BuGoooo]

@COKETSANG 这个牛 笔记本都能这个响应速度吗 那放服务器不得起飞咯 HAHA

[hashakei]

@BuGoooo #30 不支持，你这种估计得要用 es 了，且性能应该不会太好

[superchijinpeng]

starrocks

[crysislinux]

@BuGoooo redis 有全文搜索插件，就是要算算这么多数据放得下不。

[yufeng0681]

10 亿级别的数据查询，要想办法分开，增加维度让查询的数量级降到千万条数据，这样才能体现出来你的价值（做过设计）。
自己作为消费者，老吐槽 app 越来越大，越来越慢，内存大都被 app 吃掉了。app 开发者就是偷懒，不做设计，业务功能堆堆堆上去，反正手机不停硬件升级

[zhangshenglong52]

@BuGoooo redis key 支持模糊检索 keys *yKtt 可以模糊匹配（ keys 不推荐用，会阻塞线程导致 redis 不可用），或者用 SCAN 也支持模糊匹配。

[djangovcps]

elasticsearch 可以做到 15ms ，但是内存至少 32G 起步，机器配置不够查询不太行。

[sagaxu]

10 亿条，索引也就 4 层，short 区分度高的话，内存搞个 32G ，索引全装内存里，随便哪个数据库完整匹配或者后四位都不会超过 1 秒

[BuGoooo]

@djangovcps 单机单节点吗 机器配置可以高点 能带的动不

[djangovcps]

能带动，16 核 64G ，单机没问题。

[BuGoooo]

@djangovcps 只用到 Elasticsearch 就够了吗？还需要其他的配合不？我 10 亿条都存一个分片还是多个分片合适呀

[djangovcps]

看你 cpu 数量，5-10 个够用了，你这里只用 term 查询，如果用后四位的话，可以再存一份 reverse 的数据，直接用 es 提供的前缀 查询就行。

[BuGoooo]

64C64G1TSSD 这个配置应该带的动

我先插入 1 亿条试试 感谢大哥指点
祝大哥年入千万

[8355]

es 毫秒级无压力啊
分表以下做好分片和索引

[unclejimao]

@COKETSANG 这种查 short_sub 的时候是不是就没法用索引了？是不是可以考虑使 partition by short_sub ，order by short ，查询的时候都带上 WHERE short_sub=? ，以减少分区扫描

[COKETSANG]

@unclejimao 对，这个表如果这样设计单 short_sub 查询的时候是没法用索引。
我这里测试没有动脑粗暴的按 short 去分区了，按你说的优化固定带上 short_sub 是一种办法。
我还想过把 short 和 short sub 这俩字符串的转成 hash 数字多存两个数字 hash 字段，这样扫描后在代码里面二次匹配过滤。
不知道会不会更快，考虑到这俩字符串比较短碰撞可能性比较高可能是个负优化。

[ldyisbest]

生成了 1 亿数据，使用 duckdb 在 short 上建索引，查询效果如下，10 亿应该毫无压力

D select count(*) from user_info;
Total Time: 0.0241s
count_star()
int64
100000000
Run Time (s): real 0.026 user 0.067518 sys 0.052258

D select * from user_info where short = 'lHmQkx' limit 10;
Total Time: 0.0028s
cardno name short
varchar varchar varchar
JMasgl4pEtpVoadYedJEFAGcOR6xgesN YykPH lHmQkx
Run Time (s): real 0.006 user 0.001355 sys 0.001915
D