Manticore Search 2.x сохраняет совместимость с Sphinxsearch 2.x и может загружать существующие таблицы, созданные Sphinxsearch. В большинстве случаев обновление сводится к замене бинарных файлов.
Вместо sphinx.conf (в Linux обычно находится в /etc/sphinxsearch/sphinx.conf) Manticore по умолчанию использует /etc/manticoresearch/manticore.conf. Он также работает под другим пользователем и использует другие папки.
Имя службы systemd изменилось с sphinx/sphinxsearch на manticore, и служба работает под пользователем manticore (Sphinx использовал sphinx или sphinxsearch). Также используется другая папка для файла PID.
Папки, используемые по умолчанию: /var/lib/manticore, /var/log/manticore, /var/run/manticore. Вы всё ещё можете использовать существующую конфигурацию Sphinx, но вам нужно вручную изменить права доступа к папкам /var/lib/sphinxsearch и /var/log/sphinxsearch. Или просто глобально переименовать 'sphinx' в 'manticore' в системных файлах. Если вы используете другие папки (для данных, файлов wordforms и т.д.), владение ими также должно быть переключено на пользователя manticore. Местоположение pid_file следует изменить, чтобы оно соответствовало manticore.service на /run/manticore/searchd.pid.
Если вы хотите использовать папку Manticore, файлы таблиц нужно переместить в новую папку данных (/var/lib/manticore), и права доступа должны быть изменены на пользователя manticore.
Обновление с Sphinx / Manticore 2.x до 3.x не является простым, так как движок хранения таблиц претерпел значительное обновление, и новый searchd не может загружать старые таблицы и обновлять их в новый формат на лету.
Manticore Search 3 получил переработанное хранение таблиц. Таблицы, созданные с Manticore/Sphinx 2.x, не могут быть загружены Manticore Search 3 без конвертации. Из-за ограничения в 4 ГБ, таблица реального времени в 2.x могла иметь несколько дисковых чанков после операции оптимизации. После обновления до 3.x эти таблицы теперь можно оптимизировать до одного дискового чанка с помощью обычной команды OPTIMIZE. Файлы индексов также изменились. Единственный компонент, который не претерпел структурных изменений — это файл .spp (hitlists). .sps (строки/json) и .spm (MVA) теперь содержатся в .spb (атрибуты переменной длины). Новый формат содержит файл .spm, но он используется для карты строк (ранее он был предназначен для MVA атрибутов). Добавлены новые расширения: .spt (поиск docid), .sphi (гистограммы вторичных индексов), .spds (хранение документов). Если вы используете скрипты, которые манипулируют файлами таблиц, их следует адаптировать под новые расширения файлов.
Процедура обновления может отличаться в зависимости от вашей конфигурации (число серверов в кластере, наличие высокой доступности и т.д.), но в общем случае она включает создание новых версий таблиц 3.x и замену существующих, а также замену старых бинарных файлов 2.x на новые.
Есть два специальных требования, которые нужно учесть:
- Таблицы реального времени нужно сбросить с помощью FLUSH RAMCHUNK
- Обычные таблицы с kill-листами требуют добавления новой директивы в конфигурацию таблицы (см. killlist_target)
Manticore Search 3 включает новый инструмент — index_converter — который может конвертировать таблицы Sphinx 2.x / Manticore 2.x в формат 3.x. index_converter поставляется в отдельном пакете, который нужно установить первым. С помощью этого инструмента создайте версии таблиц 3.x. index_converter может записывать новые файлы в существующую папку данных и создавать резервные копии старых файлов, либо записывать новые файлы в выбранную папку.
Если у вас один сервер:
- Установите пакет manticore-converter
- Используйте index_converter для создания новых версий таблиц в другой папке, отличной от существующей папки данных (с помощью опции
--output-dir)
- Остановите существующий Manticore/Sphinx, обновитесь до 3.0, переместите новые таблицы в папку данных и запустите Manticore
Чтобы минимизировать время простоя, вы можете скопировать таблицы 2.x, конфигурацию (вам нужно будет отредактировать пути для таблиц, логов и разных портов) и бинарные файлы в отдельное место и запустить это на отдельном порту. Направьте ваше приложение на него. После обновления до 3.0 и запуска нового сервера вы можете вернуть приложение к обычным портам. Если всё работает хорошо, остановите копию 2.x и удалите файлы, чтобы освободить место.
Если у вас есть запасной сервер (например, тестовый или staging сервер), вы можете сначала выполнить обновление таблиц там и даже установить Manticore 3 для проведения нескольких тестов. Если всё в порядке, скопируйте новые файлы таблиц на продуктивный сервер. Если у вас несколько серверов, которые можно вывести из эксплуатации, делайте это по одному и выполняйте обновление на каждом. Для распределённых конфигураций searchd 2.x может работать как мастер с узлами 3.x, так что вы можете сначала обновить узлы данных, а затем мастер-узел.
Изменений в способе подключения клиентов к движку, режиме запросов или поведении запросов не было.
Kill-листы были переработаны в Manticore Search 3. В предыдущих версиях kill-листы применялись к результирующему набору, предоставленному каждой ранее обработанной таблицей во время выполнения запроса.
Таким образом, в 2.x порядок таблиц во время запроса имел значение. Например, если у дельта-таблицы был kill-лист, чтобы применить его к основной таблице, порядок должен был быть основной, дельта (либо в распределённой таблице, либо в операторе FROM).
В Manticore 3 kill-листы применяются к таблице при её загрузке во время запуска searchd или при её ротации. Новая директива killlist_target в конфигурации таблицы указывает целевые таблицы и определяет, какие doc id из исходной таблицы должны использоваться для подавления. Это могут быть id из определённого kill-листа, фактические doc id таблицы или оба варианта.
Документы из kill-листов удаляются из целевых таблиц, они не возвращаются в результатах даже если поиск не включает таблицу, которая предоставила kill-листы. Из-за этого порядок таблиц для поиска больше не имеет значения. Теперь delta, main и main, delta дадут одинаковые результаты.
В предыдущих версиях таблицы ротировались в порядке, указанном в конфигурационном файле. В Manticore 3 порядок ротации таблиц стал гораздо умнее и работает в соответствии с целями killlist. Перед началом ротации таблиц сервер ищет цепочки таблиц по определениям killlist_target. Затем он сначала ротирует таблицы, которые нигде не упоминаются как цели kill-листов. Далее он ротирует таблицы, на которые ссылаются уже ротированные таблицы, и так далее. Например, если мы делаем indexer --all и у нас есть 3 таблицы: main, delta_big (который нацелен на main) и delta_small (с целью на delta_big), сначала ротируется delta_small, затем delta_big и наконец main. Это делается для того, чтобы при ротации зависимой таблицы она получала самый актуальный kill-лист из других таблиц.
docinfo - теперь всё extern
inplace_docinfo_gap - больше не нужен
mva_updates_pool - MVAs больше не имеют выделенного пула для обновлений, так как теперь их можно обновлять напрямую в блобе (см. ниже).
Строковые, JSON и MVA атрибуты можно обновлять в Manticore 3.x с помощью оператора UPDATE.
В версии 2.x строковые атрибуты требовали REPLACE, для JSON можно было обновлять только скалярные свойства (так как они были фиксированной ширины), а MVAs можно было обновлять с помощью пула MVA. Теперь обновления выполняются напрямую в компоненте блоба. Одной из настроек, которую может потребоваться подстроить, является attr_update_reserve, которая позволяет изменять выделенное дополнительное пространство в конце блоба, используемое для избежания частых переразмериваний, если новые значения больше существующих в блобе.
Doc id раньше были беззнаковыми 64-битными целыми числами. Теперь они являются положительными знаковыми 64-битными целыми числами.
Читайте здесь про RT режим
Manticore 3.x распознаёт и парсит специальные суффиксы, что облегчает использование числовых значений со специальным значением. Общая форма — целое число + литерал, например 10k или 100d, но не 40.3s (так как 40.3 не целое), или не 2d 4h (так как это два значения, а не одно). Литералы не чувствительны к регистру, поэтому 10W — то же, что 10w. В настоящее время поддерживаются 2 типа таких суффиксов:
- Суффиксы размера — могут использоваться в параметрах, определяющих размер чего-либо (буфер памяти, файл на диске, лимит ОЗУ и т.п.) в байтах. «Голые» числа в таких местах означают буквально размер в байтах (октетах). Суффиксы размера:
k для килобайт (1k=1024), m для мегабайт (1m=1024k), g для гигабайт (1g=1024m) и t для терабайт (1t=1024g).
- Суффиксы времени — могут использоваться в параметрах, задающих временные интервалы, такие как задержки, таймауты и т.п. «Голые» значения для таких параметров обычно имеют документированную шкалу, и вы должны знать, означает ли число, скажем, 100 — «100 секунд» или «100 миллисекунд». Однако вместо догадок можно просто написать значение с суффиксом, и оно будет однозначно определено своим суффиксом. Суффиксы времени:
us для микросекунд, ms для миллисекунд, s для секунд, m для минут, h для часов, d для дней и w для недель.
index_converter — это инструмент для конвертации таблиц, созданных в Sphinx/Manticore Search 2.x, в формат таблиц Manticore Search 3.x. Инструмент можно использовать несколькими способами:
$ index_converter --config /home/myuser/manticore.conf --index tablename
$ index_converter --config /home/myuser/manticore.conf --all
$ index_converter --path /var/lib/manticoresearch/data --all
Новая версия таблицы по умолчанию записывается в ту же папку. Файлы предыдущей версии сохраняются с расширением .old в имени. Исключение — файл .spp (hitlists), который является единственным компонентом таблицы, не изменившимся в новом формате.
Вы можете сохранить новую версию таблицы в другую папку, используя опцию -–output-dir
$ index_converter --config /home/myuser/manticore.conf --all --output-dir /new/path
Особый случай — таблицы, содержащие kill-листы. Поскольку поведение kill-листов изменилось (см. killlist_target), дельта-таблица должна знать, какие таблицы являются целевыми для применения kill-листов. Есть 3 способа получить конвертированную таблицу, готовую для установки целевых таблиц для применения kill-листов:
Вот полный список опций index_converter:
--config <file> (-c <file> для краткости) указывает index_converter использовать данный файл в качестве конфигурации. Обычно он ищет manticore.conf в каталоге установки (например, /usr/local/manticore/etc/manticore.conf, если установлен в /usr/local/sphinx), затем в текущем каталоге, в котором вы вызываете index_converter из оболочки.
--index указывает, какую таблицу следует конвертировать
--path - вместо использования конфигурационного файла можно указать путь, содержащий таблицу(ы)
--strip-path - удаляет путь из имён файлов, на которые ссылается таблица: стоп-слова, исключения и словоформы
--large-docid - позволяет конвертировать документы с идентификаторами больше 2^63 и выводить предупреждение, иначе при большом идентификаторе программа просто завершится с ошибкой. Эта опция была добавлена, так как в Manticore 3.x идентификаторы документов имеют тип signed bigint, тогда как ранее они были unsigned
--output-dir <dir> - записывает новые файлы в выбранную папку, а не в то же место, где находятся существующие файлы таблиц. При установке этой опции существующие файлы таблиц останутся нетронутыми на своих местах.
--all - конвертирует все таблицы из конфигурации
--killlist-target <targets> задаёт целевые таблицы, к которым будут применяться kill-листы. Эта опция должна использоваться только вместе с опцией --index