Вышел Manticore Search 28.6.6. Теперь в RT‑таблицах можно использовать UUID‑идентификаторы документов, а GROUP_CONCAT() умеет сортировать значения и ограничивать их количество в запросах с группировкой. Кроме того, в релиз вошли 16 исправлений, связанных с резервным копированием, репликацией, обработкой запросов, SQL‑совместимостью и вторичными индексами.

В статье собраны все изменения в версиях с 28.4.5 по 28.6.6.


Что нужно знать перед обновлением

Миграция данных при обновлении не требуется. Чтобы использовать UUID, при создании новой RT‑таблицы задайте id uuid. Существующие таблицы с числовыми ID продолжат работать без изменений. Изменить тип ID в существующей таблице с числового на UUID или обратно с помощью ALTER TABLE нельзя.

Два исправления особенно важны для систем в продакшене. После успешного резервного копирования RT‑таблицы теперь всегда размораживаются (раньше в редких случаях этого не происходило), поэтому последующие операции записи не остаются заблокированными. При аутентифицированной репликации снова можно добавлять уже заполненную RT‑таблицу с помощью ALTER CLUSTER ... ADD.


UUID‑идентификаторы документов в RT‑таблицах

Во многих приложениях UUID используются в качестве основных идентификаторов документов. Раньше для работы с ними в Manticore Search приходилось отдельно сопоставлять каждый UUID с числовым ID. Теперь RT‑таблицы могут напрямую использовать UUID‑идентификаторы документов:

CREATE TABLE products_uuid(id uuid, title text, price int);

Manticore принимает явно заданный UUID или генерирует его автоматически, если id не указан в INSERT или REPLACE. В запросах UUID можно сравнивать на равенство и использовать в фильтрах IN; операции REPLACEUPDATE и DELETE также поддерживают UUID в качестве ID.

UUID‑идентификаторы пока поддерживаются только в RT‑таблицах, в том числе колоночных и реплицируемых. В обычных и шардированных таблицах, а также в таблицах типа percolate они недоступны.

GROUP_CONCAT() с сортировкой и ограничением числа значений

При группировке результатов часто нужно компактно показать самые важные значения из каждой группы. Теперь в SQL‑запросах с явным GROUP BY функция GROUP_CONCAT() умеет сортировать значения и ограничивать их количество в результате:

SELECT category,
       GROUP_CONCAT(title ORDER BY price DESC SEPARATOR ', ' LIMIT 3)
FROM products
GROUP BY category;

Новые параметры ORDER BYSEPARATOR и LIMIT позволяют сразу получить нужное число значений в заданном порядке. Больше не нужно возвращать из запроса весь список, а затем сортировать и обрезать его в приложении. Полный синтаксис приведён в документации по GROUP_CONCAT().


Исправления в обслуживании таблиц, резервном копировании и работе кластера

Следующие изменения касаются прежде всего повседневного обслуживания системы, а не обычного поиска:

  • Manticore Backup 1.10.2 устраняет ошибку, из‑за которой даже после успешного резервного копирования RT‑таблица могла остаться замороженной, а последующие операции записи заблокированными.

  • При аутентифицированной репликации передача состояния теперь работает и при добавлении в кластер заполненной RT‑таблицы через ALTER CLUSTER ... ADD.

  • При ALTERTRUNCATE, удалении чанков и оптимизации RT‑таблиц теперь удаляются устаревшие внешние файлы. Настройки Jieba сохраняются, если операция ALTER TABLE их не затрагивает. При попытке внести неподдерживаемые изменения в настройки теперь возвращается явная ошибка.

  • OPTIMIZE TABLE принимает имена вида system.<table>, поэтому можно оптимизировать отдельные физические шарды.


Обработка запросов и совместимость с клиентами

Исправления затрагивают разные компоненты. Для поисковых сервисов под высокой нагрузкой особенно важны следующие:

  • Если включён boolean_simplifyCALL SNIPPETS больше не тратит по несколько секунд на упрощение отдельных сложных булевых запросов перед подсветкой.

  • Для длинных запросов — точных или близких по структуре к фразовым — теперь корректно рассчитывается необходимый размер стека. Ошибка в прежнем расчёте могла приводить к повреждению памяти или сбою searchd. Кроме того, при вычислении local_df для RT‑таблиц с несколькими чанками и распределённых таблиц из статистики по ключевым словам исключаются дубли.

  • Обновлённая колоночная библиотека исправляет ошибку, из‑за которой декодер StreamVByte мог читать данные за пределами буфера. Это могло приводить к сбою при выполнении запросов со вторичными индексами, в том числе с GROUP BY по JSON‑полям. indextool --check теперь сообщает о повреждённых файлах вторичных индексов вместо аварийного завершения.

  • Несмотря на появление ключевого слова USER в синтаксисе аутентификации, функцию USER() по‑прежнему можно вызывать; благодаря этому в клиенте MySQL снова работает команда status. Кроме того, в SHOW INDEX ... STATUS устранена гонка при одновременном вычислении перцентилей.

  • Фильтры IN(...) по ID документов теперь корректно принимают допустимые беззнаковые 64-битные значения, превышающие Long.MAX_VALUE, а сочетание LEFT JOIN с несколькими FACET больше не приводит к сбою.

В релизе также устранена гонка при обработке SSL‑подключений в SphinxQL, из‑за которой воркеры могли загружать CPU на 100%. Исправлены ошибки в разборе ответов PHP API и Ruby API: корректные фрагменты ответа, оканчивающиеся на "0", больше не теряются.

Полный список см. в журнале изменений версии 28.6.6.


Установка и обновление Manticore Search 28.6.6

Установка, как обычно, проходит согласно руководства по установке. Если в системе настроена аутентификация или репликация, перед переключением продакшн‑трафика на новую версию сверьтесь с чек‑листом внедрения аутентификации Manticore в продакшн.

Нужна помощь или хотите связаться с нами?