使用像MonetDB这样的柱状数据库来避免维度建模？

Question

I was wondering if you think it's reasonable, using monetdb (or another columnar database) to put all of your data in one big, flat table rather than breaking it up into several related tables.

For example, a database of used cars, flat, might look like:

Make    Model   Year   Color    Mileage
Chevy   Malibu  2009   orange   102100   
Chevy   Malibu  2009   orange   98112
Chevy   Malibu  2008   orange   210232
Chevy   Malibu  2009   pink     150100

Noticing the redundancy in Make-Model-Year-Color, in a SQL database or excel spreadsheet or whatever, you might have two tables like:

mId   Make   Model   Year  Color
1     Chevy  Malibu  2009  orange
2     Chevy  Malibu  2008  orange
3     Chevy  Malibu  2009  pink

mId   Mileage
1     102100   
1     98112
2     210232
3     150100

This helps with the redundancy at the expense of more complex queries and having to think about how to decompose (break up) the tables.

I was reading about columnar databases and monetdb in particular. It seems like, since monetdb compresses columns individually that the redundancy doesn't matter and you could just use the flat table expecting same-or-better performance (query time, disk usage) as a well-decomposed set of relational tables would provide. This saves design effort, but even better lets you completely automate schema design -- by avoiding it.

What do you think? Is there some hidden cost that I'm not seeing?

Answer 1

Seems like you got it right. In my experience Columnar Databases in general and MonetDB particularly deliver extremely fast query times with data structure like you have described. For the example you described, a Columnar database will Encode and Compress each column (naturally containing data of the same type, with many repetitions).

Anyway, if your workload include lot's of updates, benchmark the solution before deciding.

Personally I've seem MonetDB performs much better than most commercial Column Oriented Databases and much-much better then Row oriented or NoSQL, but the bottom line to keep in mind is that every case has it's own behavior.

Answer 2

What you are describing is (afaik) called the "unified table approach". Very smart people tried implementing systems around this idea and gave up on it. The latest (unsuccessful) attempt was the IBM DB2 Blink Project (read page 3 of http://homepages.cwi.nl/~idreos/BlinkDebull2012.pdf ). The essence: from a query processing point of view, you will generally be better of with normalized schemas rather than having the system figure out your schema for you.

To answer your specific question: MonetDB does not compress data other than strings (and even those only if there are few unique strings). I'd advise you to spend the effort to define a relational schema or switch to a schemaless DBMS if you really cannot. This will, naturally come at a performance penalty.