目前我们的日志是存在es中的，平时没什么量的情况下，一切都ok。但是当给客户演示2w或者3wtps压测的时候，一秒的日志量达到了几百G，这个时候写入es就遇到瓶颈了。
我简单的测试了一下，es7.6版本极限也就是一次写入10几M，而且响应时间10+s了。升级到7.10+以上，可以写入30M，但是响应时间也是3+s。对于压测的日志量，这个响应时间不可接受。
压缩率也对比了一下，也是ch完胜。
查询耗时，没有拿上百G，上T的日志来比，可能在量大起来的情况下，es应该比ch强。但是考虑到我们的日志查询都是最基本的匹配查询，es有点大材小用了。
考虑换成clickhouse，粗略扫了一眼它的文档，感觉运维起来有点麻烦。es毕竟成熟，社区活跃。
版上有大神用过ch吗？能给一些意见或者建议吗
--
FROM 113.116.198.*

【 在 No1 的大作中提到: 】
: clickhouse是批量导入数据快，多维分析快；
: 简单插入和简单查询不是它的专长
:
不对吧，写入比es快是肯定的，es写之前要做很多事情
--
FROM 113.116.181.*

【 在 lokta 的大作中提到: 】
: clickhouse在记录日志方便比es性价比高多了。
: es本身就是写慢读快，clickhouse写快读也快。
: es关键是太吃内存了，要到达预期的效果需要很多机器。
: ...................
另外，我们技术栈是go，目前也正准备下线flink，准备直接从消息队列里消费消息，写入ch。这样没有中间平台层，资源可以更省，而且flink这家伙动不动就OOM，烦得一逼，
--
FROM 113.116.181.*

【 在 lokta 的大作中提到: 】
: 一般的数据库，你拿一堆UUID去查，可以很快
: 但是clickhouse基于LSM，索引是基于跳表玩的，没法拿UUID直接快速的取到结果，都是基于UUID去scan一片，命中到了取出来，所以clickhouse并发性不太行。而且每次查询默认要用系统一半的cpu去查。
: 我存数据都是俺天分区，之前看文档没有看到说不推荐分区。。。
: ...................
纠正一下我之前的设计问题，不能分库分表，否则查询时候处理起来很麻烦，可能导致查询响应非常慢。应该是一个库表里面按day分区，然后设置TTL。
我是把时间列作为index了，每次都必须带上时间条件，这样可以锁定一定范围的数据。而且需要like的字段是日志内容字段，这样的字段没法index吧。每次查询默认用一半cpu，这个能修改么？虽说查询不是高频，但是每秒也得支持百级别的查询吧？
--
FROM 113.116.181.*