Using ClickHouse to scale an events engine
1–10 of 100 posts
Re: Using ClickHouse to scale an events engine
#2And if you use MariaDB, just enable columnstore. Why not treat yourself to s3 backed storage while you are there?
It is extremely cost effective when you can scale a different workload without migrating.
Re: Using ClickHouse to scale an events engine
#3And if you use MariaDB, just enable columnstore. Why not treat yourself to s3 backed storage while you are there? It is extremely cost effective when you can scale a different workload without migrating.
This is no shade to postgres or maria, but they don’t hold a candle to the simplicity, speed, and cost efficiency of clickhouse for olap needs.
Re: Using ClickHouse to scale an events engine
#4And if you use MariaDB, just enable columnstore. Why not treat yourself to s3 backed storage while you are there? It is extremely cost effective when you can scale a different workload without migrating.
This is no shade to postgres or maria, but they don’t hold a candle to the simplicity, speed, and cost efficiency of clickhouse for olap needs.
And I mean why should they? They work great for what they are made for and that is all that matters!
Re: Using ClickHouse to scale an events engine
#5deleting this comment because apparently jokes are not received well here
Re: Using ClickHouse to scale an events engine
#6I'm curious: how many rows Lago store in its CH cluster? Do they collect data for fighting fraud?
PG can handle a billion rows easily.
Re: Using ClickHouse to scale an events engine
#7deleting this comment because apparently jokes are not received well here
> Recently, the most interesting rift in the Postgres vs OLAP space is [Hydra](https://www.hydra.so), an open-source, column-oriented distribution of Postgres that was very recently launched (after our migration to ClickHouse). Had Hydra been available during our decision-making time period, we might’ve made a different choice.
There will likely be a good OLAP solution (possibly implemented as an extension) in Postgres in the next year or so. Many companies are working on it (Hydra, Parade[0], etc.)
Re: Using ClickHouse to scale an events engine
#8> Recently, the most interesting rift in the Postgres vs OLAP space is [Hydra](https://www.hydra.so), an open-source, column-oriented distribution of Postgres that was very recently launched (after our migration to ClickHouse). Had Hydra been available during our decision-making time period, we might’ve made a different choice.
There will likely be a good OLAP solution (possibly implemented as an extension) in Postgres in the next year or so. There are a few companies are working on it (Hydra, Parade[0], tembo etc.).
Re: Using ClickHouse to scale an events engine
#9I'm curious: how many rows Lago store in its CH cluster? Do they collect data for fighting fraud? PG can handle a billion rows easily.
Reading between the lines, given they're talking > 1 million rows per minute, I'd guess on the order of trillions of rows rather than billions (assuming they retain data for more than a couple of weeks)
Re: Using ClickHouse to scale an events engine
#10And if you use MariaDB, just enable columnstore. Why not treat yourself to s3 backed storage while you are there? It is extremely cost effective when you can scale a different workload without migrating.
This is no shade to postgres or maria, but they don’t hold a candle to the simplicity, speed, and cost efficiency of clickhouse for olap needs.
I have tons of OOMs with clickhouse on larger than RAM OLAP queries.
While postgres works fine (even it is slower, but actually returns results)