- 2.1 Getting Started with the NDB API
- 2.1.1 Compiling and Linking NDB API Programs
- 2.1.2 Connecting to the Cluster
- 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 permit duplicate values.
Names of unique indexes and primary keys are handled as follows:
For a MySQL
UNIQUEindex, 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 theNDBtable.
Column Names and Values.
NDB column names are the same as their MySQL
names.
Data Types.
MySQL data types are stored in NDB columns as
follows:
The MySQL
TINYINT,SMALLINT,INT, andBIGINTdata types map toNDBtypes having the same names and storage requirements as their MySQL counterparts.The MySQL
FLOATandDOUBLEdata types are mapped toNDBtypes having the same names and storage requirements.The storage space required for a MySQL
CHARcolumn 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 theMaxlencolumn in the output ofSHOW CHARACTER SET.-
In MySQL 5.1 and later, the storage requirements for a
VARCHARorVARBINARYcolumn depend on whether the column is stored in memory or on disk:For in-memory columns, the
NDBCLUSTERstorage engine supports variable-width columns with 4-byte alignment. This means that (for example) a the string'abcde'stored in aVARCHAR(50)column using thelatin1character 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,
VARCHARandVARBINARYare stored as fixed-width columns. This means that each of these types requires the same amount of storage as aCHARof the same size.
-
Each row in a Cluster
BLOBorTEXTcolumn 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 ofsizebytes in aTEXTorBLOBcolumn requires256 bytes, if
size<= 256256 + 2000 * ((bytes otherwisesize– 256) \ 2000) + 1)
