{"id":12376,"date":"2013-12-18T12:54:27","date_gmt":"2013-12-18T11:54:27","guid":{"rendered":"http:\/\/timoelliott.com\/blog\/?p=5989"},"modified":"2013-12-18T12:54:27","modified_gmt":"2013-12-18T11:54:27","slug":"the-battle-of-the-database-elephants","status":"publish","type":"post","link":"https:\/\/timoelliott.com\/blog\/2013\/12\/the-battle-of-the-database-elephants.html","title":{"rendered":"The Battle of The Database Elephants"},"content":{"rendered":"

\"database-elephants-banner\"<\/p>\n

\"stonebraker_x220\"GigaOM Research<\/a> recently published an interview<\/a> with database rock star Michael Stonebraker<\/a> on \u201cthe impending battle of the database elephants,\u201d covering his thoughts on the disruption in the database market.<\/p>\n

This blog includes the excerpts I thought were most interesting:<\/p>\n

SAP enters the database market<\/h3>\n

“In the OLTP market, recent advances have completely convinced me that main memory database systems … are going to completely take over<\/strong>”<\/p>\n

“The database market is really alive, vibrant, with lots of new ideas, and I think the legacy vendors face the “innovator’s dilemma” in spades”<\/p>\n

“SAP is in the database business and SAP customers are Oracle’s biggest customer right now, and among the elephants there\u2019s going to be a duke it out between Oracle and SAP<\/strong> and I\u2019m delighted to look on from the side.\u201d<\/p><\/blockquote>\n

Legacy databases are obsolete<\/h3>\n

“I think data warehouses are an SQL market. It\u2019s just there\u2019s the new way to do it and the old way to do it, and the legacy vendors have the old way to do it. In OLTP, I think it\u2019s a SQL market also, and the legacy vendors have the old way and there\u2019s a new, much better way<\/strong>.<\/p>\n

In round numbers, the database market is a third OLTP, a third data warehouses and a third everything else, and I think \u201ceverything else\u201d is primarily a non-SQL market. I think in datawarehouses and in OLTP, it will remain a SQL market, it\u2019s just the implementations have to change from what they are now to better ideas.<\/p>\n

The codebases that the elephants, the legacy vendors are selling right now are 25 years old. And it’s time for them to be retired and sent to the home for obsolete software!<\/strong>“<\/p><\/blockquote>\n

Modern ideas behind HANA<\/h3>\n

“My expectation is that SAP will make a compelling case for their SAP customers switching off of Oracle and onto HANA<\/strong>. That case has not been made yet, it\u2019s way to early. The real thing to watch is how SAP customers are going to react to persuasion from SAP to switch database systems.”<\/p>\n

“I\u2019ve looked at the ideas [behind HANA], and I think the ideas are good<\/strong>. They are modern ideas. It’s too soon to whether the implementation will hold up to the ideas. My suspicion is that it deserves to be taken seriously, and that it will have a very large elephant pushing it very hard”<\/p><\/blockquote>\n

Gap between NoSQL and SQL narrowing<\/h3>\n

\u201cMy favorite way to categorize the NoSQL guys is that they started off as \u201cNoSQL,\u201d meaning \u201cSQL is bad.\u201d After a while, that turned into NoSQL\u00a0 meaning \u201cnot only SQL\u201d \u2013 SQL was fine, and they wanted to co-exist with SQL systems. My prediction is that NoSQL will come to mean “not yet SQL.” <\/strong><\/p>\n

The two things the NoSQL guys say is number one, \u201cdon’t use SQL, instead use low-level record-at-a-time language.\u201d Cassandra and Mongo have both announced what looks like \u2013 unless you squint\u2014a high level language that is basically SQL. I think the NoSQL guys will move to putting higher-level languages on their products, and thereby make the difference between NoSQL and SQL get much smaller.<\/p>\n

I also think that the second thing is that they don’t like ACID<\/a>.\u00a0 The biggest proponent of NoSQL non-ACID has been historically a guy named Jeff Dean<\/a> at Google, who is responsible for most or all of their database offerings. And he and the team recently wrote a system called Spanner<\/a>. Spanner is a pure ACID system. So Google is moving to ACID and I think the NoSQL market will move away from <\/strong>eventual consistency<\/strong><\/a> and toward ACID<\/strong>, and so I think the distinction between the two camps will decrease in the future.<\/p>\n

\u201cThere\u2019s been 40 years of DBMS research, starting way back in the 70s. This was a\u00a0 huge debate in the 70s in the relational database research world, and if you go back and look at the history in the 70s, all the discussion today of ACID vs non-ACID all got wrangled out back then. The NoSQL engineers didn’t… You know, “If you don’t pay attention to history, you’re going to have to repeat it<\/strong>,” which I think is what\u2019s happening.<\/p><\/blockquote>\n

Did Oracle take good care of TimesTen<\/a>?<\/h3>\n

\"only-10-percent-useful-work\"<\/a>“That’s a technical question… I and some others wrote a paper called “OLTP through the looking-glass, and what we found there<\/a>.”<\/p>\n

We took an open source legacy DBMS called Shore<\/a> that is from university of Wisconsin. And we said \u201csuppose all the data fits in main memory?\u201d If you have a terabyte of data or less, or maybe even these days two or three or five terabytes, it\u2019s perfectly reasonable to put that in main memory.<\/p>\n

So we ran the industry standard benchmark, which is TPC-C<\/a>, on data with a buffer pool big enough to hold all the data. And then we said \u201cwhere do all the cycles go?\u201d<\/p>\n

The answers were a little bit shocking: less than 10% goes into useful work \u2013 meaning actually solving the SQL command that comes in.<\/strong> The other 90+% went to four different places [\u2026.]<\/p>\n

TimesTen was architected in the 90s [\u2026] it\u2019s got three of the four big pieces of overhead, and so its ability to go blindingly fast is really compromised. And so I think the question is not “has any particular system been well taken care of?” or not, it’s more than that any system written more than six or eight years ago didn’t realize where all the overhead is going, and wasn’t architected in a way that goes blindingly fast.”<\/p><\/blockquote>\n

The full interview<\/h3>\n

Listen to the full \u201cStructure Show<\/a>\u201d (The Stonebraker portion starts at 18:20)<\/p>\n