Hacker News Reader

Comment by hodgesrm | Hacker News Reader

CEO of Altinity here, also editor of the blog article. It would be more interesting to address the points that it raises. If you are an open source user of ClickHouse, do you really want basic features like object storage for tables or ability to delete data efficiently withheld?

This question is important regardless of who raises it. Projects like Kafka, Spark, PostgreSQL, and Kubernetes (among others) have solved it while allowing good returns to those who contribute.

p.s., We spent 7% of budget on marketing last month. A sizable fraction of our budget is devoted to open source contributions ClickHouse and ecosystem projects.

View on HN

i appreciate your work here man, altinity even wrote a lot of useful blog posts about clickhouse back then, love those stuff.

this whole thing reminds me of elastic and hashicorp, and it's hard to pick sides given that the core maintainers also worked their assess of building it in public, and the community contributors also put their effort into it.

i think this common theme is unlocking a new era of software where core maintainers productize the main product slapped with a bsl license and the community (incl other businesses) maintain their own fork.

it's great that discussions like this are being brought up and talked about.

Thanks. That's exactly why we wrote the article. Beyond any commercial considerations, we have worked with ClickHouse for many years and are personally invested in seeing it become the default analytic database worldwide. I believe the best path to that goal is robust support for open source development and distribution.

Lots of other competitors like Apache Pinot, Apache Druid and StarRocks are fighting in that default analytics space.

StarRocks has compute/storage separation in open-source as example.

Not only. Transactions, UPDATES, CBO, Better join optimizations.

It seems that someone is stuck in 2016, when there is no good alternatives for ClickHouse exist in open source.

When datasets are small and can easily fit into a single node [a few terabytes], this isn't as much of an issue. Yet when datasets grow far larger, or when compute/QPS needs grow while the dataset grows slower — when either side of the equation does not scale in balanced proportion with each other — that's when this separation of compute & storage becomes vital. [Either that, or you need to find hardware servers or cloud instance types that also support this imbalance of compute & storage, which is sometimes harder to do; it also locks you into a hardware configuration that cannot dynamically scale as needs and workloads change.]

Apache Pinot also offers the same 2-tier compute/storage separation. And it also has nodes for minion [administrative] tasks. Again, these are more issues for larger scale analytical use cases.

> Apache Pinot also offers the same 2-tier compute/storage separation.

Based on looking at the docs, I don't think so. Maybe only with HDFS. Feel free to link to a page that says otherwise.

The Brokers are the compute layer. The Servers are the storage later.

Note that this is separate from the fact that the Servers can also be in a tiered storage configuration.

https://docs.pinot.apache.org/basics/architecture

Reply on news.ycombinator.com