blog-post

Manticore Search 4.2.0: 10x быстрее SELECT, исправлены серьезные ошибки, поддержка Debian Bullseye

Команда Manticore рада объявить о версии Manticore Search 4.2.0 . Что нового в релизе:

Основные новые функции

  • Поддержка псевдо-шардинга для реальных индексов и полнотекстовых запросов. В предыдущем релизе мы добавили ограниченную поддержку псевдо-шардинга. Начиная с этой версии вы можете получить все преимущества псевдо-шардинга и вашего многоядерного процессора, просто активировав searchd.pseudo_sharding . Самое классное в этом то, что вам не нужно ничего делать с вашими индексами или запросами, просто включите это, и если у вас есть свободный ЦП, он будет использован для сокращения времени отклика. Это поддерживает простые и реальные индексы для полнотекстовых, фильтрационных и аналитических запросов. Например, вот как включение псевдо-шардинга может сократить среднее время отклика большинства запросов примерно на 10x на выборке отурнированных комментариев Hacker News , умноженной на 100 раз (116 миллионов документов в простом индексе).
    4.2.0 псевдо-шардинг включен и выключен
  • Debian Bullseye теперь поддерживается.
  • Транзакции PQ теперь атомарны и изолированы. Ранее поддержка транзакций PQ была ограниченной. Это позволяет более быстрому REPLACE в PQ, особенно когда вам нужно заменить много правил сразу. Подробности производительности:

Предыдущий релиз 4.0.2

Это занимает 48 секунд для вставки 1M правил PQ и 406 секунд для замены всего лишь 40K в 10K партиях.

root@perf3 ~ # mysql -P9306 -h0 -e "drop table if exists pq; create table pq (f text, f2 text, j json, s string) type='percolate';"; date; for m in `seq 1 1000`; do (echo -n "insert into pq (id,query,filters,tags) values "; for n in `seq 1 1000`; do echo -n "(0,'@f (cat | ( angry dog ) | (cute mouse)) @f2 def', 'j.json.language=\"en\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; [ $n != 1000 ] && echo -n ","; done; echo ";")|mysql -P9306 -h0; done; date; mysql -P9306 -h0 -e "select count(*) from pq"

Wed Dec 22 10:24:30 AM CET 2021
Wed Dec 22 10:25:18 AM CET 2021
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+

root@perf3 ~ # date; (echo "begin;"; for offset in `seq 0 10000 30000`; do n=0; echo "replace into pq (id,query,filters,tags) values "; for id in `mysql -P9306 -h0 -NB -e "select id from pq limit $offset, 10000 option max_matches=1000000"`; do echo "($id,'@f (tiger | ( angry bear ) | (cute panda)) @f2 def', 'j.json.language=\"de\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; n=$((n+1)); [ $n != 10000 ] && echo -n ","; done; echo ";"; done; echo "commit;") > /tmp/replace.sql; date
Wed Dec 22 10:26:23 AM CET 2021
Wed Dec 22 10:26:27 AM CET 2021
root@perf3 ~ # time mysql -P9306 -h0 < /tmp/replace.sql

real    6m46.195s
user    0m0.035s
sys     0m0.008s

Новый релиз 4.2.0

Это занимает 34 секунды для вставки 1M правил PQ и 23 секунды для замены их в 10K партиях.

root@perf3 ~ # mysql -P9306 -h0 -e "drop table if exists pq; create table pq (f text, f2 text, j json, s string) type='percolate';"; date; for m in `seq 1 1000`; do (echo -n "insert into pq (id,query,filters,tags) values "; for n in `seq 1 1000`; do echo -n "(0,'@f (cat | ( angry dog ) | (cute mouse)) @f2 def', 'j.json.language=\"en\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; [ $n != 1000 ] && echo -n ","; done; echo ";")|mysql -P9306 -h0; done; date; mysql -P9306 -h0 -e "select count(*) from pq"

Wed Dec 22 10:06:38 AM CET 2021
Wed Dec 22 10:07:12 AM CET 2021
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+

root@perf3 ~ # date; (echo "begin;"; for offset in `seq 0 10000 990000`; do n=0; echo "replace into pq (id,query,filters,tags) values "; for id in `mysql -P9306 -h0 -NB -e "select id from pq limit $offset, 10000 option max_matches=1000000"`; do echo "($id,'@f (tiger | ( angry bear ) | (cute panda)) @f2 def', 'j.json.language=\"de\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; n=$((n+1)); [ $n != 10000 ] && echo -n ","; done; echo ";"; done; echo "commit;") > /tmp/replace.sql; date
Wed Dec 22 10:12:31 AM CET 2021
Wed Dec 22 10:14:00 AM CET 2021
root@perf3 ~ # time mysql -P9306 -h0 < /tmp/replace.sql

real    0m23.248s
user    0m0.891s
sys     0m0.047s

Незначительные изменения

  • optimize_cutoff теперь доступен как параметр конфигурации в разделе searchd. Это полезно, когда вы хотите ограничить количество RT-чанков во всех ваших индексах до определенного числа глобально.
  • Commit 00874743 точный count(distinct &hellip;) и FACET &hellip; distinct по нескольким локальным физическим индексам (реальному/простому) с идентичными полями и порядком.
  • PR #598 поддержка bigint для YEAR() и других функций временных меток.
  • Коммит 8e85d4bc Адаптивный rt_mem_limit . Ранее Manticore Search собирал данные ровно до rt_mem_limit перед сохранением новой дисковой части на диск, и во время сохранения продолжал собирать до 10% больше (так называемая двойная буферизация), чтобы минимизировать возможные приостановки вставки. Если этот лимит также исчерпывался, добавление новых документов блокировалось до полного сохранения дисковой части на диск. Новый адаптивный лимит основывается на том факте, что у нас теперь есть автооптимизация , поэтому не страшно, если дисковые части не полностью соблюдают rt_mem_limit и начинают сбрасывать дисковую часть раньше. Теперь мы собираем до 50% rt_mem_limit и сохраняем это как дисковую часть. При сохранении мы смотрим на статистику (сколько мы сохранили, сколько новых документов поступило во время сохранения) и пересчитываем первоначальную скорость, которая будет использоваться в следующий раз. Например, если мы сохранили 90 миллионов документов, и еще 10 миллионов документов поступило во время сохранения, скорость составляет 90%, так что мы знаем, что в следующий раз мы можем собрать до 90% rt_mem_limit перед началом сброса другой дисковой части. Значение скорости рассчитывается автоматически от 33.3% до 95%.
  • Проблема #628 unpack_zlib для источника PostgreSQL. Спасибо, Дмитрий Воронин за вклад .
  • Коммит 6d54cf2b indexer -v и --version. Ранее вы могли видеть версию индексатора, но -v/--version не поддерживались.
  • Проблема #662 бесконечный mlock лимит по умолчанию, когда Manticore запускается через systemd.
  • Коммит 63c8cd05 spinlock -> op queue для coro rwlock.
  • Коммит 41130ce3 переменная окружения MANTICORE_TRACK_RT_ERRORS, полезная для отладки повреждений RT сегментов.

Ломающие изменения

  • Версия Binlog была увеличена, binlog из предыдущей версии не будет воспроизведен, поэтому убедитесь, что вы останавливаете Manticore Search корректно во время обновления: никаких файлов binlog не должно быть в /var/lib/manticore/binlog/, кроме binlog.meta после остановки предыдущего экземпляра.
  • Коммит 3f659f36 новый столбец “chain” в show threads option format=all. Он показывает стек некоторой информации о задачах, наиболее полезной для профилирования, поэтому если вы разбираете вывод show threads, имейте в виду новый столбец.
  • searchd.workers устарел с версии 3.5.0, теперь он отключен, если у вас все еще есть его в файле конфигурации, это вызовет предупреждение при запуске. Manticore Search запустится, но с предупреждением.

Исправления ошибок

  • Проблема #650 Manticore 4.0.2 медленнее, чем Manticore 3.6.3. 4.0.2 был быстрее, чем предыдущие версии по скорости массовых вставок, но значительно медленнее для вставок отдельных документов. Эта проблема была исправлена в 4.2.0.
  • Коммит 22f4141b RT индекс мог быть поврежден при интенсивной нагрузке REPLACE, или он мог аварийно завершить работу.
  • Коммит 03be91e4 исправлено усреднение при объединении группировщиков и групповой сортировки N; исправлено объединение агрегатов.
  • Коммит 2ea575d3 indextool --check мог завершиться аварией.
  • Коммит 7ec76d4a Проблема исчерпания памяти, вызванная UPDATE.
  • Коммит 658a727e демон мог зависнуть при INSERT.
  • Коммит 46e42b9b демон мог зависнуть при завершении работы.
  • Коммит f8d7d517 демон мог аварийно завершить работу при завершении работы.
  • Коммит 733accf1 демон мог зависнуть при аварийном завершении.
  • Коммит f7f8bd8c демон мог аварийно завершиться при запуске, пытаясь повторно присоединиться к кластеру с недействительным списком узлов.
  • Коммит 14015561 распределенный индекс мог полностью забыться в RT режиме в случае, если он не мог разрешить одного из своих агентов при запуске.
  • Проблема #683 attr bit(N) engine=‘columnar’ не работает.
  • Проблема #682 создание таблицы завершается неудачей, но оставляет директорию.
  • Проблема #663 Конфигурация завершается неудачей с: неизвестное имя ключа ‘attr_update_reserve’.
  • Проблема #632 Manticore аварийно завершает работу при пакетных запросах.
  • Проблема #679 Пакетные запросы снова вызывают аварии с v4.0.3.
  • Commit f7f8bd8c исправлена ошибка аварийного завершения демона при запуске, пытающегося повторно присоединиться к кластеру с недействительным списком узлов
  • Issue #643 Manticore 4.0.2 не принимает соединения после партии вставок
  • Issue #635 Запрос FACET с ORDER BY JSON.field или строковым атрибутом может привести к сбою
  • Issue #634 Сбой SIGSEGV при запросе с packedfactors

Установить Manticore Search

Установить Manticore Search