千万级数据 10 毫秒以内的简单查询 有什么最佳实践？

manticoresearch

zincsearch

meilisearch （内存成本高）

sphinxsearch （已闭源能免费下载）


tantivy 使用难度高

@dzdh 感谢大佬 我去查查看看

你倒是说是什么样的数据啊

单机 clickhouse 秒了

es 可以

@whileFalse 数据 举个例子 就是 ，所有的地标（商店、宾馆）名称和这些地标的类型、介绍之类的信息
要求就是 输入名称 快速返回是不是一个 地标 和是什么类型的

阿里云 TableStore ，目前 10 亿数据，大概 10ms 返回

@ychost 这个看下来好贵呀 不知道是不是我看的价格不对

千万级别 ES 应该随意应付

（ type ，name ）,需要根据 name 全文索引。MySQL InnoDB + 固态就够了吧，千万数据真的很小，如果 name 是精确搜索，就唯一索引，模糊搜索就全文索引。不行就用 Memory 引擎

索引建的没问题的话 大部分数据库都能满足

mysql 可以了 机器好一点

@BiChengfi 嗯 需要精确搜索

@decken
@Nich0la5 之前知识用过 mysql 做一些业务，没有具体关注过耗时这么低的场景 感谢感谢

pgsql: https://pigsty.cc/zh/blog/pg/paradedb/

mysql 足以

这点数据，模糊搜索直接 pg 用 bigm_gin 索引秒了

直接存 ssd 上搞个散列表就行了。

这点数据，即使是在性能弱鸡的手机端，进行全文搜索，不是最简单的 1MB 的 SQLite ，都能解决的吗？


[《微信全文搜索耗时降 94%？我们用了这种方案》]( https://cloud.tencent.com/developer/article/2220615 ) 里说：

> 一个包含 100w 条中文内容、每条长度 100 汉字的 FTS5 的表查询三个词，optimize 状态下耗时 2.9ms

> 100w 条内容每次写入 100 条的情况下，按照 WCDB 的方案执行 merge ，耗时在 10s 内。

ck 秒了
es 秒了
mysql 秒了
pg 秒了

总结：千万量级不算大，业务也不复杂，做好索引即可

redis + mysql 稳了

字典树

@Kinnice 那亿级别的 哪种方案好扩展数据量 也只是简单查询

我看了下我线上库，1.1 亿数据，走索引查单条数据室 5ms 左右，mysql 在物理机上，物理机配置较高。

mysql 主从，主表 innodb 只写 从表 memory 只读

@7911364440 嗯嗯 写可能就停机批量写，大部分场景读

@woduzibue 你的简单查询是等值查询还是 like 匹配？

@woduzibue #23 ck 和 es

单机 clickhouse 轻松应对，我们数十亿数据的高并发查询都轻松拿捏，在线写也轻松，就是删除比较麻烦

@yjhatfdu2 暂时就等值查询，后续可能会考虑 like 但暂时是没这个打算

@Kinnice 好的 感谢大佬
@csbde 好的感谢大佬

@Nich0la5 按照题主的需求 ， %name%, 这样索引就失效了吧， 就上 es 吧，es 是开源的， 就 MySQL 加 es ， 业界成熟方案， 外包 公司 大规模使用的

前段时间测试 clickhouse, 目前库里 530 亿条数据查询蛮轻松

我来讲一个方案给楼主点思路。

我在广告方面做过一些项目，热点数据量在几亿条，存储占用四五 T ，需要秒级别延迟下的数据检索。
开始我们用了 starrocks ，但 starrocks 在广告场景下密集写入数据后索性能极差（这里不是点 starrocks ，只是我们在用这个。实际上各种号称大数据搜索的都有这种问题）。线上事故不断，资损动不动就是几十万，巅峰时期 3 天 4 个线上事故。
后来我们想了一个办法，搜索的字段和内容是固定的。我们动用了两套数据库，一个是常规的大容量存储，保证原始数据不丢失（这块我们不用于线上查询，偶尔 T+1 检索，目的是保证数据可以用来恢复业务需要的数据以及数分团队抽数分析），另一个是 Redis ，通过 ETL 方式将数据通过规则（规则是可配置的，比如“今天是星期天”，分词后就是“今天”，“星期天”）写入 Redis 作为索引。

* 检索：检索的时候仅查询 Redis ，从 Redis 中查到原始数据的索引，再去获取需要的数据

* 数据重刷：规则是固定的，随着业务的发展，规则需要变更。分词变更成“今天是星期天”要分词成“今天”，“2024/07/30”，“星期天”，“2024/08/04”，这个时候只能重刷数据。刷数就会导致未知风险，为了保证线上可以无感切换，我们还准备了两条数据链路，刷数链路清完数据开始从大容量存储里捞数据，重建影响范围内的数据。刷完后切换查询数据源。再把原来的数据链路重复上面的步骤。

以上一把操作后，我们的热点数据存储从之前的几 T 变成了百 G 。热点数据的数据量上的降低让我们系统 SLA 从 95%提升到 99.9%以上，接口耗时从 200 ～ 300ms 变成了 5ms 。

-----
ES 对于千万级别的数据用起来还算顺手，但数据量上去后 C 端接口抖动真的难以优化。如果有预期数据量在短期有数十倍增长就不必折腾了。B 端业务可以上，B 端接口 10ms 与 200ms 的感知不明显。

@brybeZhang 嗯 短期内不会有模糊查询的需要，支持精确查找就行，感谢大佬

@andyxq 感谢大佬

@singer 感谢大佬分享 我的场景比你这个要简单一点 不需要规则 非常感谢

@csbde ck 高并发？你这就是简单的索引键少字段点差询？

10ms 不可能，光是消耗在网络传输的时间就比这个长

唯一可行的放在机器内存里

看业务场景。
如果是静态元数据，那么，楼上说的方法都可行。
如果数据涉及到交易，那么，最好用关系型数据库。

举个例子：
我之前做过 1 个机票垂直搜索系统，在搜索系统中，涉及到 2 类数据。

第 1 类是静态元数据，比如：航司、城市、机场。
这类数据只用于对外展示，不影响业务流程走向。
通过中心式缓存，或者当作静态配置，都可以解决。
我们是采用静态配置，基于长轮询做了个增量更新协议。
原因是，我们的查询频次和范围非常高。

第 2 类是交易数据，比如：各个代理商的报价政策。
这些数据决定了机票价格，代理商会高频调价，直接影响机票金额。
这种一般是采用分库分表，我们分了 1024 个短表，然后并发查。
每个 sql 语句 select 字段不超过 5 个字段，where 条件不超过 3 个字段，全部走索引。
通过中间件实现报价源和搜索系统中间的数据同步，节点间采取半同步复制。
最终，基本能够达到你提到的性能要求，能够轻松支持亿级数据，代理商改价后，搜索服务秒级感知。

简单查询，走索引的话，直接查 MySQL 表问题不大吧

@Jooooooooo 50ms 以内也能接受

@kong0bbs 不涉及更新和交易

@sketcherly 嗯 准备先试试 之前没接触过这么多体量的数据

目前用的 ck,我们单表数据过亿了，也很快

之前做健康码的时候，4000 多万人口的数据使用 ES 进行存储和查询，就是简单的通过身份证号查询，使用 8 台 64G 内存 1TSSD 服务器，查询耗时在 1ms 左右。ES 级群也支持动态扩容/缩容, 操作起来也不难。

@joetao123

随便给个数据库，都是 1ms 。。。。而且只需要 2g4g 即可。