blog-post

Manticore Search 4.0.2: полная поддержка колонного хранилища, автоматическая компакция индексов, переработка системы блокировок, псевдо-шардинг

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

  • Полная поддержка Manticore Columnar Library . Ранее Manticore Columnar Library поддерживалась только для обычных индексов. Теперь она поддерживается:
  • в индексах реального времени для INSERT, REPLACE, DELETE, OPTIMIZE
  • в репликации
  • в ALTER
  • в indextool --check
  • Автоматическая компакция индексов ( #478 ). Наконец, вам не нужно вручную вызывать OPTIMIZE или через крон-задачу или другой вид автоматизации. Manticore теперь делает это самостоятельно. Вы можете установить порог компакции по умолчанию через optimize_cutoff .
  • Переработка системы снимков чанков и блокировок. Эти изменения могут быть невидимы снаружи на первый взгляд, но они значительно улучшают поведение многих вещей, происходящих в индексах реального времени. В двух словах, ранее большинство операций манипуляции данными Manticore сильно полагались на блокировки, теперь мы используем снимки дисковых чанков вместо этого. В частности:
    • операции чтения (например, SELECT, репликация) выполняются с помощью снимков
    • операции, которые просто изменяют внутреннюю структуру индекса без изменения схемы/документов (например, слияние сегментов RAM, сохранение дисковых чанков, слияние дисковых чанков) выполняются с помощью только для чтения снимков и в конце заменяют существующие чанки
    • UPDATE и DELETE выполняются по существующим чанкам, но в случае слияния, которое может происходить, записи собираются и затем применяются к новым чанкам
    • UPDATE последовательно получает эксклюзивную блокировку для каждого чанка. Слияния получают общую блокировку при входе на этап сбора атрибутов из чанка. Таким образом, в одно и то же время только одна (слияние или обновление) операция имеет доступ к атрибутам чанка.
    • когда слияние доходит до фазы, когда ему нужны атрибуты, оно устанавливает специальный флаг. Когда UPDATE завершается, он проверяет флаг, и если он установлен, все обновление сохраняется в специальной коллекции. Наконец, когда слияние завершается, оно применяет обновления к новорожденному дисковому чанку
    • ALTER выполняется через эксклюзивную блокировку
    • репликация выполняется как обычная операция чтения, но дополнительно сохраняет атрибуты перед SST и запрещает обновления во время SST
  • ALTER может добавлять/удалять полнотекстовое поле. Ранее он мог только добавлять/удалять атрибут.
  • 🔬 Экспериментально: псевдо-шардинг для запросов полного сканирования - позволяет параллелизовать любой запрос, не являющийся полнотекстовым. Вместо того, чтобы вручную подготавливать шарды, вы теперь можете просто включить новую опцию searchd.pseudo_sharding и ожидать до CPU cores более низкого времени отклика для запросов, не являющихся полнотекстовыми. Обратите внимание, что это может легко занять все существующие ядра CPU, поэтому, если вы заботитесь не только о задержке, но и о пропускной способности, используйте это с осторожностью.

Небольшие изменения

  • Linux Mint и Ubuntu Hirsute Hippo поддерживаются через APT репозиторий
  • более быстрое обновление по id через HTTP в больших индексах в некоторых случаях (в зависимости от распределения id)
  • пользовательские флаги запуска для systemd . Теперь вам не нужно вручную запускать searchd, если вам нужно запустить Manticore с каким-то конкретным флагом запуска
  • новая функция LEVENSHTEIN() , которая вычисляет расстояние Левенштейна
  • добавлены новые флаги запуска searchd --replay-flags=ignore-trx-errors и --replay-flags=ignore-all-errors, чтобы можно было все еще запустить searchd, если бинарный журнал поврежден
  • #621 - вывод ошибок из RE2
  • более точный COUNT(DISTINCT) для распределенных индексов, состоящих из локальных обычных индексов
  • FACET DISTINCT для удаления дубликатов при выполнении фасетного поиска
  • точная форма модификатора теперь не требует морфологии и работает для индексов с включенным поиском инфикс/префикс

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

  • новая версия может читать старые индексы, но старые версии не могут читать индексы Manticore 4
  • удалена неявная сортировка по id. Сортируйте явно, если это необходимо
  • значение по умолчанию для charset_table изменяется с 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F, U+401->U+451, U+451 на non_cjk
  • OPTIMIZE происходит автоматически. Если вам это не нужно, убедитесь, что вы установили auto_optimize=0 в разделе searchd в конфигурационном файле
  • #616 ondisk_attrs_default были устаревшими, теперь они удалены
  • для участников: теперь мы используем компилятор Clang для сборок Linux, так как согласно нашим тестам он может собрать более быстрый Manticore Search и Manticore Columnar Library
  • если max_matches не указан в запросе поиска, он обновляется неявно до наименьшего необходимого значения ради производительности нового колонного хранилища. Это может повлиять на метрику total в SHOW META , но не на total_found, который является фактическим количеством найденных документов.

Миграция с Manticore 3

  • убедитесь, что вы остановили Manticore 3 корректно:
  • в /var/lib/manticore/binlog/ не должно быть файлов binlog (в директории должен быть только binlog.meta)
  • в противном случае индексы, для которых Manticore 4 не может воспроизвести binlogs, не будут запущены
  • новая версия может читать старые индексы, но старые версии не могут читать индексы Manticore 4, поэтому убедитесь, что вы сделали резервную копию, если хотите легко откатить новую версию
  • если вы запускаете кластер репликации, убедитесь, что вы:
  • сначала корректно остановили все ваши узлы
  • а затем запустите узел, который был остановлен последним, с --new-cluster (запустите инструмент manticore_new_cluster в Linux).
  • прочитайте о перезапуске кластера для получения дополнительных деталей

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

  • Исправлено множество проблем с репликацией:
  • 696f8649 - исправлен сбой во время SST на joiner с активным индексом; добавлена проверка sha1 на узле joiner при записи файловых частей для ускорения загрузки индекса; добавлена ротация измененных файлов индекса на узле joiner при загрузке индекса; добавлено удаление файлов индекса на узле joiner, когда активный индекс заменяется новым индексом от узла донора; добавлены точки журнала репликации на узле донора для отправки файлов и частей
  • b296c55a - сбой на JOIN CLUSTER в случае неправильного адреса
  • 418bf880 - во время первоначальной репликации большого индекса узел joiner мог завершиться с ERROR 1064 (42000): invalid GTID, (null), узел донора мог стать неотзывчивым, пока другой узел присоединялся
  • 6fd350d2 - хеш мог быть рассчитан неправильно для большого индекса, что могло привести к сбою репликации
  • #615 - репликация не удалась при перезапуске кластера
  • #574 - indextool --help не отображает параметр --rotate
  • #578 - высокая загрузка CPU у searchd в режиме ожидания после примерно одного дня
  • #587 - немедленно сбросить .meta
  • #617 - manticore.json очищается
  • #618 - searchd --stopwait не работает под root. Это также исправляет поведение systemctl (ранее он показывал сбой для ExecStop и не ждал достаточно долго, чтобы searchd остановился корректно)
  • #619 - INSERT/REPLACE/DELETE против SHOW STATUS. command_insert, command_replace и другие показывали неправильные метрики
  • #620 - charset_table для простого индекса имел неправильное значение по умолчанию
  • 8f753688 - новые дисковые части не блокируются
  • #607 - узел кластера Manticore аварийно завершает работу, когда не может разрешить узел по имени
  • #623 - репликация обновленного индекса может привести к неопределенному состоянию
  • ca03d228 - индексатор мог зависнуть при индексации источника простого индекса с атрибутом json
  • 53c75305 - исправлено выражение фильтра "не равно" в индексе PQ
  • ccf94e02 - исправлены выборки окон в запросах списка выше 1000 совпадений. SELECT * FROM pq ORDER BY id desc LIMIT 1000 , 100 OPTION max_matches=1100 ранее не работал
  • a0483fe9 - HTTPS-запрос к Manticore мог вызвать предупреждение "max packet size(8388608) exceeded"

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

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