一秒几百G, 这是多大量的ES, 你们的整体服务器架构说下看看, 单实例肯定满足不了了
【 在 lichehuo 的大作中提到: 】
: 目前我们的日志是存在es中的，平时没什么量的情况下，一切都ok。但是当给客户演示2w或者3wtps压测的时候，一秒的日志量达到了几百G，这个时候写入es就遇到瓶颈了。
: 我简单的测试了一下，es7.6版本极限也就是一次写入10几M，而且响应时间10+s了。升级到7.10+以上，可以写入30M，但是响应时间也是3+s。对于压测的日志量，这个响应时间不可接受。
: 压缩率也对比了一下，也是ch完胜。
: ...................
--
FROM 58.34.53.*

clickhouse是批量导入数据快，多维分析快；
简单插入和简单查询不是它的专长

【 在 lichehuo 的大作中提到: 】
: 标  题: elasticsearch和clickhouse的选择
: 发信站: 水木社区 (Sun Oct  9 09:53:22 2022), 站内
:
: 目前我们的日志是存在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吗？能给一些意见或者建议吗
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 113.116.198.*]
--
FROM 106.121.185.*

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

clickhouse在记录日志方便比es性价比高多了。
es本身就是写慢读快，clickhouse写快读也快。
es关键是太吃内存了，要到达预期的效果需要很多机器。
clickhouse对机器需求要小一些。
我拿了4太机器做存储，一台机器做zookeeper（存储机器复用zookeeper，3节点)，存下了千亿级别的数据。
查询只要限定分区，查询速度还可以。
clickhouse的问题在于单点查询速度不行，
扩容缩容都很麻烦。
但是优点就是稳得一匹。开了2年没有重启过。。

生态方面es不用说，flink都有官方客户端，flink-sql都能直接入库。现在开放了xapck,可以使用sql查询。

clickhouse生态有点差，flink没有官方connector，官方的db jar包还不如第三方的快，有点离谱。sql查询需要用到一些奇怪的函数和方法。官方后来更新了一些东西，说支持join了，但是我没有升级，不知道现在如何。



【 在 lichehuo 的大作中提到: 】
: 目前我们的日志是存在es中的，平时没什么量的情况下，一切都ok。但是当给客户演示2w或者3wtps压测的时候，一秒的日志量达到了几百G，这个时候写入es就遇到瓶颈了。
: 我简单的测试了一下，es7.6版本极限也就是一次写入10几M，而且响应时间10+s了。升级到7.10+以上，可以写入30M，但是响应时间也是3+s。对于压测的日志量，这个响应时间不可接受。
: 压缩率也对比了一下，也是ch完胜。
: ...................
--
FROM 58.42.245.*

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