Open source database vendor MySQL AB has released the newest version of its signature database management system, MySQL 5.0, with new pluggable storage engines -- swappable components that offer the ability to add or remove storage engines from a live MySQL server.
SearchOpenSource.com talked to site expert Mike Hillyer to find out how MySQL customers can benefit from the new pluggable storage engines.
Hillyer, the webmaster of VBMySQL.com, a popular site for people who run MySQL on top of Windows, currently holds a MySQL Professional Certification and is a MySQL expert at Experts-Exchange.com.
What exactly do pluggable storage engines bring to MySQL that wasn't available in previous versions?
Mike Hillyer: Pluggable storage engines bring the ability to add and remove storage engines to a running MySQL server. Prior to the introduction of the pluggable storage engine architecture, users were required to stop and reconfigure the server when adding and removing storage engines. Using third-party or in-house storage engines required additional effort.
If you were speaking to a database administrator (DBA) not familiar with MySQL, how would you describe the value of the new pluggable storage engines?
Hillyer: Many database management systems use a 'one-size-fits-all' approach for data storage -- all table data is handled the same way, regardless of what the data is or how it is accessed. MySQL took a different approach early on and implemented the concept of storage engines: different storage subsystems that are specialized to different use cases.
MyISAM tables are well suited to read heavy applications such as Web sites. InnoDB supports higher read/write concurrency. The new Archive storage engine is designed for logging and archival data. The NDB storage engine provides very high performance and availability.
One benefit of this design is that our users have been able to make migrating from a legacy system to a SQL DBMS easier by converting their legacy storage into a MySQL storage engine, allowing them to issue SQL queries against their legacy system without abandoning their old systems.
Pluggable seems to imply that they are used in certain instances, or not at all depending on the administrator's needs. Could you explain how some of the more important engines (of the nine) assist a MySQL DBA?
Hillyer: Here are a couple of examples:
The new Archive engine is great for storing log data because it uses gzip compression and shows great performance for inserts and reads with concurrency support. This means an administrator can save on storage and processing costs for logging and archival data.
The new Blackhole engine is unique in that it takes all INSERT, UPDATE and DELETE statements and drops them; it literally holds no data. That may seem odd at first, but it works well for allowing a replication master to handle writes without using any storage because the statements still get written to the binary log and passed on to the slaves.
Thanks to the new pluggable aspect, these storage engines can be loaded into the server when needed, and unloaded when not being used.
Are any of the nine modules something that has already been a part of database technology in the past? How does their inclusion in MySQL server make this app more robust?
Hillyer: Most of these storage engines have been in place for quite some time, namely MyISAM, InnoDB, BDB, MEMORY and MERGE. They are quite mature and used by most of our users. The NDB storage engine is new to MySQL, but it is an existing technology that has been in development for over 10 years.
The NDB storage engine is an example of a storage engine that has contributed to making MySQL more robust by enabling five nines of availability when properly implemented.
Are there any issues with MySQL that these pluggable storage engines do not address? How critical is it that additional modules are released in future versions?
Hillyer: There will always be needs that certain users have that the existing storage engines will not address, but the new pluggable approach means that it will be increasingly simple to write custom storage engines according to a defined API [application programming interface] and plug them in.
As these engines are written, it will be exciting to see the innovation that comes from the community, and I look forward to trying some of these community-provided storage engines.