Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing ClickHouse: Tactics that worked for us

highlight.io

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Optimizing ClickHouse: Tactics that worked for us

#11

Post by ople »

Very interesting observations! Merge performance tuning seems often overlooked even though it's a key aspect of sustained ClickHouse performance.

I also like that the blog is quite compact and gets the points across without getting too much into the weeds.

One thing I've noticed also that bloom filter index types can be quite costly to merge. In many cases that's acceptable though due to the massive benefit they provide for text queries. One just has to be mindful of the overhead when adding them.

Re: Optimizing ClickHouse: Tactics that worked for us

#12

Post by cpursley »

podoman wrote: post #3
Syntaf wrote: post #2

We've been using highlight for our bootstrapped member management platform[1] and I gotta say I'm super impressed with the session replay feature, it's really helpful for understanding user behavior at a fraction of the price of competitors. I remember wanting to use Heap's session replay only to release they want hundreds of dollars per _month_, my last bill with highlight was $2.38 I recall. That's all to say that…

Highlight.io cofounder here. Thanks for the shout out. Glad to hear you like the product; continue to share feedback as you use it!

Highlight looks great. Does it support Elixir LiveView?

Re: Optimizing ClickHouse: Tactics that worked for us

#13

Post by Dachande663 »

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...

Re: Optimizing ClickHouse: Tactics that worked for us

#15

Post by ericb »

Dachande663 wrote: post #13

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...

What sort of insert volume are you handling with that?

Re: Optimizing ClickHouse: Tactics that worked for us

#16

Post by JosephRedfern »

Thanks for sharing! I'm curious as to your approach to changing the ORDER BY key for such large tables without significant downtime, since AFAIK this can't be done in place (see: https://kb.altinity.com/altinity-kb-schema-design/change-ord...). Are you able to share any details?

Re: Optimizing ClickHouse: Tactics that worked for us

#18

Post by vadman97 »

ople wrote: post #11

Very interesting observations! Merge performance tuning seems often overlooked even though it's a key aspect of sustained ClickHouse performance. I also like that the blog is quite compact and gets the points across without getting too much into the weeds. One thing I've noticed also that bloom filter index types can be quite costly to merge. In many cases that's acceptable though due to the massive benefit they prov…

Exploring bloom filter index merges would be an interesting addition. I do wish it were easier to profile merge performance to break down where most of the CPU time is being spent.

Re: Optimizing ClickHouse: Tactics that worked for us

#19

Post by vadman97 »

JosephRedfern wrote: post #16

Thanks for sharing! I'm curious as to your approach to changing the ORDER BY key for such large tables without significant downtime, since AFAIK this can't be done in place (see: https://kb.altinity.com/altinity-kb-schema-design/change-ord... ). Are you able to share any details?

Materialized views can help change the ORDER BY with 0 downtime:

* Create a new version of the table with the new ORDER BY.

* Create a materialized view that will insert from the old table to the new table.

* Update your application code to query the new table.

* Start inserting data into the new table.

Re: Optimizing ClickHouse: Tactics that worked for us

#20

Post by vadman97 »

cpursley wrote: post #12
podoman wrote: post #3

Earlier quoted context omitted.

Highlight.io cofounder here. Thanks for the shout out. Glad to hear you like the product; continue to share feedback as you use it!

Highlight looks great. Does it support Elixir LiveView?

We do via the OpenTelemetry Elixir SDK (and the Phoenix extension) https://opentelemetry.io/docs/languages/erlang/
Post reply on HN