目前大概有 10 亿条数据(陆续还会继续增加)，就两个字段一个用户编码（随机的） 一个姓名。 我现在想做模糊匹配查询手机号做毫秒级的返回，比如输入编码后 3 位置后 4 位这些条件来输出所有编码一样的用户出来，用 clickhouse 合适吗
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 632 days ago, the information mentioned may be changed or developed.
33 replies • 2025-02-21 10:07:29 +08:00
 |
raycoolFeb 16, 2025
1
用 ES 合适吧？
|
 |
irrigate2554Feb 16, 2025
2
如果都是后 N 位的话直接数据库索引就可以优化，如果是任意 N 位 PGSQL 的话可以用 pg_trgm
|
 |
yudooFeb 16, 2025
3
非常合适啊 也好部署，数据压缩比较好对内存要求比较低
|
 |
silentskyFeb 16, 2025 via Android
4
合适
|
 |
8355Feb 16, 2025
5
es 成本更低
|
 |
QQQQQQQQQQQFeb 16, 2025
6
es 更合适。
clickhouse 的任意位置模糊匹配查询很费劲 |
 |
bronyakakaFeb 16, 2025
7
搜索需求 毫无疑问是 es
|
 |
mark2025Feb 16, 2025
9
pgsql 的 FTS 搜索可以满足需求
|
 |
NotLongNilFeb 16, 2025 via iPhone
10
需要你再具体描述下你的搜索场景，是固定按后 3 位搜索？还是后 4 位？还是随机长度？
|
 |
soap0XFeb 16, 2025
11
Pika
|
 |
me1onsodaFeb 17, 2025 via Android
12
这么简单的需求 pg 其实就可以，支持表达式索引
|
 |
levelwormFeb 17, 2025 via Android
13
好奇一把，十个亿存储量多大？
|
 |
spritecnFeb 17, 2025
14
感觉,这个活普通 mysql 就能搞定啊,不要被各种教程说 2000 万以上 mysql 撑不住说法给忽悠
|
 |
13240284671Feb 17, 2025
15
@spritecn 模糊搜索呢，你用 mysql 搜试下，搜一次几分钟
|
 |
homewORKFeb 17, 2025
18
不适合
clickhouse 更适合的是时序 + 数据处理任务的数据 很明显你这个不是，只是查找。es 可能更合适，或者折腾一下 mysql 等 |
 |
cosenFeb 17, 2025
19
应该问题不大，把后 3 位或后 4 位设计成分区，最多也就 1w 个分区，这样查数据也不会全表扫，可以试试
|
 |
20
各位需求都没明白吧（我反正是没有看懂） 就开始说技术了？
|
1 |
8355Feb 17, 2025
21
@root71370 简单来说看看阿里云的价格
Elasticsearch 有 Serverless 版本，可以按照 cu 收费，如果计划任务批量写库实际使用的 cu 很少，系统不是高并发持续访问的话一年不到 1 万就够了。clickhouse 单机起步就是 1 万 |
 |
diluFeb 17, 2025
22
“就两个字段一个用户编码（随机的） 一个姓名”
“模糊匹配查询手机号做毫秒级的返回” 从哪又蹦出来一个手机号字段？不就两个字段吗？一个用户编码，一个姓名 而且从实际出发，你已经有 10 亿条记录，还是手机号这种数据，先不说你从哪来的 如果只搜后 4 位，重复的概率得多大啊，你一下子就能搜出上万条记录，请问你怎么把这上万甚至几十万的数据展示给用户？ |
 |
raysFeb 17, 2025
23
你的需求是模糊匹配且是后缀匹配，是要用到 LIKE 和 position 函数，跳数索引是前缀匹配，无法满足你的需求，起不到加速查询的作用。position 是 ClickHouse 自带的字符串查询算法，性能会比 like 要好。但是 ClickHouse 数据库还是更适合列式聚合场景的，你的这种需求，还是不是很推荐使用 ClickHouse ，因为引入一项新技术后并没有带来突破性的提升。
|
 |
guanhui07Feb 17, 2025
24
搜索需求 最合适还是 es
|
 |
blessingsiFeb 17, 2025
25
查询流量是多少？
|
 |
26
@NotLongNil
编码长度是固定的，32 位的。但是编码是随机的，每次查询的话就是查询开头和结尾是否有匹配的，比如 ABCD****123456 我就查询前面 2 位 AB 和后面 4 位是否有相匹配的编码 |
|
NotLongNilFeb 17, 2025
29
@BuGoooo #26 clickhouse 不适合做这个。上面看到你试验后，发现查询慢。这是正常的，因为 CH 做了全表扫描。CH 的索引跟 mysql 多索引不一样。如果是固定前两位和固定后四位查询，你使用 mysql ，把这两个单独提出来，作为分表键，加索引，查询速度比 ch es 还快，还节省资源
|
|
silentskyFeb 18, 2025 via Android
30
@NotLongNil clickhouse 物化视图就能做
|
 |
unclejimaoFeb 18, 2025
31
多存两列，prefix 存前两位，做分区字段，不区分大小写的话 1000 多个分区； suffix 存后 4 位，做排序字段；
查询的时候直接 WHERE prefix=? AND suffix=? |
|
NotLongNilFeb 18, 2025
32
@silentsky #30 CH 的 MergeTree 索引结构，只能判断到数据在哪个段，然后将整个段加载到内存，在内存中进行遍历过滤。一个段默认大小有 8000 多行。在这个场景下，做好分表，设置好索引，B+ 树段查询速度反而会比 CH 更可观，还节省资源，并发更大。楼主这个搜索场景还需要考虑并发数，CH 的并发成本比 mysql 高了几个量级。物化视图只是 MergeTree 套了一层，底层没变
|
 |
itechifyFeb 21, 2025
33
es 前缀匹配完美符合切合你的需求
|
Select Language