大数据查询

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

单表大数据？ clickhouse

10 亿上 ES 吧

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

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

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

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

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

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

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

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

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

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

@sunjiayao 用 mysql 吗

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

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

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

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

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

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

@sunjiayao 我看看 pgsql

建议上 ES 吧 。

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

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

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

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

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

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

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

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

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

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

starrocks

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

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

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

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

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

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

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

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

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

64C64G1TSSD 这个配置应该带的动

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

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

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

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

生成了 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