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

Manticore Search 4.2.0: 10x faster SELECT, major bugs fixed, Debian Bullseye support

Manticore team is excited to announce Manticore Search version 4.2.0 . What's new in the release:

Основные новые возможности

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

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

Это занимает 48 секунд для вставки 1M правил PQ и 406 секунд для REPLACE только 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 секунды для REPLACE их в пакетах по 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 ...) и FACET ... distinct по нескольким локальным физическим индексам (реального времени/обычным) с одинаковым набором/порядком полей.
  • PR #598 поддержка bigint для YEAR() и других функций временных меток.
  • Commit 8e85d4bc Адаптивный rt_mem_limit . Ранее Manticore Search собирал данные ровно до rt_mem_limit перед сохранением нового дискового чанка, а во время сохранения продолжал собирать до 10 % больше (так называемый двойной буфер), чтобы минимизировать возможную приостановку вставок. Если этот лимит также исчерпывался, добавление новых документов блокировалось до полного сохранения дискового чанка. Новый адаптивный лимит построен на том, что теперь у нас есть auto-optimize , поэтому не критично, если дисковые чанки не полностью соблюдают rt_mem_limit и начинают сбрасывать чанк раньше. Теперь мы собираем до 50 % от rt_mem_limit и сохраняем это как дисковый чанк. При сохранении мы смотрим на статистику (сколько мы сохранили, сколько новых документов пришло во время сохранения) и пересчитываем начальную скорость, которая будет использована в следующий раз. Например, если мы сохранили 90 миллионов документов, а ещё 10 миллионов пришли во время сохранения, скорость составляет 90 %, поэтому мы знаем, что в следующий раз можем собирать до 90 % от rt_mem_limit перед началом сброса другого дискового чанка. Значение скорости рассчитывается автоматически от 33,3 % до 95 %.
  • Issue #628 unpack_zlib для источника PostgreSQL. Спасибо Dmitry Voronin за вклад .
  • Commit 6d54cf2b indexer -v и --version. Ранее вы всё ещё могли увидеть версию indexer, но -v/--version не поддерживались.
  • Issue #662 бесконечный лимит mlock по умолчанию, когда Manticore запускается через systemd.
  • Commit 63c8cd05 spinlock -> очередь операций для coro rwlock.
  • Commit 41130ce3 переменная окружения MANTICORE_TRACK_RT_ERRORS, полезная для отладки повреждения RT‑сегментов.

Критические изменения

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

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

  • Issue #650 Manticore 4.0.2 медленнее, чем Manticore 3.6.3. 4.0.2 был быстрее предыдущих версий по массовой вставке, но значительно медленнее при вставке одиночных документов. Исправлено в версии 4.2.0.
  • Commit 22f4141b RT‑индекс мог повреждаться при интенсивной нагрузке REPLACE, либо мог падать
  • Commit 03be91e4 исправлено усреднение при слиянии группировок и сортировщика group N; исправлено слияние агрегатов
  • Commit 2ea575d3 indextool --check мог падать
  • Commit 7ec76d4a проблема исчерпания ОЗУ, вызванная UPDATE
  • Commit 658a727e демон мог зависать при INSERT
  • Commit 46e42b9b демон мог зависать при завершении работы
  • Commit f8d7d517 демон мог падать при завершении работы
  • Commit 733accf1 демон мог зависать при падении
  • Commit f7f8bd8c демон мог падать при запуске, пытаясь повторно присоединиться к кластеру с недействительным списком узлов
  • Commit 14015561 распределённый индекс мог полностью исчезнуть в режиме RT, если при запуске не удавалось разрешить один из его агентов
  • [Issue #
  • Issue #682 create table fails, but leaves dir
  • Issue #663 Config fails with: unknown key name 'attr_update_reserve'
  • Issue #632 Manticore crash on batch queries
  • Issue #679 Batch queries causing crashes again with v4.0.3
  • Commit f7f8bd8c fixed daemon crash on startup trying to re-join cluster with invalid nodes list
  • Issue #643 Manticore 4.0.2 does not accept connections after batch of inserts
  • Issue #635 FACET query with ORDER BY JSON.field or string attribute could crash
  • Issue #634 Crash SIGSEGV on query with packedfactors

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

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