SolidDB and MySQL 5.0 – how industrial-strength in OLTP?
MySQL 4.0 is an OLTP joke. MySQL 5.0, however, shows a lot of progress in terms of real transactions, foreign keys, referential integrity, triggers, stored procedures and so on. In anticipation of the MySQL user conference next week, I got a quick briefing from Paola Lubet and Murat Demiroglu at Solid Information Technology, whose SolidDB is one of the two transactional storage engines for MySQL (the other is InnoDB, now owned by Oracle).
The layer provided by MySQL actually does most of what I think of as “language processing” – parsing, optimization, drivers, triggers, stored procedures, referential integrity, etc. SolidDB is a storage engine providing actual execution. Its features and virtues include:
• Online backup. (Note: Apparently, the extra-cost InnoDB online backup product isn’t showing up on price lists these days.)
• Optimistic (as well as pessimistic) concurrency control. This can be a good performance feature for applications that have a whole lot of Adds and very few Changes.
• General reliability. Unless they really botched the port, Solid benefits from a long history of very reliable operation.
• High availability. Scheduled for alpha in early summer and beta in the fall is a high-availability option. This initial-release will be master-slave synchronous replication. More sophisticated replication could come later on, as could memory-centric performance, if market conditions seem to warrant it (I’m betting they will).
Solid would also add “multiprocessor support” to the list, but I don’t see why SolidDB would be ahead of serious alternatives in that respect.
Overall, I don’t think SolidDB will do much to hold MySQL 5.0 back in industrial-strengthness. Solid’s classic products are – well, they’re solid, and I don’t know why the port would have gone badly. They’re not super-scalable historically, or at least haven’t had to be, but they’re also very far from being toys. One problem, however – Solid’s product isn’t extensible with respect to datatype support. (Solid claims very fast BLOB performance, but that’s not the same thing at all. Alternate datatype support requires flexible indexing schemes.)
On the other hand, SolidDB also doesn’t help that much, simply because many industrial-strengthness issues are on the side of the joint product that’s MySQL code. I’m guessing MySQL got transactions and referential integrity basically right in 5.0, but I haven’t confirmed this. Nor do I know how stored procedure performance is, or row-level security.
As for actual production customers – Solid says the first customers are going production around now. Some of them apparently have databases in the 100s of gigabytes size range, which is non-trivial. Indeed, 15 years ago, or maybe even a little less, a few hundred gigabytes was the size of the very largest OLTP relational databases in the world.
All in all, the MySQL/SolidDB combo seems like a reasonable option in the midrange OLTP DBMS market.
Want to continue getting great research about DBMS, analytics, and other technologies related to data management? Then subscribe to our feed, by RSS/Atom or e-mail! We recommend taking the integrated feed for all our blogs, but blog-specific ones are also easily available.
Technorati Tags: MySQL, SolidDB
Comments
2 Responses to “SolidDB and MySQL 5.0 – how industrial-strength in OLTP?”
Leave a Reply
“Some of them apparently have databases in the 100s of gigabytes size range, which is non-trivial”.
100s of GB? … man, those sizes are ridiculous small for a real and serious OLTP database. Oh wait, you were talking about MySQL, ok then :).
It feels like yesterday that I was unearthing the biggest golly-gee-whiz UNIX RDBMS databases, and they had just gotten up to the 100s of gigabytes range.
In reality (if memory serves), it was 1993 or so, give or take a couple of years — but it FEELS like yesterday. 😉
CAM