September 25, 2008

Another round of discussion on in-memory OLTP data management

Oracle Exadata was pre-teased as “Extreme performance.” Some incorrect speculation shortly before the announcement focused on the possibility of OLTP without disk, which clearly would speed things up a lot. I interpret that in part as being wishful thinking. :)

The most compelling approach I’ve seen to that problem yet is H-Store, which however makes some radical architectural assumptions. One point I didn’t stress in my earlier posts, but which turned out to be a deal-breaker for one early tire-kicker, is that to use H-Store you have to be able to shoehorn each transaction into its own stored procedure. Depending on how intricate your logic is, that might make it hard to port an existing app to H-Store.

Even for new apps, it could get in the way of some things you might want to do, such as rule-based processing. And that could be a problem. A significant fraction of the highest-performance OLTP apps are customer-facing, and customer-facing apps are one of the biggest areas where rule-based processing comes into play.

Comments

3 Responses to “Another round of discussion on in-memory OLTP data management”

  1. Chris Bird on April 30th, 2009 6:30 pm

    The whole stored procedure in C++ thing scares the living daylights out of me. I have never been a huge stored procedure fan, but then to have to downgrade to C++ in a proprietary fashion – that just seems like a strange way to go.

    I understand the logic, but it would have to be an otherwise compelling solution for me to contemplate it.

  2. Curt Monash on April 30th, 2009 8:46 pm

    I’m not going to check my notes as to what the latest language plan is for the most advanced H-Store commercialization project for H-Store is, since it was under NDA otherwise. (But please contact me privately about same if you care.) All I recall is that the Ruby idea was dropped due to performance.

    I’d expect good language flexibility to be in early, whether or not it actually is there Day 1.

  3. Chris Bird on May 1st, 2009 8:01 am

    I have just been reading the various white papers sent to me by Vertica. C++ is feartured front and center.

    IMHO the language needs to be slightly higher level – you don’t want to be in a place where a pinhole sized memory leak brings down the whole database.

    I can un understand why Ruby would be eliminated, there really aren’t (yet?) any rocking fast VMs that I know about. It would be interesting to see the Model code of Rails’s MVC etructure execute “down there” though.

    That leaves us with java. As long as they stay away from EJB, and do something lightweight, I suppose that will be OK. Since Oracle owns it (or will soon), every DBMS vendor that embeds java will at least look twice.

    Whatever the method, there has to be a whole lot better IDE, debug and development support than the version 1.0 kinds of stored procedures that we see today.

    I would expect:
    Realtime debuggers
    Unit test frameworks
    Refactoring capabilities
    Version management
    Team development capabilities

    all to be present before the thing can be considered ready for prime time.

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.