I would describe this as a hybrid engine as it provides an interface to an existing DBMS and is tightly integrated with the existing DBMS. By comparison, the Federated storage engine also provides an interface to an existing DBMS, but is not tightly integrated. The integration should greatly increase usability and performance. Performance can be further improved by adding support for condition pushdown for MySQL 5.1 and by implementing the batch key access interface when the engine is available in MySQL 6.
A few more comments:
- My favorite line from the wikipedia page is on the System i everything is an object. Profound.
- Where is the storage engine independent test suite that makes it easy to test new engine? The current suite is hardwired to use MyISAM and InnoDB for most tests.
- Where is the virtual machine image that will allow us to try out System i with MySQL and the new engine using our Mac/Win/Linux boxes?
Posts
I think the closest equivalent/port for this would be to use the DragonFlyBSD HAMMER filesystem - which is essentially a log-structured transactional storage system with replication and distributed storage (to come in the future).
ReplyDeleteThe last time I chatted with Matt Dillon, the creator of HAMMER, he was not opposed to the idea of exposing a few ioctls to allow his filesystem to be used as a database storage engine. It would be interesting as it would allow point-in-time views of the data: Want to see what the database looked like last week, sure.... The other side benefit is that every scrap of available RAM on the system can be used to cache pages without needing to be explicitly tuned as is currently required by InnoDB etc. No fear of your cache being accidentally paged out to slower disk. Being log-structured, it should have excellent write leveling behavior for flash-based storage.