Skip to Content

Quite a few years ago here at SDN, I mentioned a new database concept called “c-store” that had been pioneered by the great Michael Stonebraker (among others) and was being developed as a practical BW/BI product by a start-up company called Vertica in Cambridge MA. 

 

I learned of “c-store” from my friend Bill Mann, who was (and is) a lead developer for Vertica, and has a long history of being associated with breakthru database products, from his earliest days at Lincoln Labs in the 60’s, thru his involvment with CCA’s Model 204 DB (the only US DBMS product supporting inverted-file access like ADABAS), to his later involvment in the Oracle parallelization project at Kendall Square Research, etc.

 

And I knew that if: 1) a giant like Stonebraker was involved in the conceptual birth of “c-store”, and 2) a pro like Bill was willing to become actively involved in developing it, then “c-store” was a technology to watch. 

 

 Well, lo and behold!

 

In particular, “lo and behold” two very recent events involving the “c-store” concept:

 

1) SAP has implemented some version of it in HANA. (Unless I’m badly mistaken, “c-store” is essentially what SAP bills as “columnar storage”.)

 

2) After teaming with Vertica on an analytics appliance, HP has decided to go ahead and just acquire Vertica outright.

 

So, it seems to me that one obvious question for both SAP marketeers and SAP’s customers is going to be:

 

why HANA and not the HP/Vertica appliance?

 

And it seems to me that SAP is going to be able to come up with only one basic answer to this question (apart from price-point related answers, of course):

 

because HANA is eventually going to be fully-integrated with existing SAP tools that SAP customers have come to respect and revere.

 

So, unless I’m misreading the tea leaves completely, HANA accessibility via ABAP will be SAP’s chief argument in what is sure to be an epic struggle between the two appliances.

 

But if anyone has any other ideas about how SAP can position HANA against its natural competitor, I’d be interested in hearing them.

 

And I’m sure SAP will be also … heh heh heh.

 

 

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Jonathan Wilson
    Hi David,

    You pose a really good question. Essentially is there anything unique about HANA. I think the answer is Yes, but it’s not because of the use of in-memory, or the storage format, or the algorithms, or pretty much any of the other technical aspects that get a lot of press.

    The fundamental difference with HANA is that everything is put together specifically to provide the optimal environment for Enterprise (i.e. SAP) applications. The algorithms are chosen based on what works for SAP data, SAP structures and SAP users. The next step of course will be to optimise the SAP applications themselves and here SAP have a natural advantage that others will not be able to match.

    Others may be able to build generic equivalents, which may be very good in their own right, but SAP are not trying to build the best generic DB, they are trying to build the best DB for SAP, and I don’t see how anyone else will do a better job.

    Cheers,
    Jon

    (0) 
    1. David Halitsky
      Yes – I think you’re absolutely correct in what you say.

      Even if SAP’s Hana winds up as the 70-85% solution technically (compared to HP’s or other appliances), it will always wind-up as the115-130% solution functionally (which is essentially what you’re saying.)

      In particular, I know enough about c-store to know that knowledge of the “business” is absolutely critical to knowing what needs to be “columnized” to avoid the expensive I/O of row fetches.

      And as you say, no one knows this better than SAP and its customers.

      Of course, if SAP decides not to build enough flexibility into its approach to columnizing, then you’re going to get the usual rounds of complaints from customers, followed by the equivalent of “user exits”, etc.  But that’s normal in this business, isn’t it?

      Finally, I don’t mean to imply that there’s some reason that SAP’s HANA will necessarily wind-up as the 70-85% solution technically … it’s just worth noting that relatively speaking, SAP is the “new kid” on this particular “block”, so it may have some catching-up to do.

      Unless, of course, SAP has already licensed some stuff from HP, with whom SAP has always had a good relationship …

      Thanks again for taking the time to comment …

      djh

      (0) 
  2. Danny Rohde
    I would agree with  the previous comments that SAP accepts they will never be able to build better databases than Oracle or any other specialize database vendor. Nor will they be better in putting the hardware together than their hardware partners.

    For the hardware they have partnered already, for the database part they have a good basis in the theoretical foundations based in the Hasso Plattner institute in Potsdam as well as their previous acquisitions (who knows, Sybase IQ may share some features with HANA in the future).

    However. the big advantage is that SAP now controls both, the application layer and the database layer. Now they are not restricted by public interface definitions (e.g. SQL) when interacting between these layers. If you control both of them you can change the layer boundaries and optimize to an extend other competitors will not be able to.

    And that is exactly what – in my view – SAP does with pushing logic down the stack. Instead of doing the data intensive calculations in the application server, they push it down to the database and realize performance increases in the order of magnitudes.

    So, in conclusion: SAP will never have the best (in memory, columnar, you name it) database, but they can build the best integration between their software and their database.

    (0) 
    1. David Halitsky
      You wrote:

      “However. the big advantage is that SAP now controls both, the application layer and the database layer. Now they are not restricted by public interface definitions (e.g. SQL) when interacting between these layers. If you control both of them you can change the layer boundaries and optimize to an extend other competitors will not be able to.”

      Absolutely agree, 100%.  Not only that, but you said it so well the point couldn’t be clearer.

      SAP’s “Achilles heel” has always been the need for it to use “LCD” (lowest-common denominator) protocols between the app and db layers, in order to maintain “universality”.

      If SAP goes in the direction you’re suggesting, that “Achilles heel” disappears and is replaced by a superior “Achilles tendon.”

      Who says “white men can’t jump?” ( http://www.imdb.com/title/tt0105812/ )

      Best
      djh

      (0) 

Leave a Reply