Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do in-memory OLAP engines have advantages over the traditional OLAP engines backed by enough RAM to contain the entire cube(s)?

For example, if I use a MOLAP engine (SSAS) and GB / TB of RAM where the entire cube (or even star-schema) is RAM resident, what is the difference compared to something like TM1 / SAP HANA?

share|improve this question
up vote 4 down vote accepted

Databases designed with the assumption that they will be entirely resident in main memory can use structures such as T-tree indexes. But the real advantage is, IMDBs are just simpler. They do less (as they don't have to worry about managing a cache, or serializing writes for consistency, or anything to do with ACID-compliant I/O at all) so they execute fewer instructions on the hardware to carry out the same "work". A general-purpose database has to be all things to all people; like a Leatherman has a dozen tools, but sometimes you just need a cutting edge, so you buy a blade from Cold Steel, and no-one debates that it is a better knife!

share|improve this answer
    
s/Cold Steel/Benchmade/ ;) – MattK Nov 6 '11 at 21:03

Not my field of expertise but as I understand it the difference in the majority of so-called in-memory OLAP databases (not a term I'm fond of, it's used as marketing pitch more than as a fair comparison of technologies) is column store indexes.

Column-Stores vs Row-Stores (How Different Are They Really) is a good intro to the technology if you're familiar with traditional OLTP and OLAP database structures.

share|improve this answer

Column store indexes will make an appearance in SQL Server 2012 (aka 'Denali').

Here is a link to a Power Point presentation by Conor Cunningham, Principal Software Architect in the SQL Server Query Processor team covering this new feature.

share|improve this answer

Column stores allow for significant data compression in a way that isn't possible in a row store system. Basically all values in a column are stored only once in a dictionary then the DB stores an integer dictionary key instead of the original value. If you had a row store DB in memory it would but significantly larger, and more impractical give the cost of memory. The performance improvements are significant enough that you no longer need to pre-aggregate transaction data and Cubes are not necessary in most cases.

Also because the column store keeps all of a columns values in sequential memory blocks scanning has fewer blocks to skip in operations like Select. There are however some drawbacks to Column Stores transactionally, and HANA for instance added rowstore tables in later versions.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.