content_image/812270.jpg
bytes each per record. There is a primary key hash index on the base table using roughly 29 bytes per record. The unique constraint is implemented by a separate table with b  as primary key and a  as a column. This other table consumes an additional 29 bytes of index memory per record in the example  table as well 8 bytes of record data plus 12 bytes of overhead. 

Thus, for one million records, we need 58MB for index memory to handle the hash indexes for the primary key and the unique constraint. We also need 64MB for the records of the base table and the unique index table, plus the two ordered index tables. 

You can see that hash indexes takes up a fair amount of memory space; however, they provide very fast access to the data in return. They are also used in NDB Cluster to handle uniqueness constraints. 

Currently, the only partitioning algorithm is hashing and ordered indexes are local to each node. Thus, ordered indexes cannot be used to handle uniqueness constraints in the general case. 

An important point for both IndexMemory  and DataMemory  is that the total database size is the sum of all data memory and all index memory for each node group. Each node group is used to store replicated information, so if there are four nodes with two fragment replicas, there are two node groups. Thus, the total data memory available is 2 × DataMemory  for each data node. 

It is highly recommended that DataMemory  and IndexMemory  be set to the same values for all nodes. Data distribution is even over all nodes in the cluster, so the maximum amount of space available for any node can be no greater than that of the smallest node in the cluster. 

DataMemory  can be changed, but decreasing it can be risky; doing so can easily lead to a node or even an entire NDB Cluster that is unable to restart due to there being insufficient memory space. Increasing these values should be acceptable, but it is recommended that such upgrades are performed in the same manner as a software upgrade, beginning with an update of the configuration file, and then restarting the management server followed by restarting each data node in turn. 

MinFreePct. A proportion (5% by default) of data node resources including DataMemory  is kept in reserve to insure that the data node does not exhaust its memory when performing a restart. This can be adjusted using the MinFreePct  data node configuration parameter (default 5). 

<img src='content_image/812270.jpg'>

Updates do not increase the amount of index memory used. Inserts take effect immediately; however, rows are not actually deleted until the transaction is committed. 

Transaction parameters.  The next few [ndbd]  parameters that we discuss are important because they affect the number of parallel transactions and the sizes of transactions that can be handled by the system. MaxNoOfConcurrentTransactions  sets the number of parallel transactions possible in a node. MaxNoOfConcurrentOperations  sets the number of records that can be in update phase or locked simultaneously. 

Both of these parameters (especially MaxNoOfConcurrentOperations ) are likely targets for users setting specific values and not using the default value. The default value is set for systems using small transactions, to ensure that these do not use excessive memory. 

