This section discusses NDB naming and other conventions with regard to database objects.
Databases and Schemas.
Databases and schemas are not represented by objects as such in
the NDB API. Instead, they are modelled as attributes of
Index objects. The value of the
database attribute of one of these objects is
always the same as the name of the MySQL database to which the
table or index belongs. The value of the
schema attribute of a
Index object is always
def' (for “default”).
MySQL table names are directly mapped to
table names without modification. Table names starting with
NDB$' are reserved for internal use>, as
SYSTAB_0 table in the
Indexes. There are two different type of NDB indexes:
Hash indexes are unique, but not ordered.
B-tree indexes are ordered, but permit duplicate values.
Names of unique indexes and primary keys are handled as follows:
For a MySQL
UNIQUE index, both a B-tree and
a hash index are created. The B-tree index uses the MySQL name
for the index; the name for the hash index is generated by
$unique' to the index name.
For a MySQL primary key only a B-tree index is created. This
index is given the name
PRIMARY. There is
no extra hash; however, the uniqueness of the primary key is
guaranteed by making the MySQL key the internal primary key of
Column Names and Values.
NDB column names are the same as their MySQL
MySQL data types are stored in
NDB columns as
The storage space required for a MySQL
CHAR column is determined by
the maximum number of characters and the column's character
set. For most (but not all) character sets, each character
takes one byte of storage. When using UTF-8, each character
requires three bytes. You can find the number of bytes needed
per character in a given character set by checking the
Maxlen column in the output of
SHOW CHARACTER SET.
For in-memory columns, the
storage engine supports variable-width columns with 4-byte
alignment. This means that (for example) a the string
'abcde' stored in a
VARCHAR(50) column using
latin1 character set requires 12
bytes—in this case, 2 bytes times 5 characters is
10, rounded up to the next even multiple of 4 yields 12.
(This represents a change in behavior from Cluster in
MySQL 5.0 and 4.1, where a column having the same
definition required 52 bytes storage per row regardless of
the length of the string being stored in the row.)
Each row in a Cluster
TEXT column is made up of two
separate parts. One of these is of fixed size (256 bytes), and
is actually stored in the original table. The other consists
of any data in excess of 256 bytes, which stored in a hidden
table. The rows in this second table are always 2000 bytes
long. This means that record of
size bytes in a
BLOB column requires
256 bytes, if
256 + 2000 * (( bytes otherwise
– 256) \ 2000) + 1)