目前在做一个日志分析模块,里边有个分页展示所有日志的页面,并且可以按条件搜索,主要还是根据关键字去模糊搜索日志,类似 like '%关键字%' 这种。
我翻了下 clickhouse 的官方文档,找到 like 这种查询的优化可以用 tokenbf_v1 索引,但是我模拟了 1 亿数据量的日志,发现直接用 like '%%'并不走索引,只能用 hasToken()函数才行,但是这种函数的方式更像是分词匹配(确实这个索引的逻辑也是这样),不是 like 原本的逻辑。而且,tokenbf_v1 索引在低命中率的时候效果才明显,高命中率的时候依旧等于全表扫描。
我测试下来发现 clickhouse 并不能完全满足我。我想请教下 clickhouse 是否还有其他的优化是我未知的,或者 es 是否可以满足这种需求( es 我还没怎么接触过)。现在我测试的 1 亿数据,命中有 900w 数据时,select count()出来的时间要 100 来秒,太慢了。不知道 es 的情况会怎么样。
1
dode 2023-09-09 21:26:27 +08:00
增加 clickhouse 节点,划分多个独立硬盘分区数据呢
|
2
vitoliu 2023-09-09 22:18:59 +08:00
clickhouse 不清楚
es 可以通过 ngram+term query 进行查询。只有一亿数据的话可以尝试下,p99 肯定是可以做到一秒以内。 也可以先 suggester 查询,不行再使用 wildcard 查询,但是注意要限制字符长度。 |
5
vitoliu 2023-09-09 22:31:51 +08:00
@so2back #4 嗯,这么说来你们是自运维的 infrastructure ?全文检索场景肯定是优先 ES 的。而且 ES 集群对外能提供多种能力,业务普适性比 clickHouse 强。
|
6
vincent7245 2023-09-10 10:44:24 +08:00
大哥你是不是用错场景了,clickhouse 是做 OLAP 的,你只结把日志怼进去查是不是太粗暴了
|
7
so2back OP @vincent7245 主要看了好几个像携程、唯品会、石墨啥的博客说把日志从 es 转到 ck ,所以我在想 ck 是不是可行的,但我实际测试下来好像又不是一回事,可能场景不同吧,我这种场景太暴力了,就单纯的 like
|
8
kneo 2023-09-10 21:21:28 +08:00 via Android
like 是很难索引的。而且你返回结果太大了。有必要 900 万条都返回?看得过来嘛……
|
11
so2back OP @yudoo #10 es 和 ck 都用了,不过我这边没深度研究,目前就是搜索用的 es (每天数据写到不同的 index 里),但是限制了页面只能查看 es 默认的 1w 条数据(带搜索),整体搜索还行吧,我这边要求不是很高;其他一些非及时性的就用的 ck 。我这边是 flink 任务同时写 es 和 ck 的。上亿数据是客户那边的,因为我们是用 flink 对接的他们的日志,日志很多,每天都是几十上百亿的。。。
|