MongoDB is even less like a column store than a row store is because there are no joins and all data must be stored in one place (without said joins).

Column Store = Each column is a file that can be scanned (oversimplification). Joins can be used to put data together.
Row Store = Each column is part of a file containing all columns (again, oversimplification). Joins can be used to put data together.
MongoDB = There is only one table period, and all columns and joins must be in one file unless you do a fake-join in your application.

For most purposes, column stores behave like row stores. Joins work, etc. Some of the performance characteristics will be different, though. Clearly if you’re using/selecting most columns, they won’t help much. They might even hurt! Which columns you filter by or select in a column store will make a big difference.

What you get out of MongoDB is map-reduce, and a natural ability to use a non-declarative (i.e. SQL) language that can be trivially paralellized without any planner magic. In other words, even if the physical layout sucks, you can throw hardware at it and expect that to help.

Also, the SSB schema is based on the TPC-H schema, which is denormalized.

So for example, on Oracle you could build materialized views to answer the queries, and allow Oracle to rewrite the SSB queries transparently to use your views, but this wouldn’t gain you much since each SSB query is executed only once.

A database engine might build a materialized view (or a specialized index) automatically behind the scenes on foreign key constraint definitions in order to improve the performance of the join. I believe that LucidDB builds such a structure on FK constraints, as does ScaleDB, Kickfire, and other database engines. Other engines focus on distributed hash-joins instead of materialization. Ideally, such an engine will have a high-performance way of building such a structure.

As I recall, the SSB benchmark was designed with a specialized type of DB2 materialized cube in mind, but I’d have to read the paper again to verify that.

I saw that LucidDB and InfoBright have a high compression rate. So if we make the SSB denormalization then probabilly the queries perfomance will grow up. Is that right?

Does anyone already made this kind of stuff?

Thanks

Speaking for LucidDB it’s unlikely you’d see a large increase if you denormalized to a flat table. Since we store column by column you’d see some change in size but it wouldn’t be substantial.

I was taking a look at SSB and then i was thinking if is possible to denormalize all tables from the SSB?

So database size will increase a lot but potencially the performance will grow up. Is that right? Is It possible?

Thanks and sorry for my poor englise
Pedro

We have some metrics from running a SF-10,000 to share for those interested. Notes on the paramters tweaked from the defaults are included as well. The dbgen issue with keys being re-used referenced by Marcin Z does show up at this scale.

The basic scenario; load a SF-10,000 and a SF-1,000 (60 billion and 6 billion facts respectively) into one InfiniDB instance on a 6 sever (8 cores, 16GB) stack attached to 4 FC attached LSI trays. Then run the queries in a stream against each and compare the relative time against each other.

Overall, the results were as expected; the overall processing behavior didn’t change as we scaled the fact table. Anyway, further details are available at: http://www.infinidb.org/myblog-admin/mysql-parallel-query-processing-of-60-billion-rows-via-infinidb.html .

Thanks – Jim Tommaney

I just use “du -sh *” on datadir, that’s all.