21–26 of 26 posts
We found the "lots of small inserts" issue, and fixed it by just using the Buffered table engine[0]. Can create it as a replica of the destination table, and it stores inserts in memory until they cross a threshold and are written. Super simple and took 5 minutes. [0] https://clickhouse.com/docs/en/engines/table-engines/special...
We found the "lots of small inserts" issue, and fixed it by just using the Buffered table engine[0]. Can create it as a replica of the destination table, and it stores inserts in memory until they cross a threshold and are written. Super simple and took 5 minutes. [0] https://clickhouse.com/docs/en/engines/table-engines/special...
Why not just use async inserts that internally do the same thing?
Plus, async inserts are only available on ClickHouse Cloud.
Earlier quoted context omitted.
Why not just use async inserts that internally do the same thing?
Once we hit >100k inserts per second, async inserts didn't work well for us because we had limited control over the background async insert batching happening on the cluster. The background inserts would be too small, resulting in many merges running, causing high CPU, causing high back-pressure (latency) on async inserts which would just result in an ingestion delay. Plus, async inserts are only available on ClickHo…
To enable asynchronous INSERTs, set `async_insert` to true.
Here is the documentation: https://clickhouse.com/docs/en/optimize/asynchronous-inserts ; intro: https://clickhouse.com/blog/asynchronous-data-inserts-in-cli... and a hands-on guide: https://clickhouse.com/blog/monitoring-asynchronous-data-ins...
Earlier quoted context omitted.
Why not just use async inserts that internally do the same thing?
Once we hit >100k inserts per second, async inserts didn't work well for us because we had limited control over the background async insert batching happening on the cluster. The background inserts would be too small, resulting in many merges running, causing high CPU, causing high back-pressure (latency) on async inserts which would just result in an ingestion delay. Plus, async inserts are only available on ClickHo…
Earlier quoted context omitted.
Once we hit >100k inserts per second, async inserts didn't work well for us because we had limited control over the background async insert batching happening on the cluster. The background inserts would be too small, resulting in many merges running, causing high CPU, causing high back-pressure (latency) on async inserts which would just result in an ingestion delay. Plus, async inserts are only available on ClickHo…
Like sibling comment is saying - async inserts are part of the oss version. Batch flushes are tunable in two dimensions - size and latency. I think it’s likely the default size was just too low for your usecase
> We opted to use the ClickHouse Kafka Connect Sink that implements batched writes and exactly-once semantics achieved through ClickHouse Keeper. Just a heads up, You've got repeated line there
Put up a fix, thanks: https://github.com/highlight/highlight/pull/8571
> OTLP