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

• Полная поддержка Manticore Columnar Library . Ранее Manticore Columnar Library поддерживалась только для обычных индексов. Теперь она поддерживается:
• в реальном времени индексах для INSERT, REPLACE, DELETE, OPTIMIZE
• в репликации
• в ALTER
• в indextool --check
• Автоматическое сжатие индексов ( #478 ). Наконец вам не нужно вызывать OPTIMIZE вручную или через cron‑задачу или иной тип автоматизации. 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 repository
• более быстрая обновление по id через HTTP в больших индексах в некоторых случаях (зависит от распределения id)
• custom startup flags for systemd . Теперь вам не нужно запускать searchd вручную, если требуется запустить Manticore с определённым флагом запуска
• новая функция LEVENSHTEIN() , вычисляющая расстояние Левенштейна
• добавлены новые searchd startup flags --replay-flags=ignore-trx-errors и --replay-flags=ignore-all-errors, чтобы можно было запустить searchd даже если binlog повреждён
• #621 — раскрыть ошибки из RE2
• более точный COUNT(DISTINCT) для распределённых индексов, состоящих из локальных обычных индексов
• FACET DISTINCT для удаления дубликатов при фасетном поиске
• exact form modified теперь не требует morphology и работает для индексов с включённым поиском infix/prefix

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

• новая версия может читать старые индексы, но старые версии не могут читать индексы 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"