⚠️ Эта страница автоматически переведена, и перевод может быть несовершенным.
blog-post

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

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

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

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

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

Вставка 1M PQ правил занимает 48 секунд и REPLACE всего 40K в 10K пакетах занимает 406 секунд.

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

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

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 ...) и FACET ... distinct по нескольким локальным физическим индексам (реального времени/обычным) с идентичными полями и порядком.
  • PR #598 поддержка bigint для YEAR() и других функций временных меток.
  • Commit 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%.
  • Issue #628 unpack_zlib для источника PostgreSQL. Спасибо, Дмитрий Воронин за вклад .
  • Commit 6d54cf2b indexer -v и --version. Ранее вы все еще могли видеть версию индексатора, но -v/--version не поддерживались.
  • Issue #662 бесконечный лимит mlock по умолчанию, когда Manticore запускается через systemd.
  • Commit 63c8cd05 spinlock -> op queue для coro rwlock.
  • Commit 41130ce3 переменная окружения MANTICORE_TRACK_RT_ERRORS, полезная для отладки повреждений сегментов RT.

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

  • Версия Binlog была увеличена, binlog из предыдущей версии не будет воспроизведен, поэтому убедитесь, что вы останавливаете Manticore Search корректно во время обновления: никаких файлов binlog не должно быть в /var/lib/manticore/binlog/, кроме binlog.meta после остановки предыдущего экземпляра.
  • Commit 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 атрибут bit(N) engine='columnar' не работает
  • Проблема #682 создание таблицы не удалось, но оставляет директорию
  • Проблема #663 Конфигурация не удается с: неизвестное имя ключа 'attr_update_reserve'
  • Проблема #632 Manticore аварийно завершился при пакетных запросах
  • Проблема #679 Пакетные запросы снова вызывают аварии с v4.0.3
  • Коммит f7f8bd8c исправлен аварийный завершение демона при запуске, пытаясь повторно присоединиться к кластеру с недействительным списком узлов
  • Проблема #643 Manticore 4.0.2 не принимает соединения после пакета вставок
  • Проблема #635 Запрос FACET с ORDER BY JSON.field или строковым атрибутом мог вызвать аварийное завершение
  • Проблема #634 Авария SIGSEGV при запросе с packedfactors

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

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