Начиная с Manticore Search 24.4.0, компактизация RT‑таблиц имеет более продвинутую модель выполнения. Вместо последовательного объединения пар чанков одно за другим, оптимизация теперь поддерживает два важных улучшения:

• слияния дисковых чанков могут выполняться параллельно

• каждая задача слияния может объединять более двух чанков одновременно

• parallel_chunk_merges : сколько задач слияния дисковых чанков RT может выполняться одновременно

• merge_chunks_per_job : сколько дисковых чанков RT может объединять одна задача за один проход

Документация по компактизации также была обновлена, чтобы описать оптимизацию как N‑стороннее слияние, обрабатываемое пулом фоновых воркеров, а не одним последовательным потоком слияния.

Почему это важно

Для RT‑нагрузок интересующая метрика часто заключается не только в скорости вставки документов, но и во времени, необходимом для того, чтобы компактизация догнала и таблица вернулась к целевому количеству чанков.

Это особенно заметно, когда:

• вы загружаете данные с постоянной скоростью
• optimize_cutoff установлен достаточно низко, чтобы слияния начинались рано
• вы ждёте завершения компактизации, прежде чем считать загрузку полностью завершённой

Это имеет наибольшее значение в двух типичных случаях:

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

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

Чтобы продемонстрировать разницу, мы загрузили 10 миллионов документов в RT‑таблицу. Каждый документ содержит:

• id bigint
• name text с сгенерированным текстом от 10 до 100 слов
• type int

Таблица была создана с помощью:

CREATE TABLE test(id bigint, name text, type int) optimize_cutoff='16'

Таким образом, целью было скомпактировать таблицу до примерно 16 дисковых чанков.

Для бенчмарка мы использовали manticore-load , наш инструмент генерации нагрузки и бенчмаркинга. Он полезен для воспроизведения подобных сценариев, стресс‑тестирования загрузки и сравнения изменений конфигурации без необходимости писать собственные скрипты каждый раз.

Данные были загружены с помощью:

manticore-load \
  --cache-gen-workers=5 \
  --drop \
  --batch-size=1000 \
  --threads=5 \
  --total=10000000 \
  --init="CREATE TABLE test(id bigint, name text, type int) optimize_cutoff='16'" \
  --load="INSERT INTO test(id,name,type) VALUES(<increment>,'<text/10/100>',<int/1/100>)" \
  --wait

До: одна задача слияния, по два чанка за раз

С принудительным включением старого поведения:

mysql -P9306 -h0 -e "set global parallel_chunk_merges=1; set global merge_chunks_per_job=2"

Запуск выглядел так:

• слияние началось через 14 секунд, когда было вставлено около 1,8M документов
• все 10M документов были загружены за 1 минуту 18 секунд
• к этому моменту данные уже были полностью доступны для поиска
• компактизация продолжала работать в фоне до 3 минут 23 секунд

На 01:18 таблица всё ещё имела более 50 чанков. Ближе к концу загрузки статус выглядел так:

17:14:50  01:17     98%         133      128.4K   21%     5          53        1         4.22GB      9.9M
17:14:51  01:18     100%        131      310.9K   15%     1          53        1         4.27GB      10.0M
...
17:16:55  03:22     100%        0        49.4K    4%      1          17        1         4.27GB      10.0M
...
Total time:       03:23

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

После: параллельные слияния плюс более крупные задачи слияния

С новыми настройками:

mysql -P9306 -h0 -e "set global parallel_chunk_merges=3; set global merge_chunks_per_job=5"

тот же рабочий процесс завершился гораздо быстрее:

• слияние снова началось примерно через 14 секунд
• все 10M документов снова были загружены примерно за 1 минуту 18 секунд
• полная компактизация завершилась всего за 1 минуту 31 секунду

Конец выполнения выглядел так:

17:19:22  01:17     99%         127      127.9K   28%     6          26        1         4.22GB      9.9M
17:19:23  01:18     100%        132      1883.8K  17%     1          23        1         4.25GB      10.0M
...
17:19:36  01:31     100%        0        110.2K   3%      1          17        1         4.25GB      10.0M
...
Total time:       01:31

Что изменилось на практике

Этап загрузки сам по себе остался примерно тем же:

• старые настройки: 1:18 для загрузки всех данных
• новые настройки: 1:18 для загрузки всех данных

Большой прирост пришёл от пост‑загрузочной компактизации:

• старые настройки: около 2:05 дополнительного времени слияния после завершения загрузки
• новые настройки: около 0:13 дополнительного времени слияния после завершения загрузки

Это примерно:

• на 55 % меньше общее время в целом, с 3:23 до 1:31
• примерно на 90 % меньше хвост слияний после вставки последнего документа

Давление чанков во время загрузки также было значительно ниже. Ближе к концу загрузки:

• старые настройки: 53 чанка
• новые настройки: 23 чанка

Таким образом, улучшение заключается не только в более раннем завершении компактизации. Оно также гораздо активнее поддерживает количество чанков под контролем, пока данные всё ещё вставляются.

Что насчёт новых значений по умолчанию?

На этом сервере, с новыми настройками по умолчанию и без какой‑либо явной настройки, тот же рабочий процесс завершился за:

Total time:       01:57

Это уже существенно сокращает старый результат 03:23, при этом оставляя возможность для дополнительной настройки с помощью:

• parallel_chunk_merges
• merge_chunks_per_job

Другими словами, новые значения по умолчанию уже улучшают работу «из коробки», а системы с достаточным запасом ввода‑вывода могут ещё больше ускорить компактизацию, осторожно увеличивая оба параметра.

Более широкие результаты бенчмарков: строковое и колонковое хранение

Пример с 10 млн документами выше ясно демонстрирует механику, но более широкая картина ещё интереснее. В более обширной матрице тестов мы измерили суммарное время загрузка + оптимизация как для строкового, так и для колонкового хранения при разных значениях:

• parallel_chunk_merges
• merge_chunks_per_job

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

• до 4.6x для строкового хранения
• до 6.8x для колонкового хранения

Ниже представлена картина «лучшее против худшего» из этого набора тестов:

Также в полных результатах есть полезный шаблон настройки:

• лучшие запуски для обоих режимов хранения сосредоточены вокруг parallel_chunk_merges=4..5
• лучшие запуски также сосредоточены вокруг merge_chunks_per_job=4..5
• самые медленные результаты постоянно были при parallel_chunk_merges=1 и merge_chunks_per_job=2

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

Как думать о двух настройках

Новая документация описывает два отдельных рычага:

• parallel_chunk_merges увеличивает количество задач слияния, которые могут выполняться одновременно
• merge_chunks_per_job увеличивает количество чанков, которые может обрабатывать каждая задача

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

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

Вывод

Если ваши RT‑нагрузки тратят слишком много времени на ожидание сжатия чанков после массовых вставок, новая модель параллельного слияния существенно меняет эту ситуацию.

В этом тесте с 10 млн документов и параметром optimize_cutoff=16:

• время до того, как все данные стали доступными для поиска, осталось прежним
• время до завершения сжатия чанков сократилось с 3:23 до 1:31
• даже новые значения по умолчанию сократили общее время до 1:57

Это именно тот тип улучшения, который важен для оперативного RT‑индексирования. Данные становятся доступными для поиска сразу после загрузки, и этот момент оставался примерно одинаковым в обоих запусках. Разница проявляется после этого: насколько долго сервер продолжает тратить время на сжатие чанков в фоновом режиме, пока таблица не вернётся к своей целевой форме. Если ваш рабочий процесс зависит от того, что таблица снова станет сжатой до следующей крупной загрузки, до закрытия окна обслуживания или до передачи системы под поисковую нагрузку, которая должна работать с меньшим количеством чанков и меньшим фоновым давлением слияния, то улучшение является значительным.