Search
Search
Mike Stonebraker
December 5, 2013

SE Radio 199: Michael Stonebraker on Current Developments in Databases

Recording Venue: Skype
Guest: Michael Stonebraker
Dr. Michael Stonebraker, one of the leading researchers and technology entrepreneurs in the database space, joins Robert for a discussion of database architecture and the emerging NewSQL family of databases. Dr. Stonebraker opens with his take on how the database market is segmented around a small number of use cases: OLTP, data warehouses, and event stream processing. He discusses the origins of the standard architecture for OLTP, which is row-based, and says it’s no longer optimal for any of the use cases that it is applied to. He proceeds to describe some research he has done, showing that row-based databases spend about 90 percent of their time acquiring and releasing locks, buffer management, and other activities that could be characterized as overhead in comparison to main task of reading and writing data. These results, which in Stonebraker’s view are intrinsic to the row-based architecture, require a new architecture to overcome. The discussion proceeds to a new database architecture, known as “NewSQL” or “NewOLTP,” which is single-threaded, lock-free, doesn’t require disk I/O in the critical path, and can scale out to a large multiple node cluster. Stonebraker criticizes the eventual consistency model that some NoSQL distributed systems employ and he defends the ACID guarantees as a superior model. The interview closes with a discussion about database education in university curricula and Stonebraker’s thoughts on the place of Hadoop in the data storage space.

Show Notes

Tagged as:
Join the discussion
13 comments

  • Outstanding interview. Looks like much of what I learned about database architecture from undergrad, is now no longer relevant. Brave new world indeed.
    One impressive takeaway for me was the robust design of SQL, how in spite of all these fundamental hardware changes (cheaper memory, more cores), SQL still survives — even the noSQL guys, as Stonebraker says are now “Not yet SQL”.
    Thank you for this.

  • Thank you and congratulations. This episode was really good!
    I was facing conflicts related to RDBMS in my work this month. This episode was much informative.

  • I have to say that I totally disagree with Stonkbraker’s premise. The standard database is not “going away”, many businesses use it, and it is a very useful mental model that I believe computer programmers should learn.

    It is true that most super-large implementations have been forced to abandon some of the features of traditional database models, for cost/performance reasons. But removing features is not a feature. Leaving out a feature like foreign key constraints is not a benefit, it is a necessary evil.

    I believe that this topic would have been better framed with the old principle that 80% of users only use 20% of the features, and that furthermore which 20% are being used by any one user varies significantly. So if you are Amazon, your 20% required features is different from Microsoft, or the mom&pop grocery store that is just keeping inventory.

  • Interesting, however many of the problems attributed to “traditional” database architectures are actually the result of a poor system design. By this I mean the entire system architecture as well as the database design itself. There are too many drag-and-drop programmers out there who are attempting to design demanding OLTP systems with insufficient knowledge and experience of how to design and build these systems for the real world. It works in Visual Studio so they think it will work anywhere.

    Expertise and competency of the designer(s) & project lead will continue to be the most factor in the overall success of any system, regardless of underlying technology.

  • one of the best episodes in a long time. It was so good that I listened to it twice back to back, which hasn’t happened with other SE-Radio topics before. It would be interesting if you can interview people from the NoSQL or traditional SQL products and have them answer some of Stonebrakers conclusions.

More from this show

Menu

Recent posts