3 ms·
From a quick look I didn't notice any mention of columnar storage. I would be very skeptical about any claim that a DB without columnar storage "can work extrem
by dgudkov 5y ago
From a quick look I didn't notice any mention of columnar storage. I would be very skeptical about any claim that a DB without columnar storage "can work extremely well as a data warehouse".
- dreyfan 5y agoTake a look at Kimball/Star-Schema. It's worked extremely well as a data warehouse technique for decades. That said, I think modern offerings (e.g. Clickhouse) are superior in most use cases, but it's definitely not impossible on a traditional row-oriented RDBMS.
- haddr 5y agobear in mind that Clikchouse will quickly fall short when squeezed into traditional star schema model (it's very inefficient on multiple joins, probably even can't handle more than 1 at the same time). You would really need a dabase engine that is columnar first but still operate on SQL without too much hidden pitfalls, and that is quite often challenging
- dreyfan 5y agoYes in Clickhouse you’d generally take a denormalized approach.
- hodgesrm 5y agoClickHouse can handle multiple joins just fine and has for a while. I just gave a conference talk on CH this morning that discussed this exact topic, among others. The fact is that for large datasets scans on denormalized fact tables parallelize well, which means you can (a) offer stable performance and (b) scale more efficiently. This is important for use cases like web analytics, where users play around with different dimensions and measures but still expect consistent response. Note also, dimensions for things like Year, Month, Week, and the like compress absurdly well. It is often way faster to scan these values than to join them.