Subscribe to RSS Subscribe to Comments

My So-Called Blog

API vs SQL, DB vs Data

I did a bunch of housekeeping in the MySQL Cluster documentation today.

Confession: I’m the bright light who came up with the term “SQL node” because I didn’t like “API node”. At the time, it seemed like a good idea, but as time has gone on, I’ve come to see the error of my ways. However, lots of people now use the term, so I guess it’s not a good idea to change it out from under them. So here’s what I’ve decided:

API node - Any application that accesses Cluster data. Basically this means any NDB API application.

SQL node - A subspecies of API node that provides an SQL interface to a Cluster. Basically, this means a MySQL Server that’s part of a Cluster. (mysqld itself isn’t an NDB API application, but the bits that let it talk to a Cluster use the NDB API.)

Also, ndbd processes were in the distant past referred referred to as “database nodes” or even “DB nodes”. Nobody at work liked these very much (AFAIK), as we were afraid that newcomers to MySQL and Cluster would find them confusing. I wanted to call them “storage nodes” while others preferred “data nodes”.

This was an argument that I lost - after I’d started using “storage nodes” in the Manual. Ooops.

So I’ve changed “storage nodes” to “data nodes” throughout the Cluster documentation. Since some people picked up on my term before it got axed, I’ve left a note in there explaining that it’s a deprecated term. For the record, however, the official term is now “data nodes”, okay? Okay.

There are also a few places in the software where “DB node” and “storage node” still appear, such as in the output of SHOW in the Cluster management client and some NDB-specific MySQL system variables. But these vestiges of Old NDB-lish should be Going Away soon, probably in 5.0.25 and 5.1.12, and maybe in the next 4.1 release as well.

No comments yet. Be the first.

Leave a reply

MySQL 5.0.45-communityPHP 5.2.3