{"id":3304,"date":"2013-05-13T15:34:39","date_gmt":"2013-05-13T05:34:39","guid":{"rendered":"http:\/\/www.flamingspork.com\/blog\/?p=3304"},"modified":"2013-05-13T15:40:31","modified_gmt":"2013-05-13T05:40:31","slug":"the-mysql-cluster-storage-engine","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2013\/05\/13\/the-mysql-cluster-storage-engine\/","title":{"rendered":"The MySQL Cluster storage engine"},"content":{"rendered":"

This is one close to my heart. I’ve recently written on other storage engines:\u00c2\u00a0Where are they now: MySQL Storage Engines<\/a>,\u00c2\u00a0The MERGE storage engine: not dead, just resting\u00e2\u20ac\u00a6. or forgotten<\/a>\u00c2\u00a0and The MEMORY storage engine<\/a>. Today, it’s the turn of MySQL Cluster.<\/p>\n

Like InnoDB, MySQL Cluster started outside of MySQL. Those of you paying attention at home may notice a correlation between storage engines not written exclusively for MySQL and being at all successful.<\/p>\n

NDB (for Network DataBase) started inside Ericsson, originally written in a language called PLEX<\/a>, which was internal to Ericsson and used in the AXE telephone switches. Mikael Ronstrom’s PHD thesis covered NDB and even covered things that (at least were) yet to be implemented (it’s been quite a few years since I leafed through it last). The project at Ericsson (IIRC) was shelved a couple of times, but eventually got spun out into an Ericsson Business Innovation company called Alzato<\/a>.<\/p>\n

Some remnants of PLEX can still be found in the NDB source code (if you look really hard that is). At some point the code was fed through a PLEX to C++ converter and development continued from there. Some of the really, really old parts of the source may seem weird either due to this or some hand optimization for SPARC processors in the 1990s.<\/p>\n

In 2003, MySQL AB acquired Alzato and work on a storage engine plugin for MySQL to interface to the (C++ API only) NDB was underway. Seeing as the storage engine interface was so simple, easy and modular it would only take several years for the interface to NDB to become mature.<\/p>\n

The biggest problem: NDB itself worked really well if your workload fit exactly what it was good at… if you deviated, horrific performance and\/or crashes were not as uncommon as we’d have liked. This was a source of strain for many years with the developers and support team on one side and some of the less-than-careful sales team on the other. That being said, there have been some absolutely awesome sales people selling NDB into markets it truly fits, and this is why there’s barely a place in the world where placing a mobile phone call doesn’t go through MySQL Cluster at some point.<\/p>\n

You should read Tomas Ulin’s post\u00c2\u00a0Celebrating 10 years @MySQL<\/a>\u00c2\u00a0for a bit of an insight into how Alzato became part of MySQL AB (which later became part of Sun which became part of Oracle).<\/p>\n

I joined the MySQL Cluster team at MySQL in December 2004, not too long after Alzato was acquired, but certainly when the NDB storage engine in MySQL 4.1 was in its very early stages – it was then by no means a general purpose database.<\/p>\n

Over the years, MySQL Cluster gained both traction and features, making it useful for more applications. One of the biggest marketing successes of MySQL was the storage engine architecture and how you could just “plug in” different engines. The reality (of course) was far different and even though MySQL Cluster did just “plug in” to MySQL, it was certainly not a drop in replacement.<\/p>\n

In MySQL 5.0, a bunch of neat new features were added:<\/p>\n