April 20, 2009
MySQL storage engine round-up, with Oracle-related thoughts
Here’s what I know about MySQL storage engines, more or less.
- MySQL with MyISAM is fast. But it’s not transactional. Except for limited purposes, MySQL with MyISAM is a pretty crummy DBMS. Nothing can change that.
- MySQL with InnoDB is transactional. But it’s not particularly fast. MySQL with InnoDB is a pretty mediocre DBMS. Oracle could fix that, at least partially, over time.
- I don’t know much about Falcon, Maria, and so on. With Oracle winding up owning both MySQL and InnoDB, the motivation for those engines (except as Oracle-free forks) might fade.
- Infobright is the most established of the rest. At the moment I’m not recommending it for most industrial-strength uses unless the user is particularly cash-constrained. But I wouldn’t be surprised if that changed soon. A cheap, fast, simple columnar analytic DBMS has a place in the world.
- Kickfire is next in line, offering a hardware-based growth path for users who’ve maxed out on what unaided MySQL can do. It remains to be seen for how many users the desire to keep things simple and stay with MySQL outweighs the desire to avoid custom hardware. Having Oracle salespeople all over those accounts surely wouldn’t help. Kickfire also has a second market, namely OEM vendors who are mainly interested in the superfast chip. That would probably be pretty unaffected by Oracle.
- Tokutek offers a technical proposition that’s hard to match head-on without going the CEP route. Users who care are likely to be MySQL shops. Tokutek’s main challenge is to prove that it sufficiently outdoes competing technical strategies for sufficiently many users. Oracle ownership of MySQL seems pretty irrelevant to Tokutek’s success or failure.
- Calpont offers a kind of lightweight Exadata alternative. With Calpont’s packaging and positioning perennially unclear, it’s difficult to predict the effect of a particular change — i.e., Oracle buying MySQL — in Calpont’s market environment.
- I haven’t heard from transactionally-oriented ScaleDB since I wrote about them a year ago. Apparently, they’re rolling out beta product this week, and their venerable techie guru sadly passed away earlier this month.
Categories: Calpont, Columnar database management, Data warehousing, Exadata, Infobright, Kickfire, MySQL, Open source, Oracle, Tokutek and TokuDB
Subscribe to our complete feed!
Comments
14 Responses to “MySQL storage engine round-up, with Oracle-related thoughts”
Leave a Reply
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.
Oracle will slowly very slowly add new features to MySQL, whenever it is necessary to fend off a low end competitor.
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.
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.
Mike,
One job posting you had described ScaleDB as “newly funded”. What does that mean? 🙂
Best,
CAM
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”).
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.
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
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?
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.
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.
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.
I sugest you a visit to http://modis.ispras.ru/sedna/.
It is a XML native database.
[…] MySQL Storage Engine round-up with Oracle-related thoughts […]