我这个需求 适合用 clickhouse 吗
目前大概有 10 亿条数据(陆续还会继续增加),就两个字段一个用户编码(随机的) 一个姓名。
我现在想做模糊匹配查询手机号做毫秒级的返回,比如输入编码后 3 位置后 4 位这些条件来输出所有编码一样的用户出来,用 clickhouse 合适吗
用 ES 合适吧?
如果都是后 N 位的话直接数据库索引就可以优化,如果是任意 N 位 PGSQL 的话可以用 pg_trgm
非常合适啊 也好部署,数据压缩比较好对内存要求比较低
合适
es 成本更低
es 更合适。
clickhouse 的任意位置模糊匹配查询很费劲
搜索需求 毫无疑问是 es
大家不都说 clickhouse 的成本要比 es 低吗?
pgsql 的 FTS 搜索可以满足需求
需要你再具体描述下你的搜索场景,是固定按后 3 位搜索?还是后 4 位?还是随机长度?
Pika
这么简单的需求 pg 其实就可以,支持表达式索引
好奇一把,十个亿存储量多大?
感觉,这个活普通 mysql 就能搞定啊,不要被各种教程说 2000 万以上 mysql 撑不住说法给忽悠
模糊搜索呢,你用 mysql 搜试下,搜一次几分钟
怎么想的 这个得看业务需要 如果数据分析那肯定不用 mysql 存储成本也高
#14 亿级模糊搜索超出 mysql 的能力范畴了,早点上专业的更合适。
不适合
clickhouse 更适合的是时序 + 数据处理任务的数据
很明显你这个不是,只是查找。es 可能更合适,或者折腾一下 mysql 等
应该问题不大,把后 3 位或后 4 位设计成分区,最多也就 1w 个分区,这样查数据也不会全表扫,可以试试
各位需求都没明白吧(我反正是没有看懂) 就开始说技术了?
知道为什么 Copilot 的宣传片都是在桌面打开的 Copilot 吗? 当你最大化了一个窗口,比如正在用 Edge 浏览 V2EX ,此时打开 Copilot ,它启动的时…
今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情。当我们去设计…
昨晚偶然查看了公司的阿里云 CDN 监控,发现被偷偷刷量了。 攻击方式是每晚 20-23 点,会用几千个 IP 请求一个 100M 左右的 exe 文件,和一个十几 k 的静态…