When I interviewed at Tokutek, I met a team of distinguished academics and engineers who could calmly and thoughtfully wax eloquent about the finer points of B-tree and Fractal Tree™ indexing, drive I/Os, and database engines. Soon after, I discovered that several of my colleagues have a second passion — they practice Mixed Martial Arts (MMA). As Wikipedia explains, MMA showcases the “fighters of different disciplines, including boxing, Brazilian Jiu-Jitsu, wrestling, Muay Thai, karate and others.” I’ve since learned about many different fighting styles.
This was useful to understand when an MMA-style fight broke out in the MySQL world earlier this month between the different variants or “styles” of SQL — OldSQL, NewSQL and NoSQL. If you haven’t heard about this (hard to believe), it all started with a GigaOM article. There have been many many posts since with my favorite perhaps being the ones about the mud wrestling priest and Lady Gaga.
As a NewSQL vendor, we keep getting asked for our view on this hullabaloo. First of all, it’s hard to knock MySQL — it is ubiquitous, it is easy to use and get started with, it leverages well-known SQL interfaces, it offers index flexibility, it has good community support, and delivers a high degree of adaptability, just to name a few points. It is perfect for many applications and hence so tremendously popular.
MySQL does, of course, have its limitations, particularly in the face of larger databases, where performance can dip and maintenance becomes challenging. That leads to customers who try to either extend and tune its performance, employ a lot of workarounds, and/or look to explore a next step or alternative. Sometimes, rightly so, that next step is NoSQL. An example use case is when one has to touch a large amount of data, and where the occasional queries are completely ad-hoc and likely not to be repeated (i.e., massive amounts of research data). Of course, there are inevitable trade-offs with NoSQL – lack of ACID, lack of training and familiar SQL interfaces, lack of indexes etc…just to name a few. In this particular Stonebraker-Facebook disagreement, Facebook questioned how realistic it would be to go give up MySQL to go to all RAM when disks are so much cheaper. I doubt Facebook raised over $1B in cash, just so they could go all in-memory.
On the other hand, as Curt Monash noted, when one needs to extend the performance of relational databases, there are many alternatives for scaling or extending MySQL (Tokutek being one of them). TokuDB brings a number of capabilities — high insertion rates, ability to improve queries with rich indexing, on the fly schema modifications, efficient use of disk I/O and more — to the table (pun intended). As opposed to giving up SQL or ACID functionality (or paying for it at the application level) to get additional horsepower, an innovative architecture such as Fractal Tree™ indexes can be employed to significantly improve performance. Having the flexibility of MySQL plus the power of a new storage engine means that one has a single versatile solution. To borrow a phrase from NimbusDB, “in reality, one size fits most” needs, especially when the general solution gets such a performance boost. That’s good news for customers who simply want a more potent general purpose database without having to adopt a whole new “style.” Tokutek gives you that with a MySQL storage engine that leaves all your application logic and MySQL code completely unchanged. Tokutek is, in fact, less like a new “style” and more like a whole next belt level or set of powerful new “moves” for an existing and proven style.
So what MySQL variant or “style” is right for your organization? In some cases a radical approach may be warranted. Your data center is your ring (or cage) – you know the challenges better than anyone. But we have found that in many cases, a few new “moves” may do the trick and save you the time, money, and the challenges of new training. And with a few new moves you may find your database problems are suddenly a lot easier to take down.