MySQL 5.4 gets bigger anyway, encroaching on new parent Oracle's turf
When Oracle CEO Larry Ellison announced his acquisition of Sun Microsystems yesterday morning, he didn't mention MySQL at all -- his company's principal competitor in the small systems database space. Maybe that was just for spite: It's no secret that Ellison wanted MySQL; he said so explicitly three years ago. It was one of the key missing elements in the top-to-bottom stack he's been looking for, a way to create a line-up of pre-configured systems with everything customers need right out of the proverbial "box."
But MySQL's place in Ellison's stack doesn't extend to the enterprise, where the Oracle DB still rules -- at least in his mind. Eleven million installed MySQL customers plus a resurgent Microsoft SQL Server aside, Oracle DB is, from Oracle's perspective, an unstoppable juggernaut.
While participants in this week's MySQL Conference and Expo in Santa Clara were debating the meaning of changing the flags over the front entrance once again (it was acquired by Sun only last year), the community for the world's principal open source database maintained the course it had set last week. Today, the group heralded the official release of MySQL 5.4, whose principal improvement is bigger and better support for the InnoDB transactional storage engine. That engine will help MySQL enter more enterprises by removing version 5.1's limitation of four cores per instance, moving all the way to 16-processor ("16-way") support for x86 servers with multiple cores per processor, and 64-way support for Sun's SPARC-based CMT servers.
If you remember the days when "Toyota Truck" was an oxymoron in the heavy load division, you know how it feels when barriers are shattered. This puts MySQL into the heavy load category, which isn't exactly inside the boundaries of Larry Ellison's nice little stack.
But Ellison is rarely without an ace up his sleeve, or at least an ace somewhere handy; and in this case, he made sure he had one back in October 2005. That's when Oracle purchased Innobase OY, the makers of the InnoDB database engine. See, MySQL is officially a database management system, which means it's quite capable of managing data stored by other open source engines. While MyISAM is the one designed for MySQL and intended to work with it by default, Innobase developed InnoDB not just for MySQL, but as an open source engine for transactional data. It's through the expansion of MySQL's support for InnoDB that version 5.4's embrace of 16-way servers has come about.
Understanding how this particular innovation got started requires us to review a little bit about the ISAM methodology -- specifically, why it's been such a lucky charm for MySQL, up until the point where it needs to expand into the enterprise. For more on that, I'll cite...well, myself, from a textbook I wrote in 1998:
ISAM [Indexed Sequential Access Method] is not another trademark, nor does it represent some proprietary technology invented just for the sake of the cute acronym. Instead, it refers to a technique for locating an entry in a database table. In short, an ISAM driver or server uses a separate table called the index to look up a key number for a record. A key number is a unique entry used to identify that record, such as a serial number or purchase order number. Having found that, the index then points the server in the direction of the true record in the database, thus saving some search time.
ISAM relies on a couple of conditions being met before it can work properly:
- No two records in a table may be identical to one another. If you think about it, no properly conceived database table would have any need for identical records. Even if your table were a catalog of baseball cards and a given collection contained two identical cards, both cards should be given unique identifiers, making their respective records unique.
- At least one column of the database table must contain fields whose contents are unique for each record. Generally, a serial number qualifies as such a column. This column serves to contain the key field that uniquely identifies each record.
For ISAM, at least one separate table is generated for each field column. This table is the index for the database table. It contains two and only two columns: a duplicate of the key field column, and a separate column recording the location of the record in the table whose key field matches the duplicate in the index. The theory here is that because the index table is smaller, it's quicker to search through it than through the main table. But generally, ISAM drivers "cheat" and sort the index column, then employ a binary search instead of a sequential search...which is far faster. So why isn't it called "IBAM" rather than ISAM? Sometimes it's just too difficult to ditch a cute acronym.
Next: MySQL's road around ISAM leads to Oracle, but not the way it planned...