Основные новые возможности
- Полная поддержка 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"

