Manticore можно установить на Windows несколькими способами. Мы рекомендуем использовать WSL (Подсистема Windows для Linux), поскольку она поддерживает репликацию и не требует Docker. Ниже приведены рекомендуемые и альтернативные методы.

Для установки Manticore Search на Windows сначала необходимо включить Подсистему Windows для Linux. WSL2 позволяет запускать Linux-бинарники нативно на Windows. Для работы этого метода требуется Windows 10 версии 2004 и выше или Windows 11.

Следуйте официальному руководству Microsoft для пошаговой инструкции по установке WSL2.

Для установки Manticore на Windows через WSL2 обратитесь к разделу Установка на Debian и Ubuntu.

ПРИМЕЧАНИЕ: Установка Manticore через WSL2 — рекомендованный метод, так как он обеспечивает лучшую совместимость по сравнению с использованием нативных Windows-пакетов.

В качестве альтернативы вы можете установить Manticore в виде нативных бинарников Windows, которые требуют Docker для Manticore Buddy, выполнив следующие шаги:

1. Установите Docker Desktop и запустите его.
2. Скачайте установщик Manticore Search (ссылка доступна на странице установки) и запустите его. Следуйте инструкциям установки.
3. Выберите директорию для установки.
4. Выберите компоненты, которые хотите установить. Мы рекомендуем установить все.
5. Manticore поставляется с предварительно настроенным файлом manticore.conf в RT режиме. Дополнительная настройка не требуется.

ПРИМЕЧАНИЕ: Нативные бинарники Windows не поддерживают репликацию.

Для установки сервера Manticore Search как службы Windows выполните:

\path\to\searchd.exe --install --config \path\to\config --servicename Manticore

Обязательно используйте полный путь к файлу конфигурации, иначе searchd.exe не сможет его найти при запуске в качестве службы.

После установки службу можно запустить через оснастку Службы (Services) в Microsoft Management Console.

После запуска вы можете получить доступ к Manticore через интерфейс командной строки MySQL:

mysql -P9306 -h127.0.0.1

Обратите внимание, что во многих примерах в данном руководстве используется -h0 для подключения к локальному хосту, но в Windows необходимо явно использовать localhost или 127.0.0.1.

Компиляция Manticore Search из исходных кодов позволяет использовать пользовательские конфигурации сборки, такие как отключение определенных функций или добавление новых патчей для тестирования. Например, вы можете захотеть скомпилировать из исходных кодов и отключить встроенный ICU, чтобы использовать другую версию, установленную в вашей системе, которую можно обновлять независимо от Manticore. Это также полезно, если вы заинтересованы в участии в проекте Manticore Search.

Для подготовки официальных релизных и development пакетов мы используем Docker и специальный образ для сборки. Этот образ включает в себя необходимые инструменты и предназначен для использования с внешними sysroot, поэтому один контейнер может собирать пакеты для всех операционных систем. Вы можете собрать образ, используя Dockerfile и README, или использовать образ из Docker Hub. Это самый простой способ создания бинарных файлов для любой поддерживаемой операционной системы и архитектуры. Вам также потребуется указать следующие переменные окружения при запуске контейнера:

• DISTR: целевая платформа: bionic, focal, jammy, buster, bullseye, bookworm, rhel7, rhel8, rhel9, rhel10, macos, windows, freebsd13
• arch: архитектура: x86_64, x64 (для Windows), aarch64, arm64 (для Macos)
• SYSROOT_URL: URL для архивов системных корней. Вы можете использовать https://repo.manticoresearch.com/repository/sysroots, если не собираете sysroot самостоятельно (инструкции можно найти здесь).
• Используйте файлы CI workflow в качестве справочника, чтобы найти другие переменные окружения, которые могут вам понадобиться:
  • https://github.com/manticoresoftware/manticoresearch/blob/master/.github/workflows/pack_publish.yml
  • https://github.com/manticoresoftware/manticoresearch/blob/master/.github/workflows/build_template.yml

Чтобы найти возможные значения для DISTR и arch, вы можете использовать каталог https://repo.manticoresearch.com/repository/sysroots/roots_with_zstd/ в качестве справочника, так как он включает sysroot для всех поддерживаемых комбинаций.

После этого сборка пакетов внутри Docker-контейнера так же проста, как вызов:

cmake -DPACK=1 /path/to/sources
cmake --build .

Например, чтобы создать пакет для Ubuntu Jammy, аналогичный официальной версии, предоставляемой Manticore Core Team, вы должны выполнить следующие команды в каталоге, содержащем исходные коды Manticore Search. Этот каталог является корнем клонированного репозитория из https://github.com/manticoresoftware/manticoresearch:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=jammy \
-e boost=boost_nov22 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/dist/build_dockers/cross/linux.cmake
cmake --build .
# or if you want to build packages:
# cmake --build . --target package

Длинный путь к исходному каталогу необходим, иначе сборка исходных кодов может завершиться неудачей в некоторых случаях (например, Centos).

Таким же образом вы можете собирать бинарные файлы или пакеты не только для популярных дистрибутивов Linux, но и для FreeBSD, Windows и macOS.

Вы также можете использовать тот же специальный docker-образ для сборки SRPM:

docker run -it --rm \
-e CACHEB="../cache" \
-e DIAGNOSTIC=1 \
-e PACK_ICUDATA=0 \
-e NO_TESTS=1 \
-e DISTR=rhel8 \
-e boost=boost_rhel_feb17 \
-e sysroot=roots_nov22 \
-e arch=x86_64 \
-e CTEST_CMAKE_GENERATOR=Ninja \
-e CTEST_CONFIGURATION_TYPE=RelWithDebInfo \
-e WITH_COVERAGE=0 \
-e SYSROOT_URL="https://repo.manticoresearch.com/repository/sysroots" \
-e HOMEBREW_PREFIX="" \
-e PACK_GALERA=0 \
-e UNITY_BUILD=1 \
-v $(pwd):/manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
manticoresearch/external_toolchain:vcpkg331_20250114 bash
# following is to be run inside docker shell
cd /manticore_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/
mkdir build && cd build
cmake -DPACK=1 ..
export CMAKE_TOOLCHAIN_FILE=$(pwd)/../dist/build_dockers/cross/linux.cmake
# The CPackSourceConfig.cmake file is now generated in the build directory
cpack -G RPM --config ./CPackSourceConfig.cmake

Это создаст Source RPM (файл .src.rpm), содержащий весь исходный код.

После того как вы создали SRPM, вы можете использовать его для сборки полного набора бинарных RPM-пакетов:

# Install build tools and dependencies
dnf install -y rpm-build cmake gcc-c++ boost-devel epel-release
# Install SRPM dependencies automatically
dnf builddep -y manticore-*.src.rpm
# Build all binary RPMs from the SRPM
rpmbuild --rebuild manticore-*.src.rpm
# Find the generated packages
ls ~/rpmbuild/RPMS/*/manticore*

ПРИМЕЧАНИЕ: Для сборки RPM из SRPM необходимо убедиться, что все зависимости, перечисленные в SRPM, полностью установлены, что может быть сложной задачей. SRPM все еще может быть полезен для:

• Аудита процесса сборки или проверки исходных и spec-файлов
• Внесения пользовательских изменений или патчей в сборку
• Понимания того, как были созданы бинарные файлы
• Выполнения требований соответствия лицензиям с открытым исходным кодом

Компиляция Manticore без использования Docker для сборки не рекомендуется, но если вам нужно это сделать, вот что вам может понадобиться знать:

• Компилятор C++
  • В Linux - можно использовать GNU (4.7.2 и выше) или Clang
  • В Windows - Microsoft Visual Studio 2019 и выше (достаточно community edition)
  • На macOS - Clang (из инструментов командной строки XCode, используйте xcode-select --install для установки).
• Bison, Flex - в большинстве систем они доступны в виде пакетов, в Windows они доступны в рамках cygwin.
• Cmake - используется на всех платформах (требуется версия 3.19 или выше)

Исходный код Manticore размещен на GitHub. Чтобы получить исходный код, клонируйте репозиторий, а затем переключитесь на нужную ветку или тег. Ветка master представляет основную ветку разработки. При выпуске релиза создается версионный тег, например 3.6.0, и начинается новая ветка для текущего релиза, в данном случае manticore-3.6.0. Голова версионной ветки после всех изменений используется в качестве источника для сборки всех бинарных релизов. Например, чтобы взять исходные коды версии 3.6.0, вы можете выполнить:

git clone https://github.com/manticoresoftware/manticoresearch.git
cd manticoresearch
git checkout manticore-3.6.0

Вы можете скачать нужный код с GitHub, используя кнопку "Download ZIP". Подходят как формат .zip, так и .tar.gz.

wget -c https://github.com/manticoresoftware/manticoresearch/archive/refs/tags/3.6.0.tar.gz
tar -zxf 3.6.0.tar.gz
cd manticoresearch-3.6.0

Manticore использует CMake. Предполагая, что вы находитесь в корневом каталоге клонированного репозитория:

mkdir build && cd build
cmake ..

CMake проверит доступные функции и настроит сборку в соответствии с ними. По умолчанию все функции считаются включенными, если они доступны. Скрипт также загружает и собирает некоторые внешние библиотеки, предполагая, что вы хотите их использовать. Неявно вы получаете поддержку максимального количества функций.

Вы также можете явно настроить сборку с помощью флагов и опций. Чтобы включить функцию FOO, добавьте -DFOO=1 к вызову CMake. Чтобы отключить её, используйте -DFOO=0. Если не указано явно, включение функции, которая недоступна (например, WITH_GALERA в сборке для MS Windows), приведет к ошибке конфигурации. Отключение функции, помимо исключения её из сборки, также отключает её проверку в системе и отключает загрузку/сборку любых связанных внешних библиотек.

• USE_SYSLOG - позволяет использовать syslog в логировании запросов.
• WITH_GALERA -Включает поддержку репликации в демоне поиска. Поддержка будет настроена при сборке, а исходники библиотеки Galera будут загружены, собраны, и включены в дистрибутив/установку. Обычно безопасно собирать с Galera, но не распространять саму библиотеку (т.е. без модуля Galera, без репликации). Однако иногда может потребоваться явное отключение, например если нужно собрать статичный бинарник, который по замыслу не может загружать никакие библиотеки, так что даже присутствие вызова функции 'dlopen' внутри демона приведёт к ошибке на этапе линковки.
• WITH_RE2 - Сборка с использованием библиотеки регулярных выражений RE2. Это необходимо для функций вроде REGEX(), и для regexp_filter функциональности.
• WITH_RE2_FORCE_STATIC - Загружает исходники RE2, компилирует их и статически линкует, так что итоговые бинарные файлы не будут зависеть от наличия общей RE2 библиотеки в вашей системе.
• WITH_STEMMER - Сборка с использованием библиотеки Snowball для стемминга.
• WITH_STEMMER_FORCE_STATIC - Загружает исходники Snowball, компилирует их и статически линкует, так что итоговые бинарные файлы не будут зависеть от наличия общей libstemmer библиотеки в вашей системе.
• WITH_ICU - Сборка с библиотекой ICU (International Components for Unicode). Она используется для сегментации китайского текста. Применяется при установке morphology=icu_chinese.
• WITH_JIEBA - Сборка с использованием инструмента сегментации китайского текста Jieba. Он используется для сегментации китайского текста. Применяется при установке morphology=jieba_chinese.
• WITH_ICU_FORCE_STATIC - Загружает исходники ICU, компилирует их и статически линкует, так что итоговые бинарные файлы не будут зависеть от наличия общей icu библиотеки в вашей системе. Также включает файл данных ICU в установку/дистрибутив. Цель статической связи ICU — иметь библиотеку известной версии, чтобы поведение было определено и не зависело от системных библиотек. Скорее всего, вы предпочтёте использовать системную ICU, так как она может обновляться со временем без необходимости перекомпиляции демона Manticore. В этом случае нужно явно отключить эту опцию. Это также сэкономит место, занимаемое файлом данных ICU (примерно 30M), так как он не будет включён в дистрибутив.
• WITH_SSL - Используется для поддержки HTTPS, а также зашифрованных подключений MySQL к демону. Системная библиотека OpenSSL будет связана с демоном. Это означает, что для запуска демона потребуется OpenSSL. Это обязательно для поддержки HTTPS, но не строго обязательно для сервера (т.е. отсутствие SSL означает невозможность подключения по HTTPS, но остальные протоколы будут работать). Библиотеки SSL версий от 1.0.2 до 1.1.1 могут использоваться Manticore, однако обратите внимание, что ради безопасности настоятельно рекомендуется использовать самую свежую SSL библиотеку. Пока что поддерживается только v1.1.1, остальные устарели ( см. стратегию выпусков openssl
• WITH_ZLIB - используется индексером для работы с сжатыми столбцами из MySQL. Используется демоном для поддержки сжатого протокола MySQL.
• WITH_ODBC - используется индексером для поддержки индексирования источников из провайдеров ODBC (обычно это UnixODBC и iODBC). В MS Windows ODBC является правильным способом работы с источниками MS SQL, поэтому индексирование MSSQL также подразумевает этот флаг.
• DL_ODBC - не линкуется с библиотекой ODBC. Если ODBC связана, но недоступна, вы не сможете запустить инструмент indexer даже если хотите обработать что-то не связанное с ODBC. Этот параметр заставляет indexer загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником ODBC.
• ODBC_LIB - имя файла библиотеки ODBC. Indexer будет пытаться загрузить этот файл, когда вы захотите обработать источник ODBC. Этот параметр автоматически определяется на основе исследования доступных общих библиотек ODBC. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ODBC_LIB с правильным путем к альтернативной библиотеке перед запуском indexer.
• WITH_EXPAT - используется индексером для поддержки индексирования источников xmlpipe.
• DL_EXPAT - не линкуется с библиотекой EXPAT. Если EXPAT связана, но недоступна, вы не сможете запустить инструмент indexer даже если хотите обработать что-то не связанное с xmlpipe. Этот параметр заставляет indexer загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником xmlpipe.
• EXPAT_LIB - имя файла библиотеки EXPAT. Indexer попытается загрузить этот файл, когда вы захотите обработать источник xmlpipe. Этот параметр автоматически определяется из анализа доступных общих библиотек EXPAT. Вы также можете переопределить это имя во время выполнения, задав переменную окружения EXPAT_LIB с правильным путем к альтернативной библиотеке перед запуском indexer.
• WITH_ICONV - для поддержки различных кодировок при индексировании источников xmlpipe с помощью indexer.
• DL_ICONV - не линкуется с библиотекой iconv. Если iconv связана, но недоступна, вы не сможете запустить инструмент indexer даже если хотите обработать что-то не связанное с xmlpipe. Этот параметр заставляет indexer загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником xmlpipe.
• ICONV_LIB - имя файла библиотеки iconv. Indexer попытается загрузить этот файл, когда вы захотите обработать источник xmlpipe. Этот параметр автоматически определяется из анализа доступных общих библиотек iconv. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ICONV_LIB с правильным путем к альтернативной библиотеке перед запуском indexer.
• WITH_MYSQL - используется индексером для поддержки индексирования источников MySQL.
• DL_MYSQL - не линкуется с библиотекой MySQL. Если MySQL связана, но недоступна, вы не сможете запустить инструментindexer даже если хотите обработать что-то не связанное с MySQL. Этот параметр заставляет indexer загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником MySQL.
• MYSQL_LIB -- имя файла библиотеки MySQL. Indexer будет пытаться загрузить этот файл, когда вы захотите обработать источник MySQL. Этот параметр автоматически определяется из анализа доступных общих библиотек MySQL. Вы также можете переопределить это имя во время выполнения, задав переменную окружения MYSQL_LIB с правильным путем к альтернативной библиотеке перед запуском indexer.
• WITH_POSTGRESQL - используется индексером для поддержки индексирования источников PostgreSQL.
• DL_POSTGRESQL - не линкуется с библиотекой PostgreSQL. Если PostgreSQL связана, но недоступна, вы не сможете запустить инструмент indexer ool даже если хотите обработать что-то не связанное с PostgreSQL. Этот параметр заставляет indexer загружать библиотеку во время выполнения только тогда, когда вы хотите работать с источником PostgreSQL.
• POSTGRESQL_LIB - имя файла библиотеки postgresql. Indexer будет пытаться загрузить указанный файл библиотеки postgresql при обработке источника postgresql. Этот параметр автоматически определяется из анализа доступных общих библиотек postgresql. Вы также можете переопределить это имя во время выполнения, задав переменную окружения POSTGRESQL_LIB с правильным путем к альтернативной библиотеке перед запуском indexer.
• LOCALDATADIR - путь по умолчанию, где демон хранит binlogs. Если этот путь не задан или явно отключен в runtime-конфигурации демона (т.е. файл manticore.conf, который не связан с этой конфигурацией сборки), binlogs будут помещены в этот путь. Обычно это абсолютный путь, однако он не обязан быть таковым, допускаются и относительные пути. Скорее всего, вам не потребуется изменять значение по умолчанию, определённое конфигурацией, которое, в зависимости от целевой системы, может быть чем-то вроде /var/data, /var/lib/manticore/data или /usr/local/var/lib/manticore/data.
• FULL_SHARE_DIR - путь по умолчанию, где хранятся все ресурсы. Он может быть переопределён переменной окружения FULL_SHARE_DIR перед запуском любого инструмента, использующего файлы из этой папки. Это важный путь, так как там по умолчанию ожидается найти множество вещей. Сюда входят предопределённые таблицы кодировок, стоп-слова, модули manticore и файлы данных icu, все помещённые в эту папку. Скрипт конфигурации обычно определяет этот путь как что-то вроде /usr/share/manticore или /usr/local/share/manticore.
• DISTR_BUILD - ярлык для опций создания пакетов. Это строковое значение с названием целевой платформы. Оно может использоваться вместо ручной настройки всех опций. В Debian и Redhat Linux значение по умолчанию может быть определено путём лёгкой инспекции и установлено как обобщённое 'Debian' или 'RHEL'. В противном случае значение не определяется.
• PACK - ещё более удобный ярлык. Он читает переменную окружения DISTR, присваивает её параметру DISTR_BUILD и затем работает как обычно. Это очень полезно при сборке в подготовленных системах сборки, таких как контейнеры Docker, где переменная DISTR задаётся на уровне системы и отражает целевую систему, для которой предназначен контейнер.
• CMAKE_INSTALL_PREFIX (path) - путь, куда предполагается установить Manticore. Сборка не выполняет установку, но подготавливает правила установки, которые выполняются при запуске команды cmake --install или при создании пакета и последующей его установке. Префикс может быть изменён в любой момент, даже во время установки, вызовом cmake --install . --prefix /path/to/installation. Однако на этапе конфигурирования эта переменная используется для инициализации значений по умолчанию для LOCALDATADIR и FULL_SHARE_DIR. Например, установка её в /my/custom на этапе конфигурирования приведёт к тому, что LOCALDATADIR будет жёстко задан как /my/custom/var/lib/manticore/data, а FULL_SHARE_DIR как /my/custom/usr/share/manticore.
• BUILD_TESTING (bool) нужна ли поддержка тестирования. Если включено, после сборки вы можете запустить 'ctest' и протестировать сборку. Обратите внимание, что тестирование подразумевает дополнительные зависимости, такие как наличие PHP cli, Python и доступного сервера MySQL с тестовой базой. По умолчанию этот параметр включён. Поэтому для 'просто сборки' вы можете отключить опцию, явно указав значение 'off'.
• BUILD_SRPMS (bool) показывать ли инструкции по сборке Source RPMs (SRPMs). Из-за ограничений CPack при компонентном упаковке SRPMs не могут быть сгенерированы напрямую вместе с бинарными RPM. При включении система сборки будет выводить инструкции по правильной генерации SRPM с использованием метода конфигурирования исходников. По умолчанию этот параметр выключен.
• LIBS_BUNDLE - путь к папке с различными библиотеками. Это в основном актуально для сборки в Windows, но может быть полезно и в других случаях, чтобы не загружать сторонние исходники каждый раз. По умолчанию этот путь не меняется скриптом конфигурации; вы должны вручную помещать всё туда. Когда, скажем, нужна поддержка стеммера, исходники будут загружены с сайта Snowball, затем распакованы, сконфигурированы, собраны и т.д. Вместо этого вы можете поместить оригинальный архив исходников (который имеет имя libstemmer_c.tgz) в эту папку. В следующий раз при сборке с нуля скрипт конфигурации сначала проверит бандл, и если найдёт там стеммер, он не загрузит его снова из интернета.
• CACHEB - путь к папке со сохранёнными сборками сторонних библиотек. Обычно такие компоненты, как galera, re2, icu и т.д., сначала загружаются или берутся из бандла, затем распаковываются, собираются и устанавливаются во временную внутреннюю папку. При сборке manticore эта папка затем используется как место, где располагаются необходимые для поддержки запрошенной функции элементы. В конце они либо линкуются с manticore (если это библиотека), либо идут прямо в дистрибутив/установку (например, galera или данные icu). Когда CACHEB задана либо как параметр конфигурации cmake, либо как переменная окружения, она используется в качестве целевой папки для этих сборок. Эту папку можно сохранять между сборками, чтобы расположенные там библиотеки больше не пересобирались, что значительно сокращает время всей сборки.

Обратите внимание, что некоторые опции организованы в тройки: WITH_XXX, DL_XXX и XXX_LIB — например, поддержка mysql, odbc и т.д. WITH_XXX определяет, будут ли действовать следующие две. Т.е., если вы установите WITH_ODBC в 0 — нет смысла указывать DL_ODBC и ODBC_LIB, и эти две опции не будут иметь эффекта, если вся функция отключена. Также XXX_LIB не имеет смысла без DL_XXX, потому что если вам не нужна опция DL_XXX, динамическая загрузка использоваться не будет, и имя, указанное в XXX_LIB, бесполезно. Это используется при интроспекции по умолчанию.

Также, использование библиотеки iconv предполагает наличие expat и бесполезно, если последний отключен.

Кроме того, некоторые библиотеки могут быть всегда доступны, и поэтому нет смысла избегать линковки с ними. Например, в Windows это ODBC. В macOS это Expat, iconv и, возможно, другие. Интроспекция по умолчанию определяет такие библиотеки и фактически выдает только WITH_XXX для них, без DL_XXX и XXX_LIB, что упрощает ситуацию.

При использовании некоторых опций конфигурация может выглядеть так:

mkdir build && cd build
cmake -DWITH_MYSQL=1 -DWITH_RE2=1 ..

Помимо общих значений конфигурации, вы также можете изучить файл CMakeCache.txt, который остается в папке сборки сразу после запуска конфигурации. Любые значения, определенные там, могут быть переопределены явно при запуске cmake. Например, вы можете запустить cmake -DHAVE_GETADDRINFO_A=FALSE ..., и эта конфигурация не будет использовать исследованное значение этой переменной, а будет использовать предоставленное вами.

Переменные окружения полезны для предоставления некоторых глобальных настроек, которые хранятся отдельно от конфигурации сборки и всегда присутствуют. Для постоянства их можно установить глобально в системе разными способами — например, добавив их в файл .bashrc, или встроив в Dockerfile, если вы создаете систему сборки на основе Docker, или записав их в переменные окружения системных настроек в Windows. Также вы можете установить их на короткое время, используя export VAR=value в оболочке. Или даже короче, добавив значения перед вызовом cmake, например, CACHEB=/my/cache cmake ... — таким образом, это будет работать только при этом вызове и не будет видно при следующем.

Некоторые из таких переменных, как известно, используются в целом cmake и некоторыми другими инструментами. Это такие вещи, как CXX, который определяет текущий компилятор C++, или CXX_FLAGS для предоставления флагов компилятора и т.д.

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

• CACHEB — то же, что опция конфигурации CACHEB
• LIBS_BUNDLE — то же, что опция конфигурации LIBS_BUNDLE
• DISTR — используется для инициализации опции DISTR_BUILD, когда используется -DPACK=1.
• DIAGNOSTIC — делает вывод конфигурации cmake гораздо более подробным, объясняя все происходящее
• WRITEB — предполагает LIBS_BUNDLE и, если установлено, будет загружать архивные файлы исходного кода для различных инструментов в папку LIBS_BUNDLE. То есть, если выходит новая версия стеммера — вы можете вручную удалить libstemmer_c.tgz из бандла, а затем запустить одноразовый WRITEB=1 cmake ... — он не найдет исходники стеммера в бандле и затем загрузит их с сайта поставщика в бандл (без WRITEB он загрузит их во временную папку внутри сборки, и они исчезнут, когда вы очистите папку сборки).

В конце конфигурации вы можете увидеть, что доступно и будет использовано, в списке, подобном этому:

-- Enabled features compiled in:
* Galera, replication of tables
* re2, a regular expression library
* stemmer, stemming library (Snowball)
* icu, International Components for Unicode
* OpenSSL, for encrypted networking
* ZLIB, for compressed data and networking
* ODBC, for indexing MSSQL (windows) and generic ODBC sources with indexer
* EXPAT, for indexing xmlpipe sources with indexer
* Iconv, for support of different encodings when indexing xmlpipe sources with indexer
* MySQL, for indexing MySQL sources with indexer
* PostgreSQL, for indexing PostgreSQL sources with indexer

cmake --build . --config RelWithDebInfo

Для установки выполните:

cmake --install . --config RelWithDebInfo

чтобы установить в пользовательскую (не по умолчанию) папку, выполните

cmake --install . --prefix path/to/build --config RelWithDebInfo

Для сборки пакета используйте цель package. Она соберет пакет в соответствии с выбором, предоставленным опцией -DDISTR_BUILD. По умолчанию это будет простой архив .zip или .tgz со всеми бинарными файлами и дополнительными файлами.

cmake --build . --target package --config RelWithDebInfo

Если вы не меняли путь к исходникам и сборке, просто перейдите в папку сборки и выполните:

cmake .
cmake --build . --clean-first --config RelWithDebInfo

Если по какой-либо причине это не работает, вы можете удалить файл CMakeCache.txt, расположенный в папке сборки. После этого шага вам придется снова запустить cmake, указав папку с исходниками и настроив опции.

Если это тоже не помогает, просто очистите папку сборки и начните с нуля.

Кратко — просто используйте --config RelWithDebInfo, как написано выше. Это не даст ошибиться.

Мы используем два типа сборки. Для разработки это Debug — он назначает флаги компилятора для оптимизации и другие вещи таким образом, что это очень удобно для разработки, подразумевая отладку с пошаговым выполнением. Однако полученные бинарные файлы довольно большие и медленные для производства.

Для выпуска релизов мы используем другой тип — RelWithDebInfo — что означает 'сборка релиза с отладочной информацией'. Он производит бинарные файлы для производства со встроенной отладочной информацией. Последняя затем отделяется в отдельные пакеты debuginfo, которые хранятся отдельно от релизных пакетов и могут быть использованы в случае некоторых проблем, таких как сбои — для расследования и исправления ошибок. Cmake также предоставляет Release и MinSizeRel, но мы их не используем. Если тип сборки недоступен, cmake выполнит сборку noconfig.

Существует два типа генераторов: одноконфигурационные и многоконфигурационные.

• Одноконфигурационным требуется тип сборки, предоставленный во время конфигурации, через параметр CMAKE_BUILD_TYPE. Если он не определен, сборка вернется к типу RelWithDebInfo, который подходит, если вы просто хотите собрать Manticore из исходников и не участвовать в разработке. Для явных сборок вы должны предоставить тип сборки, например, -DCMAKE_BUILD_TYPE=Debug.
• Многоконфигурационный выбирает тип сборки во время сборки. Он должен быть предоставлен с опцией --config, иначе он соберет что-то вроде noconfig, что нежелательно. Поэтому вы всегда должны указывать тип сборки, например, --config Debug.

Если вы хотите указать тип сборки, но не хотите заботиться о том, является ли генератор 'single' или 'multi' config - просто укажите необходимые ключи в обоих местах. Т.е., настройте с помощью -DCMAKE_BUILD_TYPE=Debug, а затем соберите с --config Debug. Просто убедитесь, что оба значения одинаковы. Если целевой сборщик является single-config, он будет использовать параметр конфигурации. Если он multi-config, параметр конфигурации будет проигнорирован, но правильная конфигурация сборки будет выбрана с помощью ключа --config.

Если вам нужен RelWithDebInfo (т.е. просто сборка для продакшена) и вы знаете, что находитесь на платформе с single-config (это все, кроме Windows) - вы можете опустить флаг --config при вызове cmake. Тогда будет настроен и использован параметр по умолчанию CMAKE_BUILD_TYPE=RelWithDebInfo. Все команды для 'сборки', 'установки' и 'создания пакета' станут короче.

Cmake - это инструмент, который сам по себе не выполняет сборку, а генерирует правила для локальной системы сборки. Обычно он хорошо определяет доступную систему сборки, но иногда вам может потребоваться явно указать генератор. Вы можете запустить cmake -G и просмотреть список доступных генераторов.

• В Windows, если у вас установлено более одной версии Visual Studio, вам может потребоваться указать, какую из них использовать, например:

  cmake -G "Visual Studio 16 2019" ....

• На всех других платформах - обычно используются Unix Makefiles, но вы можете указать другой, например, Ninja или Ninja Multi-Config, как: Multi-Config`, как:

  cmake -GNinja ...

  или

  cmake -G"Ninja Multi-Config" ...

  Ninja Multi-Config довольно полезен, так как он действительно 'multi-config' и доступен на Linux/macOS/BSD. С этим генератором вы можете перенести выбор типа конфигурации на время сборки, а также вы можете собрать несколько конфигураций в одной и той же папке сборки, меняя только параметр --config.

1. Если вы в итоге хотите собрать полнофункциональный RPM-пакет, путь к директории сборки должен быть достаточно длинным, чтобы корректно собрать отладочные символы. Например, /manticore012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789. Это потому, что инструменты RPM изменяют путь в скомпилированных бинарниках при сборке отладочной информации, и они могут просто перезаписать существующее пространство, не выделяя дополнительного. Упомянутый длинный путь содержит 100 символов, и этого вполне достаточно для такого случая.

Некоторые библиотеки должны быть доступны, если вы хотите их использовать.

• Для индексации (инструмент indexer): expat, iconv, mysql, odbc, postgresql. Без них можно обрабатывать только источники tsv и csv.
• Для обработки запросов (демон searchd): может потребоваться openssl.
• Для всего (обязательно, обязательно!) нам нужна библиотека Boost. Минимальная версия - 1.61.0, однако мы собираем бинарники с более свежей версией 1.75.0. Еще более новые версии (например, 1.76) также должны подойти. В Windows вы можете скачать предварительно собранный Boost с их сайта (boost.org) и установить его в предлагаемый по умолчанию путь (т.е. C:\\boost...). В MacOs подойдет версия, предоставляемая в brew. В Linux вы можете проверить доступную версию в официальных репозиториях, и если она не соответствует требованиям, вы можете собрать из исходников. Нам нужен компонент 'context', вы также можете собрать компоненты 'system' и 'program_options', они понадобятся, если вы также захотите собрать библиотеку Galera из исходников. Загляните в dist/build_dockers/xxx/boost_175/Dockerfile для краткой самодокументированной инструкции о том, как это сделать.

В системе сборки вам необходимо установить 'dev' или 'devel' версии этих пакетов (т.е. - libmysqlclient-devel, unixodbc-devel и т.д. Посмотрите в наших docker-файлах на названия конкретных пакетов).

В системах выполнения эти пакеты должны присутствовать хотя бы в финальных (не-dev) вариантах. (devel варианты обычно больше, так как включают не только целевые бинарники, но и различные инструменты для разработки, такие как заголовочные файлы и т.д.).

Помимо необходимых предварительных условий, вам могут понадобиться предварительно собранные клиентские библиотеки expat, iconv, mysql и postgresql. Вам придется либо собрать их самостоятельно, либо связаться с нами, чтобы получить наш набор для сборки (простой zip-архив, в котором находится папка с этими целями).

• ODBC не нужен, так как это системная библиотека.
• OpenSSL можно собрать из исходников или скачать предварительно собранный с https://slproweb.com/products/Win32OpenSSL.html (как упоминается во внутреннем скрипте cmake в FindOpenSSL).
• Boost можно скачать предварительно собранный с https://www.boost.org/ релизов.

Запустите indexer -h. Это покажет, какие функции были настроены и собраны (неважно, явно они указаны или обнаружены):

Built on Linux x86_64 by GNU 8.3.1 compiler.
Configured with these definitions: -DDISTR_BUILD=rhel8 -DUSE_SYSLOG=1 -DWITH_GALERA=1 -DWITH_RE2=1 -DWITH_RE2_FORCE_STATIC=1
-DWITH_STEMMER=1 -DWITH_STEMMER_FORCE_STATIC=1 -DWITH_ICU=1 -DWITH_ICU_FORCE_STATIC=1 -DWITH_SSL=1 -DWITH_ZLIB=1 -DWITH_ODBC=1 -DDL_ODBC=1
-DODBC_LIB=libodbc.so.2 -DWITH_EXPAT=1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DWITH_ICONV=1 -DWITH_MYSQL=1 -DDL_MYSQL=1
-DMYSQL_LIB=libmariadb.so.3 -DWITH_POSTGRESQL=1 -DDL_POSTGRESQL=1 -DPOSTGRESQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/lib/manticore/data
-DFULL_SHARE_DIR=/usr/share/manticore

Manticore Buddy — это сайдкар для Manticore Search, написанный на PHP, который помогает с различными задачами. Типичный рабочий процесс таков: перед тем как вернуть ошибку пользователю, Manticore Search спрашивает Buddy, может ли он обработать проблему для демона. PHP-код Buddy облегчает реализацию высокоуровневых функций, которые не требуют чрезвычайно высокой производительности.

Для более глубокого понимания Buddy ознакомьтесь с этими статьями:

• Введение в Buddy: PHP-сайдкар для Manticore Search
• Manticore Buddy: задачи и решения
• Manticore Buddy: плагинная архитектура
• Репозиторий Manticore Buddy на GitHub

Если вы следуете инструкциям по установке выше или на сайте, вам не нужно беспокоиться об установке или запуске Manticore Buddy: он устанавливается автоматически при установке пакета manticore-extra, и Manticore Search автоматически запускает его при старте.

Чтобы отключить Manticore Buddy, используйте настройку buddy_path.

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 без конвертации. Из-за ограничения в 4GB в версии 2.x real-time таблица могла иметь несколько дисковых кусков после операции оптимизации. После обновления до 3.x эти таблицы теперь могут быть оптимизированы до одного дискового куска с помощью обычной команды OPTIMIZE. Также изменились файлы индексов. Единственный компонент, который не претерпел структурных изменений — это файл .spp (списки попаданий). .sps (строки/json) и .spm (MVA) теперь содержатся в .spb (атрибуты переменной длины). В новом формате присутствует файл .spm, но он используется для карты строк (ранее он предназначался для MVA атрибутов). Добавлены новые расширения — .spt (поиск docid), .sphi (гистограммы вторичных индексов), .spds (хранение документов). Если вы используете скрипты, которые манипулируют файлами таблиц, их следует адаптировать под новые расширения файлов.

Процедура обновления может отличаться в зависимости от вашей конфигурации (количество серверов в кластере, наличие высокой доступности и т.п.), но в целом она включает создание новых версий таблиц 3.x и замену существующих, а также замену старых бинарных файлов 2.x на новые.

Есть два специальных требования:

• Real-time таблицы необходимо сбросить с помощью FLUSH RAMCHUNK
• Plain таблицы с kill-листами требуют добавления новой директивы в конфигурацию таблицы (см. killlist_target)

Manticore Search 3 включает новый инструмент - index_converter - который может конвертировать таблицы Sphinx 2.x / Manticore 2.x в формат 3.x. index_converter поставляется в отдельном пакете, который необходимо установить первым. Используйте tool для выполнения конвертации и создания версий ваших таблиц 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 порядок таблиц во время выполнения запроса имел значение. Например, если в delta таблице был kill-лист, чтобы применить его к основной таблице, порядок должен был быть основной, а затем delta (либо в распределенной таблице, либо в операторе FROM).

В Manticore 3 kill-листы применяются к таблице при её загрузке во время запуска searchd или при её ротировании. Новая директива killlist_target в конфигурации таблицы указывает целевые таблицы и определяет, какие doc id из исходной таблицы должны использоваться для подавления. Это могут быть id из заданного kill-листа, реальные doc id таблицы или и то, и другое.

Документы из kill-листов удаляются из целевых таблиц, они не возвращаются в результатах, даже если поиск не включает таблицу, которая предоставила kill-листы. Поэтому порядок таблиц для поиска теперь не имеет значения. Теперь delta, main и main, delta дадут одинаковые результаты.

В предыдущих версиях таблицы ротировались в порядке, заданном в конфигурационном файле. В Manticore 3 порядок ротирования таблиц стал гораздо умнее и работает в соответствии с killlist targets. До начала ротирования таблиц сервер ищет цепочки таблиц по определениям 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 для микросекунд (useconds), 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-листов:

• Использовать --killlist-target при конвертации таблицы

  $ index_converter --config /home/myuser/manticore.conf --index deltaindex --killlist-target mainindex:kl

• Добавить killlist_target в конфигурацию перед конвертацией
• Использовать команду ALTER ... KILLIST_TARGET после конвертации

Вот полный список опций 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 - удаляет путь из имен файлов, к которым обращаются таблицы: stopwords, exceptions и wordforms
• --large-docid - позволяет конвертировать документы с идентификаторами больше 2^63 и выводить предупреждение, в противном случае программа завершится с ошибкой при большом id. Эта опция была добавлена, так как в Manticore 3.x идентификаторы документов являются знаковым bigint, тогда как ранее они были беззнаковыми
• --output-dir <dir> - записывает новые файлы в выбранную папку вместо того, чтобы сохранять рядом с существующими файлами таблицы. При использовании этой опции существующие файлы таблиц останутся нетронутыми в их исходном расположении.
• --all - конвертирует все таблицы из конфигурации
• --killlist-target <targets> задает целевые таблицы, к которым будут применяться kill-листы. Эта опция должна использоваться только совместно с параметром --index