Возвращает текущий идентификатор соединения.

mysql> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 6               |
+-----------------+
1 row in set (0.00 sec)

Возвращает расстояние KNN векторного поиска.

mysql> select id, knn_dist() from test where knn ( image_vector, 5, (0.286569,-0.031816,0.066684,0.032926) ) and match('white') and id < 10;
+------+------------+
| id   | knn_dist() |
+------+------------+
|    2 | 0.81527930 |
+------+------------+
1 row in set (0.00 sec)

Возвращает идентификаторы документов, которые были вставлены или заменены последним оператором в текущей сессии.

То же значение можно получить через переменную @@session.last_insert_id.

mysql> select @@session.last_insert_id;
+--------------------------+
| @@session.last_insert_id |
+--------------------------+
| 11,32                    |
+--------------------------+
1 rows in set
mysql> select LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 25,26,29         |
+------------------+
1 rows in set

Возвращает "короткий" универсальный идентификатор в виде 63-битного беззнакового целого числа, используя тот же алгоритм, что и для автоматической генерации ID.

ПРИМЕЧАНИЕ: Использование uuid_short() увеличит счетчик, используемый для авто-ID, поэтому используйте его с осторожностью. Хотя вы можете запускать uuid_short() в запросах типа SELECT uuid_short() FROM ..., такой подход не идеален, так как может создавать большие пропуски в ваших автоматически сгенерированных ID.

mysql> select uuid_short();
+---------------------+
| uuid_short()        |
+---------------------+
| 5839598169280741377 |
+---------------------+
1 row in set (0.00 sec)
mysql> select uuid_short();
+---------------------+
| uuid_short()        |
+---------------------+
| 5839598169280741378 |
+---------------------+
1 row in set (0.00 sec)

Регулярное резервное копирование ваших таблиц необходимо для восстановления в случае сбоев системы, отказа оборудования или повреждения/потери данных. Также настоятельно рекомендуется создавать резервные копии перед обновлением до новой версии Manticore Search или выполнением ALTER TABLE.

Резервное копирование систем баз данных может выполняться двумя уникальными способами: логическим и физическим. Каждый из этих методов имеет свои плюсы и минусы, которые могут варьироваться в зависимости от конкретной среды базы данных и потребностей. Здесь мы рассмотрим различия между этими двумя типами резервных копий.

Логические резервные копии предполагают экспорт схемы базы данных и данных в виде SQL-запросов или в форматах данных, специфичных для базы данных. Эта форма резервного копирования обычно читаема человеком и может использоваться для восстановления базы данных на различных системах или движках баз данных.

Плюсы и минусы логических резервных копий:

• ➕ Портативность: Логические резервные копии, как правило, более портативны, чем физические, так как их можно использовать для восстановления базы данных на разном оборудовании или операционных системах.
• ➕ Гибкость: Логические резервные копии позволяют выборочно восстанавливать конкретные таблицы, индексы или другие объекты базы данных.
• ➕ Совместимость: Логические резервные копии можно использовать для миграции данных между разными системами управления базами данных или версиями, при условии, что целевая система поддерживает экспортируемый формат или SQL-запросы.
• ➖ Медленнее создание и восстановление: Логические резервные копии могут выполняться медленнее, чем физические, так как движок базы данных должен преобразовать данные в SQL-запросы или другой формат экспорта.
• ➖ Повышенная нагрузка на систему: Создание логических резервных копий может вызывать большую нагрузку на систему, так как процесс требует больше ресурсов CPU и памяти для обработки и экспорта данных.

Manticore Search поддерживает mysqldump для логических резервных копий.

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

Плюсы и минусы физических резервных копий:

• ➕ Скорость: Физические резервные копии обычно выполняются быстрее логических, так как включают прямое копирование необработанных файлов данных с диска.
• ➕ Согласованность: Физические резервные копии обеспечивают согласованное резервное копирование всей базы данных, так как все связанные файлы копируются вместе.
• ➕ Меньшая нагрузка на систему: Создание физических резервных копий обычно создает меньшую нагрузку на систему по сравнению с логическими, так как процесс не требует дополнительной обработки данных.
• ➖ Портативность: Физические резервные копии, как правило, менее портативны, чем логические, так как могут зависеть от конкретного оборудования, операционной системы или конфигурации движка базы данных.
• ➖ Гибкость: Физические резервные копии не позволяют выборочно восстанавливать отдельные объекты базы данных, так как резервная копия содержит необработанные файлы всей базы данных.
• ➖ Совместимость: Физические резервные копии нельзя использовать для миграции данных между разными системами управления базами данных или версиями, так как необработанные файлы данных могут быть несовместимы между разными платформами или программным обеспечением.

Manticore Search имеет командный инструмент manticore-backup для физических резервных копий.

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

Инструмент manticore-backup, включенный в официальные пакеты Manticore Search, автоматизирует процесс резервного копирования таблиц для экземпляра, работающего в RT режиме.

Если вы следовали официальным инструкциям по установке, у вас уже должно быть все установлено, и вам не о чем беспокоиться. В противном случае, manticore-backup требует PHP 8.1.10 и специфические модули или manticore-executor, который является частью пакета manticore-extra, и вам нужно убедиться, что один из них доступен.

Обратите внимание, что manticore-backup пока недоступен для Windows.

Во-первых, убедитесь, что вы запускаете manticore-backup на том же сервере, где работает экземпляр Manticore, который вы собираетесь резервировать.

Во-вторых, рекомендуется запускать инструмент под пользователем root, чтобы инструмент мог передавать права собственности на файлы, которые вы резервируете. В противном случае резервная копия также будет создана, но без передачи прав собственности. В любом случае, убедитесь, что manticore-backup имеет доступ к каталогу данных экземпляра Manticore.

manticore-backup --config=path/to/manticore.conf --backup-dir=backupdir

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: all tables
Target dir: /mnt/backup/
Manticore config
  endpoint =  127.0.0.1:9308
Manticore versions:
  manticore: 5.0.2
  columnar: 1.15.4
  secondary: 1.15.4
2022-10-04 17:18:39 [Info] Starting the backup...
2022-10-04 17:18:39 [Info] Backing up config files...
2022-10-04 17:18:39 [Info]   config files - OK
2022-10-04 17:18:39 [Info] Backing up tables...
2022-10-04 17:18:39 [Info]   pq (percolate) [425B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info]   products (rt) [512B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info] Running sync
2022-10-04 17:18:42 [Info]  OK
2022-10-04 17:18:42 [Info] You can find backup here: /mnt/backup/backup-20221004171839
2022-10-04 17:18:42 [Info] Elapsed time: 2.76s
2022-10-04 17:18:42 [Info] Done

manticore-backup --backup-dir=/mnt/backup/ --tables=products

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: products
Target dir: /mnt/backup/
Manticore config
  endpoint =  127.0.0.1:9308
Manticore versions:
  manticore: 5.0.3
  columnar: 1.16.1
  secondary: 0.0.0
2022-10-04 17:25:02 [Info] Starting the backup...
2022-10-04 17:25:02 [Info] Backing up config files...
2022-10-04 17:25:02 [Info]   config files - OK
2022-10-04 17:25:02 [Info] Backing up tables...
2022-10-04 17:25:02 [Info]   products (rt) [512B]...
2022-10-04 17:25:02 [Info]    OK
2022-10-04 17:25:02 [Info] Running sync
2022-10-04 17:25:06 [Info]  OK
2022-10-04 17:25:06 [Info] You can find backup here: /mnt/backup/backup-20221004172502
2022-10-04 17:25:06 [Info] Elapsed time: 4.82s
2022-10-04 17:25:06 [Info] Done

Вы также можете сделать резервную копию данных через SQL, выполнив простую команду BACKUP TO /path/to/backup.

ПРИМЕЧАНИЕ: BACKUP не поддерживается в Windows. Рассмотрите возможность использования mysqldump вместо этого.

ПРИМЕЧАНИЕ: BACKUP требует Manticore Buddy. Если команда не работает, убедитесь, что Buddy установлен.

BACKUP
  [{TABLE | TABLES} a[, b]]
  TO path_to_backup
  [{OPTION | OPTIONS}
    async = {on | off | 1 | 0 | true | false | yes | no}
    [, compress = {on | off | 1 | 0 | true | false | yes | no}]
  ]

Например, чтобы сделать резервную копию таблиц a и b в каталог /backup, выполните следующую команду:

BACKUP TABLES a, b TO /backup

Доступны опции для управления и настройки процесса резервного копирования, такие как:

• async: делает резервное копирование неблокирующим, позволяя сразу получить ответ с путем резервной копии и выполнять другие запросы во время выполнения резервного копирования. Значение по умолчанию — 0.
• compress: включает сжатие файлов с помощью zstd. Значение по умолчанию — 0.

Например, чтобы выполнить резервное копирование всех таблиц в асинхронном режиме с включённым сжатием в каталог /tmp:

BACKUP TO /tmp OPTION async = yes, compress = yes

При использовании async = 1 (или yes, on, true) операция резервного копирования выполняется в фоновом задании:

• Команда возвращает управление сразу с путем резервной копии
• Вы можете продолжать выполнять другие запросы во время выполнения резервного копирования
• Задание резервного копирования выполняется в отдельном потоке, управляемом Manticore Buddy
• Во время выполнения задание резервного копирования будет отображаться в выводе SHOW QUERIES и автоматически удалится после завершения

Пример асинхронного резервного копирования:

BACKUP TO /tmp/mybackup OPTION async = 1

Это вернёт результат сразу с выводом, похожим на:

+----------------------------------+
| Path                             |
+----------------------------------+
| /tmp/mybackup/backup-20221004... |
+----------------------------------+

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

1. Путь резервной копии может содержать пробелы, если он заключён в одинарные кавычки, например, BACKUP TO '/path/with spaces'
2. Пути без пробелов не требуют кавычек: BACKUP TO /tmp/backup
3. Поддерживаются пути Windows: BACKUP TO 'C:\path' или BACKUP TO C:\windows\backup
4. Убедитесь, что Manticore Buddy запущен (по умолчанию он запущен)
5. Каталог резервного копирования должен существовать и быть доступным для записи процессом Manticore

Для обеспечения согласованности таблиц во время резервного копирования инструменты резервного копирования Manticore Search используют инновационные команды FREEZE и UNFREEZE. В отличие от традиционной функции блокировки и разблокировки таблиц, например, в MySQL, FREEZE останавливает сброс данных на диск, при этом позволяя (в определённой степени) записывать и выбирать обновлённые данные из таблицы.

Однако, если размер RAM-чана превышает порог rt_mem_limit во время длительных операций резервного копирования с большим количеством вставок, данные могут быть сброшены на диск, и операции записи будут заблокированы до завершения сброса. Несмотря на это, инструмент поддерживает баланс между блокировкой таблиц, согласованностью данных и доступностью записи в базу данных, пока таблица заморожена.

При использовании manticore-backup или SQL-команды BACKUP команда FREEZE выполняется один раз и одновременно замораживает все таблицы, которые вы сохраняете. Процесс резервного копирования затем последовательно сохраняет каждую таблицу, снимая заморозку после успешного резервного копирования каждой таблицы.

Если резервное копирование не удаётся или прерывается, инструмент пытается разморозить все таблицы.

manticore-backup --backup-dir=/mnt/backup/ --restore

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file:
Backup dir: /tmp/
Available backups: 3
  backup-20221006144635 (Oct 06 2022 14:46:35)
  backup-20221006145233 (Oct 06 2022 14:52:33)
  backup-20221007104044 (Oct 07 2022 10:40:44)

manticore-backup --backup-dir=/mnt/backup/ --restore=backup-20221007104044

Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)
Manticore config file:
Backup dir: /tmp/
2022-10-07 11:17:25 [Info] Starting to restore...
Manticore config
  endpoint =  127.0.0.1:9308
2022-10-07 11:17:25 [Info] Restoring config files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring state files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring data files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] The backup '/tmp/backup-20221007104044' was successfully restored.
2022-10-07 11:17:25 [Info] Elapsed time: 0.02s
2022-10-07 11:17:25 [Info] Done

Manticore поддерживает утилиту mysqldump из MySQL до версии 9.5 и утилиту mariadb-dump из MariaDB до версии 12.1.

mysqldump -h0 -P9306 manticore > manticore_backup.sql
mariadb-dump -h0 -P9306 manticore > manticore_backup.sql

mysqldump -h0 -P9306 --replace --net-buffer-length=16m -etc manticore tbl > tbl.sql

mysqldump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0
mariadb-dump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0

mysql -h0 -P9306 < manticore_backup.sql
mariadb -h0 -P9306 < manticore_backup.sql

Ниже приведены некоторые настройки, которые можно использовать с mysqldump для настройки вашей резервной копии:

• -t пропускает команды drop/create таблиц. Полезно для полной переиндексации текста таблицы после изменения настроек токенизации.
• --no-data: эта опция исключает данные таблиц из резервной копии, в результате получится файл с одними только схемами таблиц.
• --ignore-table=[database_name].[table_name]: эта опция позволяет пропустить определённую таблицу во время резервного копирования. Обратите внимание, что имя базы данных должно быть manticore.
• --replace для выполнения replace вместо insert. Полезно для полной переиндексации текста таблицы после изменения настроек токенизации.
• --net-buffer-length=16M для формирования партий размером до 16 мегабайт, что ускоряет восстановление.
• -e для группировки документов пакетами. Полезно для более быстрого восстановления.
• -c для сохранения имён столбцов. Полезно для переиндексации таблицы после изменения её схемы (например, изменения порядка полей).

Для полного списка настроек и их подробных описаний, пожалуйста, обратитесь к официальной документации MySQL или документации MariaDB.

• Чтобы создать дамп в режиме репликации (когда дамп включает INSERT/REPLACE INTO <cluster_name>:<table_name>):
  • Убедитесь, что таблица не изменяется во время создания дампа.
  • Используйте пользователя cluster. Например: mysqldump -u cluster ... или mariadb-dump -u cluster .... Вы можете изменить имя пользователя, включающего режим репликации для mysqldump, выполнив SET GLOBAL cluster_user = new_name.
  • Используйте флаг -t.
  • Используйте флаг --skip-lock-tables.
  • При указании таблицы в режиме репликации необходимо следовать синтаксису cluster_name:table_name. Например: mysqldump -P9306 -h0 -t -ucluster manticore cluster:tbl.
• Рекомендуется явно указывать базу данных manticore, если вы планируете делать резервное копирование всех баз, вместо использования опции --all-databases.
• Обратите внимание, что mysqldump не поддерживает резервное копирование распределённых таблиц и не может резервировать таблицы с нестинаряемыми (non-stored) полями. В таких случаях используйте manticore-backup или SQL команду BACKUP. Если у вас есть распределённые таблицы, рекомендуется всегда указывать конкретные таблицы для дампа.

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

Один из способов решения этой проблемы — использовать несколько таблиц вместо одной большой. Например, можно обработать источники, созданные в предыдущие годы, и сохранить таблицу. Затем взять только источники текущего года и поместить их в отдельную таблицу, перестраивая её так часто, как необходимо. После этого обе таблицы можно объединить в распределённую таблицу и использовать её для запросов. Суть в том, что при каждой перестройке вы обрабатываете данные не старше 12 месяцев, а таблица с более старыми данными остаётся без изменений и не требует перестройки. Можно пойти дальше и разделить таблицу за последние 12 месяцев на месячные, недельные или дневные таблицы и так далее.

Этот подход работает, но вам нужно вручную поддерживать распределённую таблицу. То есть добавлять новые части, удалять старые и следить, чтобы общее количество частичных таблиц не было слишком большим (при слишком большом количестве таблиц поиск может замедлиться, а ОС обычно ограничивает число одновременно открытых файлов). Для решения этой задачи можно вручную объединять несколько таблиц, запуская indexer --merge. Однако это решает только проблему большого количества таблиц, усложняя обслуживание. И даже при переиндексации «по часам» у вас, скорее всего, будет заметный временной разрыв между появлением новых данных в источниках и перестройкой таблицы, которая делает эти данные доступными для поиска.

Таблица в реальном времени создана для решения этой проблемы. Она состоит из двух частей:

1. Специальной таблицы в оперативной памяти (называемой RAM chunk), которая содержит части данных, поступающих прямо сейчас.
2. Набора обычных таблиц, называемых disk chunks, которые были построены ранее.

Это очень похоже на стандартную распределённую таблицу, состоящую из нескольких локальных таблиц.

Вам не нужно строить такую таблицу, запуская indexer, который читает "рецепт" из конфигурации и источники данных таблиц. Вместо этого таблица в реальном времени предоставляет возможность «вставлять» новые документы и «заменять» существующие. При выполнении команды 'insert' вы отправляете новые документы на сервер. Он строит небольшую таблицу из добавленных документов и сразу же выводит её в онлайн. Таким образом, сразу после завершения команды 'insert' вы можете выполнять поиск во всех частях таблицы, включая только что добавленные документы.

Сервер поиска автоматически поддерживает таблицу, так что вам не нужно об этом беспокоиться. Однако вам может быть интересно узнать некоторые детали о том, «как она поддерживается».

Во-первых, поскольку индексированные данные хранятся в оперативной памяти — что будет при аварийном отключении питания? Потеряю ли я тогда таблицу? Перед завершением сервер сохраняет новые данные в специальный «binlog». Это один или несколько файлов, находящихся на вашем постоянном хранилище, которые инкрементально растут по мере добавления изменений. Вы можете настроить поведение относительно того, как часто новые запросы (или транзакции) сохраняются в binlog и как часто выполняется команда 'sync' для binlog-файла, чтобы заставить ОС действительно сохранить данные на надёжном носителе. Самый параноидальный подход — сбрасывать и синхронизировать после каждой транзакции. Это самый медленный, но и самый безопасный метод. Самый дешёвый способ — полностью отключить binlog. Это самый быстрый метод, но вы рискуете потерять индексированные данные. Также предусмотрены промежуточные варианты, например, сброс/синхронизация каждую секунду.

Binlog предназначен специально для последовательного сохранения новых транзакций; это не таблица и по нему нельзя выполнять поиск. Это всего лишь страховка, гарантирующая, что сервер не потеряет ваши данные. Если произойдёт внезапный сбой и всё упадёт из-за программной или аппаратной ошибки, сервер загрузит самый свежий доступный дамп RAM chunk и затем воспроизведёт binlog, повторяя сохранённые транзакции. В итоге он достигнет того же состояния, в котором находился в момент последнего изменения.

Во-вторых, как насчёт ограничений? Что если я хочу обработать, скажем, 10 ТБ данных, но они просто не помещаются в оперативную память! Оперативная память для таблицы в реальном времени ограничена и может быть настроена. Когда индексируется определённый объём данных, сервер управляет RAM-частью таблицы, объединяя маленькие транзакции, чтобы их количество и общий размер оставались небольшими. Однако этот процесс иногда может вызывать задержки при вставке. Когда объединение уже не помогает, и новые вставки достигают лимита RAM, сервер преобразует таблицу в оперативной памяти в обычную таблицу на диске (называемую disk chunk). Эта таблица добавляется в набор таблиц второй части RT-таблицы и становится доступной онлайн. Затем RAM очищается, и пространство освобождается.

Когда данные из RAM надёжно сохранены на диск, что происходит:

• когда сервер сохраняет собранные данные как дисковую таблицу
• или когда он сбрасывает RAM-часть при корректном завершении работы или с помощью ручного сброса

binlog для этой таблицы больше не нужен. Поэтому он удаляется. Если все таблицы сохранены, binlog будет удалён.

Третье, как насчёт сбора дисков? Если наличие множества частей диска замедляет поиск, в чём разница, если я создаю их вручную в виде распределённой таблицы, или они создаются как части диска (или «чанки») таблицей RT? В обоих случаях вы можете объединить несколько таблиц в одну. Например, можно объединить почасовые таблицы за вчерашний день и вместо этого сохранить одну «суточную» таблицу за вчера. При ручном обслуживании вам нужно самостоятельно продумывать схему и команды. С таблицей RT сервер предоставляет команду OPTIMIZE, которая делает то же самое, но избавляет вас от ненужных внутренних деталей.

Четвёртое, если мой «документ» представляет собой «мини-таблицу» и он мне больше не нужен, я могу просто выбросить его. Но если он «оптимизирован», то есть смешан с множеством других документов, как я могу отменить или удалить его? Да, индексированные документы «смешаны» вместе, и нет простого способа удалить один без перестройки всей таблицы. И если для обычных таблиц перестройка или слияние — это нормальный способ обслуживания, то для таблицы реального времени это сохраняет только простоту манипуляций, но не «реальное время». Чтобы решить эту проблему, Manticore использует хитрость: когда вы удаляете документ, идентифицированный по ID документа, сервер просто отслеживает этот номер. Вместе с другими удалёнными документами их ID сохраняются в так называемом kill-list. При поиске по таблице сервер сначала извлекает все подходящие документы, а затем исключает документы, найденные в kill-list (это самое базовое описание; на самом деле внутри всё сложнее). Суть в том, что ради «немедленного» удаления документы фактически не удаляются, а просто помечаются как «удалённые». Они всё ещё занимают место в различных структурах таблицы, по сути являясь мусором. Статистика слов, которая влияет на ранжирование, также не затрагивается, то есть работает именно так, как заявлено: мы ищем среди всех документов, а затем просто скрываем помеченные как удалённые из итогового результата. Когда документ заменяется, это означает, что он убивается в старых частях таблицы и вставляется заново в самую свежую часть. Все последствия «скрытия через killlist» также действуют в этом случае.

Когда происходит перестройка какой-то части таблицы, например, когда сливаются некоторые транзакции (сегменты) RAM-чанка, или когда RAM-чанк конвертируется в дисковый чанк, или когда два дисковых чанка объединяются, сервер выполняет комплексную итерацию по затронутым частям и физически исключает удалённые документы из всех них. То есть, если они были в списках документов некоторых слов — они вычищаются. Если это было уникальное слово — оно удаляется полностью.

В итоге: удаление работает в два этапа:

1. Сначала мы помечаем документы как «удалённые» в реальном времени и подавляем их в результатах поиска.
2. Во время некоторой операции с чанком таблицы RT мы окончательно физически удаляем удалённые документы.

Пятое, если таблица RT содержит обычные дисковые таблицы в своей коллекции, могу ли я просто добавить в неё свою готовую старую дисковую таблицу? Нет. Это невозможно, чтобы избежать ненужной сложности и предотвратить случайное повреждение. Однако, если ваша таблица RT только что создана и не содержит данных, вы можете ATTACH TABLE вашу дисковую таблицу к ней. Ваша старая таблица будет перемещена внутрь таблицы RT и станет её частью.

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