By Henrik Ingo on Sep 01, 2008
One way to look at a database is that
- there is data, and
- there are ways to access data.
This dichotomy was actually coined (whether intentional or not) by Vinay in the MySQL telecom team when discussing the MySQL Cluster vision some months ago.
Even if you typically think of MySQL Cluster as just a clustered version of the plain old MySQL server, it is actually more like the opposite is true, if you consider the architecture and history of MySQL Cluster. The original cluster was just the data store called Network DataBase or NDB as we familiarly know it still. Then MySQL Server was integrated on top of that to provide an SQL interface. The original and "native" NDB interface is still there though, and many prefer to use direct C++ or Java access to their NDB-clustered data. It is faster just in general, but especially applications with a real-time requirement will benefit from omitting the MySQL Server. No additional network hop and no parsing of SQL, just direct access to your data. Sometimes also you might benefit from being able to do things with the NDB API that cannot be efficiently expressed in SQL at all.
But did you know that in addition to the SQL and NDB API there are actually multiple more ways to interface with MySQL Cluster available:
- LDAP was presented at a MySQL User Conference BOF last spring and is actually available now as an Option in the Carrier Grade Edition. The LDAP interface is actually an OpenLDAP server node, using a native NDB backend in the slapd.
- mod_ndb is a REST Web Services API for MySQL Cluster. This one is (obviously) implemented as an Apache module. Although produced by our own John 'JD' Duncan, it is not a Sun supported product.
- We also know of a case where MySQL Cluster is accessed through the RADIUS protocol, although I don't think this implementation is publicly available.
- And someone also does it with DIAMETER, a successor to RADIUS.
I don't know details on the 2 last ones, but at least the 2 first ones use NDB directly. That is much more efficient and convenient than for instance doing some LDAP->SQL conversions when SQL really isn't needed in the first place. Moreover, you did realize that all these interfaces are equal citizens with the mysqld - they are all just api nodes. Meaning, you could have one big cluster and access that same data with SQL, LDAP, HTTP, RADIUS and DIAMETER, and of course directly from your application code with the NDB C++ or Java API. Which brings us back to the title for this blog post: You have data and you have ways to access the data. Whatever ways suits you the best.
Then of course for the interesting question? Are there more protocols/API's out there for MySQL Cluster that we don't know about? (Or that I ommitted by mistake?) Are there some protocols there that would be interesting to implement? Let us know at hingo at mysql dot com (or comment below)!