Хранение данных на диске NDB Cluster реализовано с помощью ряда объектов данных на диске. К ним относятся следующие:

Журналы отката и файлы данных являются фактическими файлами в файловой системе каждого узла данных; по умолчанию они размещаются в ndb_node_id_fs в DataDir, указанном в файле конфигурации NDB Cluster config.ini, где node_id — идентификатор узла данных. Можно разместить их в другом месте, указав абсолютный или относительный путь в имени файла при создании журнала отката или файла данных. Соответствующие инструкции показаны позже в этом разделе.

Пространства имен и группы файлов журналов NDB Cluster не реализованы как файлы.

Предполагая, что у вас уже настроен NDB Cluster со всеми узлами (включая управляющие и SQL-узлы), основные шаги по созданию таблицы NDB Cluster на диске следующие:

Все эти задачи можно выполнить с помощью SQL-команд в клиенте mysql или другом приложении-клиенте MySQL, как показано в примере ниже.

Индексирование столбцов, неявно хранящихся на диске. Для таблицы dt_1, определённой в только что показанном примере, на диске хранятся только столбцы dob и joined. Это связано с тем, что есть индексы по столбцам id, last_name и first_name, поэтому данные, относящиеся к этим столбцам, хранятся в оперативной памяти. Только неиндексированные столбцы могут храниться на диске; индексы и индексированные данные столбцов продолжают храниться в оперативной памяти. Этот компромисс между использованием индексов и сохранением оперативной памяти необходимо учитывать при проектировании таблиц Disk Data.

Нельзя добавить индекс к столбцу, явно объявленному как STORAGE DISK, не изменив сначала его тип хранения на MEMORY; любая попытка сделать это завершается ошибкой. Столбец, неявно использующий хранение на диске, может быть индексирован; при этом тип хранения столбца автоматически меняется на MEMORY. Под «“неявно”» понимается столбец, тип хранения которого не объявлен, но который унаследован от родительской таблицы. В следующем операторе CREATE TABLE (использующем ранее определённое табличное пространство ts_1), столбцы c2 и c3 неявно используют хранение на диске:

mysql> CREATE TABLE ti (
    ->     c1 INT PRIMARY KEY,
    ->     c2 INT,
    ->     c3 INT,
    ->     c4 INT
    -> )
    ->     STORAGE DISK
    ->     TABLESPACE ts_1
    ->     ENGINE NDBCLUSTER;
Query OK, 0 rows affected (1.31 sec)

Поскольку c2, c3 и c4 сами по себе не объявлены с помощью STORAGE DISK, их можно индексировать. Здесь мы добавляем индексы к c2 и c3, соответственно, используя CREATE INDEX и ALTER TABLE:

mysql> CREATE INDEX i1 ON ti(c2);
Query OK, 0 rows affected (2.72 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE ti ADD INDEX i2(c3);
Query OK, 0 rows affected (0.92 sec)
Records: 0  Duplicates: 0  Warnings: 0

SHOW CREATE TABLE подтверждает, что индексы были добавлены.

mysql> SHOW CREATE TABLE ti\G
*************************** 1. row ***************************
       Table: ti
Create Table: CREATE TABLE `ti` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  `c4` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`),
  KEY `i1` (`c2`),
  KEY `i2` (`c3`)
) /*!50100 TABLESPACE `ts_1` STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Можно увидеть с помощью ndb_desc, что индексированные столбцы (выделенный текст) теперь используют хранение в памяти, а не на диске:

$> ./ndb_desc -d test t1
-- t1 --
Version: 33554433
Fragment type: HashMapPartition
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 4
Number of primary keys: 1
Length of frm data: 317
Max Rows: 0
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
PartitionCount: 4
FragmentCount: 4
PartitionBalance: FOR_RP_BY_LDM
ExtraRowGciBits: 0
ExtraRowAuthorBits: 0
TableStatus: Retrieved
Table options:
HashMap: DEFAULT-HASHMAP-3840-4
-- Attributes --
c1 Int PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY
c2 Int NULL AT=FIXED ST=MEMORY
c3 Int NULL AT=FIXED ST=MEMORY
c4 Int NULL AT=FIXED ST=DISK
-- Indexes --
PRIMARY KEY(c1) - UniqueHashIndex
i2(c3) - OrderedIndex
PRIMARY(c1) - OrderedIndex
i1(c2) - OrderedIndex

NDBT_ProgramExit: 0 - OK

Примечание по производительности. Производительность кластера, использующего хранение данных на диске, значительно улучшается, если файлы данных на диске хранятся на отдельном физическом диске от файловой системы узла данных. Это необходимо сделать для каждого узла данных в кластере, чтобы получить заметное улучшение.

Вы можете использовать абсолютные и относительные пути к файловой системе с помощью ADD UNDOFILE и ADD DATAFILE. Относительные пути рассчитываются относительно каталога данных узла данных. Вы также можете использовать символические ссылки; см. Раздел 21.6.11.2, «Использование символических ссылок с объектами данных на диске» для получения дополнительной информации и примеров.

Группа файлов журнала, пространство таблиц и любые таблицы данных на диске, использующие их, должны быть созданы в определенном порядке. То же самое относится к удалению любого из этих объектов:

Например, чтобы удалить все созданные до сих пор объекты в этом разделе, используйте следующие инструкции:

mysql> DROP TABLE dt_1;

mysql> ALTER TABLESPACE ts_1
    -> DROP DATAFILE 'data_2.dat'
    -> ENGINE NDBCLUSTER;

mysql> ALTER TABLESPACE ts_1
    -> DROP DATAFILE 'data_1.dat'
    -> ENGINE NDBCLUSTER;

mysql> DROP TABLESPACE ts_1
    -> ENGINE NDBCLUSTER;

mysql> DROP LOGFILE GROUP lg_1
    -> ENGINE NDBCLUSTER;

Эти инструкции должны быть выполнены в указанном порядке, за исключением того, что две ALTER TABLESPACE ... DROP DATAFILE инструкции могут быть выполнены в любом порядке.

Вы можете получить информацию о файлах данных, используемых таблицами данных на диске, запросив таблицу FILES в базе данных INFORMATION_SCHEMA. Дополнительная “NULL строка” предоставляет дополнительную информацию о файлах журнала отката. Для получения дополнительной информации и примеров см. Раздел 24.3.9, «Таблица INFORMATION_SCHEMA FILES».