Хранение данных на диске 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 операторов, которые можно выполнить в любом порядке.