September 23, 2013

Thoughts on in-memory columnar add-ons

Oracle announced its in-memory columnar option Sunday. As usual, I wasn’t briefed; still, I have some observations. For starters:

I’d also add that Larry Ellison’s pitch “build columns to avoid all that index messiness” sounds like 80% bunk. The physical overhead should be at least as bad, and the main saving in administrative overhead should be that, in effect, you’re indexing ALL columns rather than picking and choosing.

Anyhow, this technology should be viewed as applying to traditional business transaction data, much more than to — for example — web interaction logs, or other machine-generated data. My thoughts around that distinction start:

But in a bit of evidence that disconfirms my case, one of the first SAP applications to require HANA was something called “Smart Meter Analytics”.

To see more specifically where this technology could be useful, let’s map it against my 2011 analytic database taxonomy.

I’ll finish by expanding on that last point.

Operational applications have always had analytics blended in. If nothing else, there were a lot of straight reports; sometimes there’s a bit of optimization as well. Workday, for example, has BI and search as two of its core OLTP UI metaphors, and has a lot of other BI snippets called worklets as well. (And by the way, a lot of Workday’s database is in-memory.) I’ve thought for years that operational/analytic blending would be a major area of competition between Oracle and SAP; hence — I believe — SAP’s acquisitions of Business Objects and KXEN. Columnar in-memory Oracle features, and similarly SAP HANA, seem well-suited to support such application elements.

Comments

5 Responses to “Thoughts on in-memory columnar add-ons”

  1. Mark Callaghan on September 23rd, 2013 12:52 pm

    Will be interesting to see the details (whitepapers). I have yet to read the BLU papers but with what little I know I think Microsoft took a very different approach than Oracle and I like the Hekaton effort — both the technology and integration.

  2. Oracle, the leader in relational databases, is playing catchup everywhere else — Tech News and Analysis on September 25th, 2013 11:16 am

    [...] To recap the OpenWorld news: Ellison kicked off it all off Sunday night with news of an in-memory database option for the latest Oracle 12C database which he said will run at “ungodly speed.” The in-memory option — which competes with the aforementioned HANA — will be broadly available next year. (Check out database guru Curt Monash’s take on the in-memory database fervor here.) [...]

  3. Oracle In-Memory Option: the good, the bad, the ugly | Big Data, Small Font on September 28th, 2013 6:20 pm

    [...] Option. While there is already a great discussion at Rob’s blog and further analysis at Curt’s, I thought I could add a [...]

  4. Ippokratis Pandis on October 7th, 2013 7:35 pm

    Curt,
    In this post you imply that BLU leverages the technology that manages indexes and massages it into an actual column store. That’s far from true. (Afaict it is true in the case of SQL Server’s Columnstore indexes, while I don’t know what 12c will be doing.)

    For more information about BLU, I recommend you read our very detailed VLDB 2013 paper, where we thoroughly describe (in uncharacteristic for an industrial track research paper detail) how BLU operates: https://t.co/KuayqEXqyG

    Best regards,
    -Ippokratis.

  5. Curt Monash on October 10th, 2013 6:15 am

    Ippokratis,

    Thanks! Edited accordingly.

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.