- 主题:elasticsearch和clickhouse的选择
【 在 lokta 的大作中提到: 】
: clickhouse在记录日志方便比es性价比高多了。
: es本身就是写慢读快，clickhouse写快读也快。
: es关键是太吃内存了，要到达预期的效果需要很多机器。
: ...................
查询我倒不担心，我们都是最基本的查询，日志无非就是输入关键字，看能不能命中，like就能满足80，90%了。
--
FROM 113.116.181.*
一般的数据库，你拿一堆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.*
【 在 lokta 的大作中提到: 】
: 一般的数据库，你拿一堆UUID去查，可以很快
: 但是clickhouse基于LSM，索引是基于跳表玩的，没法拿UUID直接快速的取到结果，都是基于UUID去scan一片，命中到了取出来，所以clickhouse并发性不太行。而且每次查询默认要用系统一半的cpu去查。
: 我存数据都是俺天分区，之前看文档没有看到说不推荐分区。。。
: ...................
纠正一下我之前的设计问题，不能分库分表，否则查询时候处理起来很麻烦，可能导致查询响应非常慢。应该是一个库表里面按day分区，然后设置TTL。
我是把时间列作为index了，每次都必须带上时间条件，这样可以锁定一定范围的数据。而且需要like的字段是日志内容字段，这样的字段没法index吧。每次查询默认用一半cpu，这个能修改么？虽说查询不是高频，但是每秒也得支持百级别的查询吧？
--
FROM 113.116.181.*
默认并发100
使用一半cpu的意思是即便是一个查询也会使用一半cpu，来多个就分分这资源。
都可以通过参数调节。
但是并发真不乍地。
【 在 lichehuo 的大作中提到: 】
: 纠正一下我之前的设计问题，不能分库分表，否则查询时候处理起来很麻烦，可能导致查询响应非常慢。应该是一个库表里面按day分区，然后设置TTL。
: 我是把时间列作为index了，每次都必须带上时间条件，这样可以锁定一定范围的数据。而且需要like的字段是日志内容字段，这样的字段没法index吧。每次查询默认用一半cpu，这个能修改么？虽说查询不是高频，但是每秒也得支持百级别的查询吧？
--
FROM 58.42.245.*
【 在 lokta 的大作中提到: 】
: 默认并发100
: 使用一半cpu的意思是即便是一个查询也会使用一半cpu，来多个就分分这资源。
: 都可以通过参数调节。
: ...................
可以了，这个并发对我们来说够用了
--
FROM 113.116.181.*
ch 单机性能很好，但是本质是olap，并发查询有瓶颈，单机模式下没啥运维成本，有很多存储引擎，我当时直接用Kafka引擎消费Kafka数据，前面对接一个redash，基本上一个数据看版系统就出来了
--
FROM 125.118.162.*