clickhouse中的多个小插件

gblwokeq  于 2021-07-15  发布在  ClickHouse
关注(0)|答案(5)|浏览(532)

我在clickhouse中有一个事件表(mergetree),希望同时运行许多小插入。但是,服务器变得过载和无响应。此外,一些插入件丢失。clickhouse错误日志中有很多记录:

01:43:01.668 [ 16 ] <Error> events (Merger): Part 201 61109_20161109_240760_266738_51 intersects previous part

有没有办法优化这些查询?我知道我可以对某些类型的事件使用批量插入。基本上,运行一个包含许多记录的insert,clickhouse可以很好地处理这些记录。但是,某些事件(如单击或打开)无法以这种方式处理。
另一个问题是:为什么clickhouse决定存在类似的记录,而它们却不存在?插入时有类似的记录,这些记录与索引中的字段相同,但其他字段不同。
我还不时收到以下错误:

Caused by: ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, message: Connect to localhost:8123 [ip6-localhost/0:0:0:0:0:0:0:1] timed out, host: localhost, port: 8123; Connect to ip6-localhost:8123 [ip6-localhost/0:0:0:0:0:0:0:1] timed out
    ... 36 more

主要是在项目构建期间,对clickhouse数据库进行测试时。

jckbn6z7

jckbn6z71#

当处理大量小插入到(非复制的)mergetree中时,这就是已知的问题。
这是一个错误,我们需要调查和修复。
对于解决方法,应按建议以较大的批发送插入:大约每秒一批:https://clickhouse.tech/docs/en/introduction/performance/#performance-插入数据时。

uubf1zoe

uubf1zoe2#

clickhouse为这个缓冲区提供了特殊类型的表。它存储在内存中,允许许多小的插入而不会出现问题。我们有近200种不同的插入每秒-它工作得很好。
缓冲表:

CREATE TABLE logs.log_buffer (rid String, created DateTime, some String, d Date MATERIALIZED toDate(created))
ENGINE = Buffer('logs', 'log_main', 16, 5, 30, 1000, 10000, 1000000, 10000000);

主表:

CREATE TABLE logs.log_main (rid String, created DateTime, some String, d Date) 
ENGINE = MergeTree(d, sipHash128(rid), (created, sipHash128(rid)), 8192);

手册内容:https://clickhouse.yandex/docs/en/operations/table_engines/buffer/

brqmpdu1

brqmpdu13#

我也遇到过类似的问题,尽管不是因为每秒插入20次导致服务器达到高平均负载、内存消耗和cpu使用率。我创建了一个缓冲表来缓冲内存中的插入,然后定期将它们刷新到“实”磁盘表中。就像魔术一样,一切都很顺利:loadavg、内存和cpu使用率降到了正常水平。好的一点是,您可以对缓冲区表运行查询,并从内存和磁盘中获取匹配的行,这样客户机就不会受到缓冲区的影响。看到了吗https://clickhouse.tech/docs/en/engines/table-engines/special/buffer/

iugsix8n

iugsix8n4#

或者,您可以使用https://github.com/nikepan/clickhouse-bulk:它将缓冲多个插入,并根据用户策略将它们一起刷新。

kpbwa7wx

kpbwa7wx5#

clickhouse合并引擎的设计并不意味着同时进行小的写操作。据我所知,mergetree合并了 parts 根据分区将数据写入表中,然后重新组织 parts 为了更好的聚合阅读。如果我们经常写些小文章,你会遇到另一个例外 Merge ```
Error: 500: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slow

当您试图理解为什么会抛出上述异常时,您的想法会更清楚。ch需要合并数据,并且对于可以存在多少部分有一个上限!批处理中的每一次写入都作为一个新部分添加,然后最终与分区表合并。

SELECT
table, count() as cnt
FROM system.parts
WHERE database = 'dbname' GROUP BY table order by cnt desc

上面的查询可以帮助您监视部件,在编写部件将如何增加并最终合并的过程中进行观察。
我最好的选择是缓冲数据集并定期将其刷新到db,但这意味着没有实时分析。
使用缓冲区是好的,但是请考虑以下几点:
如果服务器异常重启,缓冲区中的数据将丢失。
final和sample不适用于缓冲表。这些条件被传递到目标表,但不用于处理缓冲区中的数据
向缓冲区添加数据时,其中一个缓冲区被锁定(所以没有阅读)
如果复制了目标表,则在写入缓冲区表时,复制表的某些预期特性将丢失(无重复数据消除)
请通读,这是一个特例引擎:https://clickhouse.tech/docs/en/engines/table-engines/special/buffer/

相关问题