July 7, 2009

Hasso Plattner calls for in-memory OLTP column stores

Former SAP CEO Hasso Plattner has written a paper called A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database, in association with a SIGMOD keynote address.* The approach Plattner advocates is an MPP in-memory column store, presumably somewhat akin to SAP’s frequently renamed Business Warehouse Accelerator/Business Intelligence Accelerator/BWA/BIA/Son-of-TREX technology. There also are strong similarities to the MPP in-memory row store project H-Store/VoltDB, although I don’t know whether Plattner would go so far as to adopt the H-Store view that all transactions should run in stored procedures. Unsurprisingly, SAP applications are used as the OLTP paradigm throughout.

*Thanks to Dave Kellogg for tipping me off to Plattner’s paper. I only went to two SIGMOD sessions, neither of which was Plattner’s. Nobody actually mentioned Plattner’s talk to me when I was down at SIGMOD.

Perhaps the most interesting part is Plattner’s claim that what’s demanding about OLTP isn’t database updating per se, but rather maintaining aggregates for quick-response analytics. In his main example of that point, Plattner proposes a real-life “more than 18” table schema, of which 2 are base tables, and (most of?) the rest are materialized views that his proposed database architecture dispenses with (because analytic performance is sufficiently good without them). Thus, Plattner’s core columnar argument seemingly is

columnar –> natively fast analytics –> no need to maintain aggregates –> much lower update burden.

That said — if Plattner’s paper contained a clear statement of how much more expensive it is to insert or update a single row in a columnar vs. row-based system, I overlooked it. Instead, Plattner seems to be arguing that the volume of base-table updates is low enough that — whatever it may be — column-store update overhead is an acceptable price to pay.  (At one point he claims that only 5% of the data inserted in a financial application ever gets changed.) That may actually be true in a financial accounting system, but seems more questionable in a sufficiently large application that gets its updates from automatic devices, or from the consumer web.

Other highlights include:

Comments

7 Responses to “Hasso Plattner calls for in-memory OLTP column stores”

  1. Seth Grimes on July 11th, 2009 7:49 am

    Regarding the sensible argument:

    “columnar –> natively fast analytics –> no need to maintain aggregates –> much lower update burden”

    What about when, instead of aggregates, the columnar system needs to maintain software-managed *replicates* rather than aggregates? That’s the Vertica situation.

    Seth

  2. Curt Monash on July 11th, 2009 5:18 pm

    Very different cases, Seth. Aggregates are updated every time a FACT changes. Dimension tables are updated every time a dimension changes.

  3. joab jackson (joabj) 's status on Saturday, 18-Jul-09 13:36:58 UTC - Identi.ca on July 18th, 2009 9:37 am
  4. Ray Wang on SAP | DBMS2 -- DataBase Management System Services on December 11th, 2009 7:17 pm

    […] and Oracle’s (Fusion) efforts to meld memory-centric analytics with operational apps will be crucial for large enterprises — but perhaps only around the middle of the next […]

  5. Quick reactions to SAP acquiring Sybase | DBMS2 -- DataBase Management System Services on May 12th, 2010 7:54 pm

    […] SAP’s thoughts on in-memory database management are interesting. However, I think SAP’s oft-repeated claim that it has a lot of important in-memory database technology to bring to Sybase (or for that matter SAP customers) is mainly smoke and mirrors. Cool data access methods, good niche database products, and broadly applicable multi-domain DBMS innovations are three different things. Granting that SAP probably has the first and thinks it has the second is not the same as giving it much credence for having the third. […]

  6. online shoe stores in kenya on June 10th, 2016 1:58 am

    online shoe stores in kenya

    Hasso Plattner calls for in-memory OLTP column stores | DBMS 2 : DataBase Management System Services

  7. http://lavochkina.ru/10474-electricals-products-that-can-be-automated-in-and-about-the-pro/0 on June 13th, 2016 9:31 pm

    http://lavochkina.ru/10474-electricals-products-that-can-be-automated-in-and-about-the-pro/0

    Hasso Plattner calls for in-memory OLTP column stores | DBMS 2 : DataBase Management System Services

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.