clickhouse - Clickhouse Buffer Table 是否适合实时摄取许多小插入？

Question

我正在编写一个应用程序来绘制财务数据并与此类数据的实时源进行交互。由于任务的性质，可能会以一次一次交易的方式非常频繁地接收实时市场数据。我在本地使用数据库，而且我是唯一的用户。只有一个程序(我的中间件)会将数据插入数据库。我主要关心的是延迟——我想尽可能地减少它。出于这个原因，我想避免有一个队列(在某种意义上，我希望缓冲区表来完成这个角色)。 Clickhouse 为我计算的很多分析预计也是实时的(尽可能多)。我有三个问题:

1. 澄清缓冲表文档中的一些限制/注意事项
2. 阐明查询的工作原理(常规查询 + 物化 View )
3. 当我在刷新数据时查询数据库会发生什么

问题 1) 澄清缓冲表文档中的一些限制/注意事项

根据 Clickhouse 文档，我了解到许多小型 INSERT 至少可以说是次优的。在研究该主题时，我发现缓冲引擎 [1] 可以用作解决方案。这对我来说很有意义，但是当我阅读 Buffer 的文档时，我发现了一些注意事项:

Note that it does not make sense to insert data one row at a time, even for Buffer tables. This will only produce a speed of a few thousand rows per second, while inserting larger blocks of data can produce over a million rows per second (see the section “Performance”).

每秒几千行对我来说绝对没问题，但我担心其他性能方面的考虑 - 如果我一次一行地将数据提交到缓冲表，我是否应该期望 CPU/内存出现峰值？如果我理解正确，一次将一行提交到 MergeTree 表会导致合并作业的大量额外工作，但如果使用 Buffer Table 应该不是问题，对吗？

If the server is restarted abnormally, the data in the buffer is lost.

我知道这是指停电或计算机崩溃之类的事情。如果我正常关机或正常停止clickhouse服务器，我是否可以期望缓冲区将数据刷新到目标表？

问题 2) 阐明查询的工作原理(常规查询 + 物化 View )

When reading from a Buffer table, data is processed both from the buffer and from the destination table (if there is one). Note that the Buffer tables does not support an index. In other words, data in the buffer is fully scanned, which might be slow for large buffers. (For data in a subordinate table, the index that it supports will be used.)

这是否意味着我可以对目标表使用查询并期望自动包含缓冲区表数据？还是反过来——我查询缓冲表，目标表包含在后台？如果其中任何一个为真(并且我不需要手动聚合两个表)，这是否也意味着将填充物化 View ？哪个表应该触发物化 View ——磁盘表还是缓冲表？或者两者兼而有之，以某种方式？

我非常依赖物化 View 并需要它们实时更新(或尽可能接近)。实现该目标的最佳策略是什么？

问题 3) 当我在刷新数据时查询数据库会发生什么？

我的两个主要问题是:

1. 在刷新发生的确切时间运行查询 - 是否存在记录重复或遗漏记录的风险？
2. 目标表的实体化 View 在哪个点被填充(我想这取决于触发 MV 的是目标表还是缓冲表)？刷新缓冲区对我如何构造 MV 很重要吗？

感谢您的宝贵时间。

[1] https://clickhouse.tech/docs/en/engines/table-engines/special/buffer/

Answer 1

A few thousand rows per second is absolutely fine for me, however I am concerned about other performance considerations - if I do commit data to the buffer table one row at a time, should I expect spikes in CPU/memory?

无缓冲区表引擎不会产生 CPU\内存峰值

If I understand correctly, committing one row at a time to a MergeTree table would cause a lot of additional work for the merging job, but it should not be a problem if Buffer Table is used, correct?

缓冲表引擎用作内存缓冲区，定期将批量行刷新到底层 *MergeTree 表，缓冲表的参数是刷新的大小和频率

If I shutdown the computer normally or stop the clickhouse server normally, can I expect the buffer to flush data to the target table?

是的，当服务器正常停止时，Buffer tables 会刷新它们的数据。

I query the buffer table and the target table is included in the background?

是的，这是正确的行为，当您从 Buffer 表中进行 SELECT 时，SELECT 也会传递到底层 *MergeTree 表中，并且刷新的数据将从 *MergeTree 中读取

does that also mean Materialized Views would be populated?

不清楚， CREATE MATERIALIZED VIEW as trigger FROM *MergeTree table 还是 trigger FROM the Buffer 表，以及你将哪个表引擎用于 TO table 子句？

我建议 CREATE MATERIALIZED VIEW 作为底层 MergeTree 表的触发器