Comments on: Mike Stonebraker may be oversimplifying data warehousing just a tad http://www.dbms2.com/2008/02/19/stonebraker-data-warehouse/ Choices in data management and analysis Fri, 08 Aug 2008 00:44:53 +0000 http://wordpress.org/?v=2.5.1 By: Curt Monash http://www.dbms2.com/2008/02/19/stonebraker-data-warehouse/#comment-73725 Curt Monash Wed, 20 Feb 2008 09:06:07 +0000 http://www.dbms2.com/2008/02/19/stonebraker-data-warehouse/#comment-73725 Oliver, I posted a while back on DATAllegro's rejoinder to the columnar guys -- they just partition vertically, getting many of the same benefits. Of course, this isn't quite as powerful or general in their case as it is in the case of columnar systems, but they have offsetting advantages. By the way, I think the ball's in your court on a phone call. Best, CAM Oliver,

I posted a while back on DATAllegro’s rejoinder to the columnar guys — they just partition vertically, getting many of the same benefits. Of course, this isn’t quite as powerful or general in their case as it is in the case of columnar systems, but they have offsetting advantages.

By the way, I think the ball’s in your court on a phone call.

Best,

CAM

]]> By: Oliver Ratzesberger http://www.dbms2.com/2008/02/19/stonebraker-data-warehouse/#comment-73724 Oliver Ratzesberger Wed, 20 Feb 2008 08:53:05 +0000 http://www.dbms2.com/2008/02/19/stonebraker-data-warehouse/#comment-73724 There is also the analytical workload on tables with VERY few columns: e.g. 1 column text. Think 100 billion lines of text. Works very well on certain platforms. Does that make it a row or column store or both? ;-) On the analytical db architecture I would agree that there will be many shades of gray. The single fact table approach just doesn't allow for holding all - and I mean all - of your atomic data in your dw environment. Why would you want to hold all of it? Because its the most intrinsic level of data you can get. All metrics, fact and KPIs derive from there - like the center of the universe. As long as you keep all atomic details you can always go back in time and come up with new KPIs and facts. If you keep doing that fact table design you always start from day 0 the moment you implement a new metric. Gets boring really fast. And one can't assume common keys either unless you are talking highly specialized departmental data marts. As you point out you quickly get to far too many dimensions, granularities and hierarchies that require more normalized data structures to hold them. While I can see use cases for column stores, I agree that there might just be as many use cases for row based dbs. And there is really nothing from preventing hybrid solutions... There is also the analytical workload on tables with VERY few columns: e.g. 1 column text. Think 100 billion lines of text. Works very well on certain platforms. Does that make it a row or column store or both? ;-)
On the analytical db architecture I would agree that there will be many shades of gray. The single fact table approach just doesn’t allow for holding all - and I mean all - of your atomic data in your dw environment. Why would you want to hold all of it? Because its the most intrinsic level of data you can get. All metrics, fact and KPIs derive from there - like the center of the universe. As long as you keep all atomic details you can always go back in time and come up with new KPIs and facts. If you keep doing that fact table design you always start from day 0 the moment you implement a new metric. Gets boring really fast.
And one can’t assume common keys either unless you are talking highly specialized departmental data marts. As you point out you quickly get to far too many dimensions, granularities and hierarchies that require more normalized data structures to hold them. While I can see use cases for column stores, I agree that there might just be as many use cases for row based dbs.
And there is really nothing from preventing hybrid solutions…

]]>