April 20, 2009

MySQL storage engine round-up, with Oracle-related thoughts

Here’s what I know about MySQL storage engines, more or less.

Comments

14 Responses to “MySQL storage engine round-up, with Oracle-related thoughts”

  1. Dmitriy on April 20th, 2009 10:05 am

    One item to add to your list:

    The MySQL consulting shop Percona recently released their branch of the InnoDB called XtraDB: http://www.percona.com/docs/wiki/Percona-XtraDB:start

    It mostly focuses on scalability and logging/recovery issues. I get the feeling a big part of the motivation for the fork was Oracle’s slow rate of patch adoption.

  2. Peter on April 20th, 2009 1:07 pm

    Oracle will slowly very slowly add new features to MySQL, whenever it is necessary to fend off a low end competitor.

  3. Curt Monash on April 20th, 2009 2:54 pm

    Peter,

    Frankly, I think MySQL’s development was so messed up that the minimum level of progress Oracle could make and keep its pride is more than Sun/MySQL was apt to achieve on its own. Those guys ARE serious about database technology.

    That doesn’t mean there won’t be a deliberately-maintained gap between MySQL and Oracle capabilities, of course.

  4. Mike on April 20th, 2009 7:02 pm

    Curt,it has been a while since we spoke (www.scaledb.com). Yes Vern Watts, was a great man and a real pioneer in the database world as the chief architect of IBM IMS (father of shared-disk clustering) and then ScaleDB.

    We just announced the beta of our shared-disk clustering storage engine for MySQL. With the Oracle acquisition of Sun, things get complicated, especially since our storage engine delivers shared-disk clustering like Oracle RAC. We live in interesting times.

  5. Curt Monash on April 20th, 2009 8:35 pm

    Mike,

    One job posting you had described ScaleDB as “newly funded”. What does that mean? :)

    Best,

    CAM

  6. Max Lybbert on April 20th, 2009 9:07 pm

    My main concern is the clash of cultures between Oracle and MySQL developers. From what I’ve seen, companies that handle lots of mergers successfully have explicit policies in place to handle culture wars (and often those policies are “the culture at the acquiring company always wins”).

  7. Mark Callaghan on April 22nd, 2009 3:08 am

    Curt,

    I love your blog, but I think you need to be more careful when your writing mixes what you know (and you know a lot) with what you have been told. According to you MyISAM is fast and InnoDB is slow and mediocre. I disagree and I use InnoDB a lot. I also run a lot of performance tests with it. In most cases that matter to me, InnoDB is much faster than MyISAM. The combination of InnoDB+MySQL is extremely stable for me (MTBF for software crashes measured in centuries). I guess I am the anomaly.

  8. Curt Monash on April 22nd, 2009 3:16 am

    Mark,

    I stand by the mediocrity claim, based on a broad lack of features. As for performance, I have clients who reiterate the conventional wisdom based on their own experience. (E.g., the one I was at Friday, who don’t count something as performant unless it has a fast COUNT *). But I’ll confess to never having looked closely enough at your tests to judge what kinds of uses they do or don’t cover.

    Best,

    CAM

  9. Mark Callaghan on April 22nd, 2009 9:02 am

    Curt,

    Which of the missing features make it mediocre?

    It is nonsense to claim that InnoDB is slow and MyISAM is fast based on the speed of SELECT COUNT(*) FROM FOO. You need better clients. Which RDBMS vendors run that query fast without doing an index or table scan?

  10. Curt Monash on April 22nd, 2009 11:32 am

    Mark,

    Actually, this is almost the ideal client for me, based on their application. :)

    As for the rest, my cat is worse than mediocre at hunting vermin and insects, which is about the only feline duty I can think of to measure him by. But I love him dearly anyway, and wouldn’t trade him for any other. Mediocre != universally unsuitable.

  11. Michael on April 22nd, 2009 6:55 pm

    I can’t say that I love or revere MySQL because I don’t understand why I would love, hate or revere a piece of computer software but lack of features isn’t really mediocre, besides
    very often a ‘feature’ can be much more efficient,
    for a particular customer, done at application level. For a narrowly defined use case implementing bitmap indexes or in-memory database isn’t a big deal. otoh MySQL/InnoDB have some features that are hard to find, insert buffer and ENUM/SET datatypes come to mind.

    imho MySQL/InnoDB has three advantages over a leading closed source database brand:

    1. performance per $ invested is unsurpassed. Most often it’s very competitive even if you count TCO, not just open source.
    2. open source which means you can fix it yourself or with the help of a few good people.
    It also contributes to #3 below. People wouldn’t want to embarass themselves by releasing the product based on code which is either naturally lame or hastily written to meet a release deadline. When the source code is closed sloppy coding often flourish.
    3. high quality. It is actually high quality as far as silly bugs resulting in crashes are concerned.

  12. Shirish Jamthe on April 23rd, 2009 1:06 am

    Curt,

    I am another fan of your blog like Mark, but totally disagree with your analysis of InnoDB.
    I have worked for several years on Oracle (since 5.0) and on Ingres, Sybase as well as other object oriented databases like FAME & Vision but have never seen an implementation this clean.
    I love Oracle and InnoDB comes next in quality.

    InnoDb is one on the most well written database code that even after 14 years or writing is still well intact and easy to understand. The fact that the code has not been disfigured shows the quality of writing.

    There are lot more features that people would wish, and of course not all were added at the speed that a commercial database would add them for reasons that you can guess.

    MySQL of course has a long way to improve, but I can say with certainty that most of the success MySQL (in web world) has got has to do with InnoDB’s quality.

    It is way better than other storage engines that you mentioned. Actually if you ask MySQL folks they will tell you that PBXT http://www.primebase.org/ engine actually is better than the other you have listed here.

  13. Marcio Carneiro on April 23rd, 2009 11:19 am

    I sugest you a visit to http://modis.ispras.ru/sedna/.
    It is a XML native database.

  14. Quick links to Curt Monash's analyses of the Sun/Oracle deal on February 20th, 2013 11:49 am

    [...] MySQL Storage Engine round-up with Oracle-related thoughts [...]

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.