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

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

Файлы журнала отката используются только таблицами данных на диске и не нужны или не используются таблицами NDB, которые хранятся только в памяти.

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

Хотя не все объекты данных на диске реализованы как файлы, все они используют одно и то же пространство имен. Это означает, что каждый объект данных на диске должен иметь уникальное имя (а не только каждый объект данных данного типа). Например, вы не можете иметь пространство имен и группу файлов журнала, оба с именем dd1.

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

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

Информацию о только что созданных файлах данных на диске и файлах журнала отката можно получить, запросив таблицу FILES в базе данных INFORMATION_SCHEMA, как показано здесь:

mysql> SELECT
              FILE_NAME AS File, FILE_TYPE AS Type,
              TABLESPACE_NAME AS Tablespace, TABLE_NAME AS Name,
              LOGFILE_GROUP_NAME AS 'File group',
              FREE_EXTENTS AS Free, TOTAL_EXTENTS AS Total
          FROM INFORMATION_SCHEMA.FILES
          WHERE ENGINE='ndbcluster';
+--------------+----------+------------+------+------------+------+---------+
| File         | Type     | Tablespace | Name | File group | Free | Total   |
+--------------+----------+------------+------+------------+------+---------+
| ./undo_1.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 4194304 |
| ./undo_2.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 3145728 |
| ./data_1.dat | DATAFILE | ts_1       | NULL | lg_1       |   32 |      32 |
| ./data_2.dat | DATAFILE | ts_1       | NULL | lg_1       |   48 |      48 |
+--------------+----------+------------+------+------------+------+---------+
4 rows in set (0.00 sec)

Более подробную информацию и примеры см. в разделе 28.3.15, «Таблица INFORMATION_SCHEMA FILES».

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

Нельзя добавить индекс к столбцу, который был явно объявлен 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=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
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

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

Можно использовать абсолютные и относительные пути файловой системы с ADD UNDOFILE и ADD DATAFILE; относительные пути рассчитываются относительно каталога данных узла данных.

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

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

mysql> DROP TABLE dt_1;

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

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

mysql> DROP TABLESPACE ts_1;

mysql> DROP LOGFILE GROUP lg_1;

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