- 主题:elasticsearch和clickhouse的选择
elasticsearch的聚合分析也挺好用的。速度绝对比clickhouse快。
还有追求速度放弃精度的模糊统计。
es查询要看分词效果，简单查询简单插入都clickhouse好用。
【 在 No1 的大作中提到: 】
: clickhouse是批量导入数据快，多维分析快；
: 简单插入和简单查询不是它的专长
--
FROM 58.42.245.*
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.*
一般的数据库，你拿一堆UUID去查，可以很快
但是clickhouse基于LSM，索引是基于跳表玩的，没法拿UUID直接快速的取到结果，都是基于UUID去scan一片，命中到了取出来，所以clickhouse并发性不太行。而且每次查询默认要用系统一半的cpu去查。
我存数据都是俺天分区，之前看文档没有看到说不推荐分区。。。
只是你自己要做好分区的索引字段的顺序，这个对于查询数据至关重要。
因为只有4台机器，我只做了2shards, 2replica。
clickhouse本身很稳定，要关注的是别让zookeeper挂了。
【 在 lichehuo 的大作中提到: 】
: 这么多回复，就你的靠谱。
: 你说的单点查询是指什么？
: 另外我看官方文档不建议用分区呢？我本来想把日志放一个库表，然后按天分区，看到官方文档说法之后，我打算按天建库，每天的日志在当天的库里。跨库查询的时候，自己在query时候处理好。
: ...................
--
FROM 58.42.245.*
flink的jdk需要u2xx以上的，不然job很容易自己挂掉。
【 在 lichehuo 的大作中提到: 】
: 另外，我们技术栈是go，目前也正准备下线flink，准备直接从消息队列里消费消息，写入ch。这样没有中间平台层，资源可以更省，而且flink这家伙动不动就OOM，烦得一逼，
--
FROM 58.42.245.*
非索引字段like速度也相当快了，只是吃cpu。
我之前干过千亿速度直接like，
虽然耗时有点长，都能查得出来
换其他数据库八成要timeout
【 在 lichehuo 的大作中提到: 】
: 查询我倒不担心，我们都是最基本的查询，日志无非就是输入关键字，看能不能命中，like就能满足80，90%了。
--
FROM 58.42.245.*
默认并发100
使用一半cpu的意思是即便是一个查询也会使用一半cpu，来多个就分分这资源。
都可以通过参数调节。
但是并发真不乍地。
【 在 lichehuo 的大作中提到: 】
: 纠正一下我之前的设计问题，不能分库分表，否则查询时候处理起来很麻烦，可能导致查询响应非常慢。应该是一个库表里面按day分区，然后设置TTL。
: 我是把时间列作为index了，每次都必须带上时间条件，这样可以锁定一定范围的数据。而且需要like的字段是日志内容字段，这样的字段没法index吧。每次查询默认用一半cpu，这个能修改么？虽说查询不是高频，但是每秒也得支持百级别的查询吧？
--
FROM 58.42.245.*