Регулярное резервное копирование ваших таблиц необходимо для восстановления в случае сбоев системы, отказа оборудования или повреждения/потери данных. Также настоятельно рекомендуется создавать резервные копии перед обновлением до новой версии 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-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

manticore-backup поддерживает сохранение и восстановление резервных копий напрямую в/из S3-совместимого хранилища, включая AWS S3, MinIO, Wasabi, Cloudflare R2 и другие. Просто передайте URL-адрес s3://bucket/prefix в качестве --backup-dir.

Установите следующие переменные окружения перед запуском manticore-backup:

⚠️ AWS_ENDPOINT_URL не должен включать имя бакета. Бакет берётся из аргумента s3://bucket/prefix. Включение бакета в URL конечной точки приводит к его дублированию в каждом запросе и вызывает ошибки.

# Неправильно — бакет "mybucket" продублирован в пути URL
AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com/mybucket

# Правильно — конечная точка это только сервер
AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com

# Backup to AWS S3 (SSE-S3 encryption enabled by default)
export AWS_ACCESS_KEY_ID=your_key
export AWS_SECRET_ACCESS_KEY=your_secret
manticore-backup --backup-dir=s3://my-bucket/backups
# Restore from S3
manticore-backup --restore --backup-dir=s3://my-bucket/backups
manticore-backup --restore=backup-20221004171839 --backup-dir=s3://my-bucket/backups
# Use with MinIO (disable encryption)
export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=minioadmin
export AWS_ENDPOINT_URL=http://localhost:9000
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups
# Use with Cloudflare R2
export AWS_ACCESS_KEY_ID=your_r2_access_key
export AWS_SECRET_ACCESS_KEY=your_r2_secret_key
export AWS_ENDPOINT_URL=https://<account_id>.r2.cloudflarestorage.com
export AWS_REGION=auto
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups

Для резервного копирования требуется s3:PutObject, для восстановления — s3:GetObject, а для вывода списка доступных точек восстановления — s3:ListBucket.

Вы также можете делать резервное копирование данных через 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 останавливает сброс данных на диск, при этом позволяя записывать (в некоторой степени) и выбирать обновленные данные из таблицы.

Однако, если размер чанка в оперативной памяти превышает порог 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 до версии 26.7 и утилиту mariadb-dump из MariaDB до версии 12.3.

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

Чтобы применить изменённые настройки полнотекстового поиска к существующим документам, см. Переиндексация существующих документов после изменения настроек FT.

При прямой передаче дампа в mysql для переиндексации той же таблицы требуется --skip-lock-tables. При экспорте в файл и последующем воспроизведении после выхода mysqldump это не требуется.

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 (называемой RAM-чанком), содержащей части данных, поступающих прямо сейчас.
2. Набора обычных таблиц на диске, называемых дисковыми чанками, которые были построены ранее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пятое, если таблица RT содержит простые дисковые таблицы в своей коллекции, могу ли я просто добавить в неё готовую старую дисковую таблицу? Нет. Это невозможно, чтобы избежать ненужной сложности и предотвратить случайное повреждение. Однако, если ваша таблица RT только что создана и не содержит данных, то вы можете ПРИСОЕДИНИТЬ ТАБЛИЦУ вашей дисковой таблице к ней. Ваша старая таблица будет перемещена внутрь таблицы RT и станет её частью.

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