3 ms·

> It already seems to be an afterthought after Gigapipe and Firebolt debuts. This is referring to Clickhouse Inc. and is way off the mark. If you're looking fo

> It already seems to be an afterthought after Gigapipe and Firebolt debuts. This is referring to Clickhouse Inc. and is way off the mark. If you're looking for hosted Clickhouse, why would a company whose CTO is the creator of Clickhouse be an "afterthought"? Their cloud product offers separation of storage and compute, but you still have an escape hatch to self-hosting if you need it (which you wouldn't have with Firebolt). Clickhouse has only one major flaw, joins. If Clickhouse improves join's, it will become the standard open source OLAP database.

intrasight 4y ago
I hadn't heard of Clickhouse, so had a look. It seems to be an OLAP backing store and not what one would call an OLAP database - because it doesn't support MDX. You have to use Mondrian as the OLAP server middleware. Or am I misunderstanding? And why would one use Clickhouse vs Sql Server as the backing store for OLAP? Is it that much cheaper?
- MrBuddyCasino 4y ago
  ClickHouse is ridiculously fast, and its architecture is versatile while still being easy to setup. Its just a very well made product.
- hodgesrm 4y ago
  It's both faster and cheaper. ClickHouse gets a lot of migrations off SQL Server. Not every dataset works, of course. As noted elsewhere ClickHouse does not handle complex joins well.
aristocrab 4y ago
Couldn't agree more with the join statement. Working on a data heavy SaaS, we've looked to overhaul our database for almost a year now, and Clickhouse hits every nail on the head for our needs except this. Most OLAP databases, and especially Clickhouse, seem to suffer from the syndrome of being structurally incompatible with relational data - understandably enough for mostly columnar databases, but still have rather weak solutions to bridge the gap. The author talks about an AP/TP hybrid being the industry killer, and it seems to ring true if we measure success on the profitability of the products that will be built on it. Data is where the money is, but not in end result data like IoT performance metrics / generally 1-dimensional data etc but in the intersections of high volumes of data. This ends up giving you two options right now if you're building in this space; A. very expensive and slow/tedious feature building on OLTP databases with lots of preprocessing or B. low cost, high performance but limited in features on OLAP.

intrasight 4y ago

I hadn't heard of Clickhouse, so had a look. It seems to be an OLAP backing store and not what one would call an OLAP database - because it doesn't support MDX. You have to use Mondrian as the OLAP server middleware. Or am I misunderstanding? And why would one use Clickhouse vs Sql Server as the backing store for OLAP? Is it that much cheaper?

MrBuddyCasino 4y ago
ClickHouse is ridiculously fast, and its architecture is versatile while still being easy to setup. Its just a very well made product.
hodgesrm 4y ago
It's both faster and cheaper. ClickHouse gets a lot of migrations off SQL Server. Not every dataset works, of course. As noted elsewhere ClickHouse does not handle complex joins well.

aristocrab 4y ago

Couldn't agree more with the join statement. Working on a data heavy SaaS, we've looked to overhaul our database for almost a year now, and Clickhouse hits every nail on the head for our needs except this. Most OLAP databases, and especially Clickhouse, seem to suffer from the syndrome of being structurally incompatible with relational data - understandably enough for mostly columnar databases, but still have rather weak solutions to bridge the gap. The author talks about an AP/TP hybrid being the industry killer, and it seems to ring true if we measure success on the profitability of the products that will be built on it. Data is where the money is, but not in end result data like IoT performance metrics / generally 1-dimensional data etc but in the intersections of high volumes of data. This ends up giving you two options right now if you're building in this space; A. very expensive and slow/tedious feature building on OLTP databases with lots of preprocessing or B. low cost, high performance but limited in features on OLAP.