Skip navigation links
The MySQL Cluster API Developer Guide :: 2 The NDB API :: 2.1 Getting Started with the NDB API :: 2.1.3 Mapping MySQL Database Object Names and Types to NDB
2.2 The NDB API Object Hierarachy »
Section Navigation      [Toggle]

2.1.3. Mapping MySQL Database Object Names and Types to NDB

Abstract

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 Table and 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 Table or Index object is always 'def' (for “default”).

Tables.  MySQL table names are directly mapped to NDB table names without modification. Table names starting with 'NDB$' are reserved for internal use>, as is the SYSTAB_0 table in the sys database.

Indexes.  There are two different type of NDB indexes:

  • Hash indexes are unique, but not ordered.

  • B-tree indexes are ordered, but allow 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 appending '$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 the NDB table.

Column Names and Values.  NDB column names are the same as their MySQL names.

Datatypes.  MySQL datatypes are stored in NDB columns as follows:

  • The MySQL TINYINT, SMALLINT, INT, and BIGINT datatypes map to NDB types having the same names and storage requirements as their MySQL counterparts.

  • The MySQL FLOAT and DOUBLE datatypes are mapped to NDB types having the same names and storage requirements.

  • 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.

  • In MySQL 5.1, the storage requirements for a VARCHAR or VARBINARY column depend on whether the column is stored in memory or on disk:

    • For in-memory columns, the NDBCLUSTER 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 the 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.)

    • In Disk Data columns, VARCHAR and VARBINARY are stored as fixed-width columns. This means that each of these types requires the same amount of storage as a CHAR of the same size.

  • Each row in a Cluster BLOB or 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 TEXT or BLOB column requires

    • 256 bytes, if size <= 256

    • 256 + 2000 * ((size – 256) \ 2000) + 1) bytes otherwise