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

Чтобы установить Manticore Search на Windows, сначала необходимо включить Windows Subsystem for Linux. WSL2 позволяет запускать бинарные файлы Linux нативно на Windows. Для этого метода требуется версия Windows 10 не ниже 2004 или Windows 11.

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

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

ПРИМЕЧАНИЕ: Установка 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 snap-in) Microsoft Management Console.

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

mysql -P9306 -h127.0.0.1

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

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

Для подготовки официальных релизных и разработческих пакетов мы используем 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, следует выполнить следующие команды в директории с исходниками 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

Это создаст исходный 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 и выше (комьюнити-версия подходит)
  • На 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 (около 30М), поскольку он не будет включен в дистрибутив.
• WITH_SSL - используется для поддержки HTTPS, а также для зашифрованных MySQL-соединений с демоном. Системная библиотека OpenSSL будет слинкована с демоном. Это означает, что наличие OpenSSL необходимо для запуска демона. Это обязательно для поддержки HTTPS, но не обязательно для сервера (т.е. если нет SSL — невозможна работа по HTTPS, но другие протоколы будут работать). Библиотеки SSL с версий от 1.0.2 до 1.1.1 могут использоваться Manticore, однако обратите внимание, что в целях безопасности настоятельно рекомендуется использовать как можно более свежую библиотеку SSL . На данный момент поддерживается только v1.1.1, остальные устарели ( см. openssl release strategy
• WITH_ZLIB - используется индексатором для работы с сжатыми колонками из MySQL. Используется демоном для поддержки сжатого MySQL-протокола.
• WITH_ODBC - используется индексатором для поддержки индексирования источников от ODBC-провайдеров (обычно UnixODBC и iODBC). В MS Windows, ODBC — правильный способ работы с источниками MS SQL, то есть индексирование MSSQL также подразумевает этот флаг.
• DL_ODBC - не линкуется с библиотекой ODBC. Если ODBC слинкована, но недоступна, невозможно запустить инструмент indexer даже если нужно обрабатывать данные, не связанные с ODBC. Эта опция заставляет индексатор загружать библиотеку только в рантайме и только при работе с источником ODBC.
• ODBC_LIB - имя файла библиотеки ODBC. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник ODBC. Эта опция определяется автоматически по результатам исследования доступных разделяемых библиотек ODBC. Вы также можете переопределить это имя в рантайме, предоставив переменную окружения ODBC_LIB с путём к другой библиотеке перед запуском индексатора.
• WITH_EXPAT - используется индексатором для поддержки индексирования xmlpipe-источников.
• DL_EXPAT - не линкуется с библиотекой EXPAT. Если EXPAT слинкована, но недоступна, вы не сможете запустить инструмент indexer даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку Только в рантайме, когда необходимо работать с xmlpipe-источником.
• EXPAT_LIB - имя файла библиотеки EXPAT. Индексатор будет пытаться загрузить этот файл при обработке источника xmlpipe. Эта опция определяется автоматически по результатам исследования доступных разделяемых библиотек EXPAT. Вы также можете переопределить это имя в рантайме, предоставив переменную окружения EXPAT_LIB с нужным путём к альтернативной библиотеке перед запуском индексатора.
• WITH_ICONV - для поддержки различных кодировок при индексировании xmlpipe-источников индексатором.
• DL_ICONV - не линкуется с библиотекой iconv. Если iconv слинкована, но недоступна, вы не сможете запустить инструмент indexer даже если хотите обработать что-то, не связанное с xmlpipe. Эта опция заставляет индексатор загружать библиотеку только в рантайме при работе с источником xmlpipe.
• ICONV_LIB - имя файла библиотеки iconv. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник xmlpipe. Этот параметр автоматически записывается на основе исследования доступных разделяемых библиотек iconv. Вы также можете переопределить это имя во время выполнения, задав переменную окружения ICONV_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• WITH_MYSQL - используется индексатором для поддержки индексирования источников MySQL.
• DL_MYSQL - не связывать с библиотекой MySQL. Если MySQL связан, но недоступен, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с MySQL. Эта опция требует от индексатора загрузить библиотеку во время выполнения только тогда, когда вы хотите работать с источником MySQL.
• MYSQL_LIB -- имя файла библиотеки MySQL. Индексатор попытается загрузить этот файл, когда вы захотите обработать источник MySQL. Этот параметр автоматически записывается на основе исследования доступных разделяемых библиотек MySQL. Вы также можете переопределить это имя во время выполнения, задав переменную окружения MYSQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• WITH_POSTGRESQL - используется индексатором для поддержки индексирования источников PostgreSQL.
• DL_POSTGRESQL - не связывать с библиотекой PostgreSQL. Если PostgreSQL связан, но недоступен, вы не сможете запустить инструмент indexer, даже если хотите обработать что-то, не связанное с PostgreSQL. Эта опция требует от индексатора загрузить библиотеку во время выполнения только тогда, когда вы хотите работать с источником PostgreSQL.
• POSTGRESQL_LIB - имя файла библиотеки postgresql. Индексатор попытается загрузить указанный файл библиотеки postgresql при обработке источника postgresql. Этот параметр автоматически определяется на основе исследования доступных разделяемых библиотек postgresql. Вы также можете переопределить имя во время выполнения, задав переменную окружения POSTGRESQL_LIB с правильным путем к альтернативной библиотеке перед запуском индексатора.
• LOCALDATADIR - путь по умолчанию, где демон хранит binlogs. Если этот путь не указан или явно отключен в конфигурации времени выполнения демона (т.е. в файле 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 (путь) - место, куда предполагается установить 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 (булево) поддерживать ли тестирование. Если включено, после сборки можно запускать 'ctest' и тестировать сборку. Обратите внимание, что тестирование требует дополнительных зависимостей, таких как наличие PHP cli, Python и доступный сервер MySQL с тестовой базой данных. По умолчанию этот параметр включён. Поэтому для «просто сборки» вы, возможно, захотите явно отключить опцию, указав значение 'off'.
• BUILD_SRPMS (булево) показывать ли инструкции по сборке Source RPM (SRPM). Из-за ограничений CPack с компонентным пакетированием, SRPM не могут генерироваться напрямую вместе с бинарными 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-based системы сборки или записью в системных настройках переменных окружения в 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 - что означает "сборка выпуска с отладочной информацией". Он создает производственные двоичные файлы со встроенной отладочной информацией. Последняя затем разделяется на отдельные пакеты отладочной информации, которые хранятся отдельно с пакетами выпуска и могут быть использованы в случае каких-либо проблем, таких как сбои - для исследования и исправления ошибок. Cmake также предоставляет Release и MinSizeRel, но мы их не используем. Если тип сборки недоступен, cmake создаст сборку noconfig.

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

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

Если вы хотите указать тип сборки, но не хотите заботиться о том, является ли генератор 'single' или 'multi' конфигурационным — просто укажите необходимые ключи в обоих местах. Т. е. сконфигурируйте с -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" ....

• On all other platforms - usually Unix Makefiles are used, but you can specify another one, such as Ninja, or Ninja Multi-Config, as: Multi-Config`, as:

  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 и т. п. См. наши dockerfile для точных названий пакетов).

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

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

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

Выполните 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 ознакомьтесь с этими статьями:

• Introducing Buddy: the PHP sidecar for Manticore Search
• Manticore Buddy: challenges and solutions
• Manticore Buddy: pluggable design
• Manticore Buddy GitHub repository

Если вы следуете инструкциям по установке выше или на сайте, вам не нужно беспокоиться об установке или запуске 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: /var/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 в конфигурации таблицы указывает целевые таблицы и определяет, какие id документов из исходной таблицы должны использоваться для подавления. Это могут быть id из определённого kill-листа, фактические id документов таблицы или и те, и другие.

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

В прежних версиях таблицы ротировались в порядке, заданном в конфигурационном файле. В Manticore 3 порядок ротации таблиц гораздо умнее и работает в соответствии с целями kill-листов. Перед началом ротации таблиц сервер ищет цепочки таблиц по определениям killlist_target. Затем он сначала ротирует таблицы, на которые не ссылаются как на цели kill-листов. Далее он ротирует таблицы, по которым уже были выполнены ротации, и так далее. Например, если мы делаем indexer --all и у нас есть 3 таблицы: main, delta_big (целевая main) и delta_small (целевая delta_big), сначала ротируется delta_small, потом delta_big и наконец main. Это делается для того, чтобы при ротации зависимой таблицы у неё был самый актуальный kill-лист из других таблиц.

• docinfo — теперь всё во внешнем виде
• inplace_docinfo_gap — больше не требуется
• mva_updates_pool — MVAs больше не имеют выделенного пула для обновлений, так как теперь они могут обновляться непосредственно в блобе (см. ниже).

Строковые, JSON и MVA-атрибуты могут обновляться в Manticore 3.x с помощью оператора UPDATE.

В 2.x строковые атрибуты требовали REPLACE, для JSON было возможно обновлять только скалярные свойства (так как они были фиксированной длины), а MVAs могли обновляться с использованием пула MVA. Теперь обновления выполняются прямо на компоненте блоба. Один параметр, который может потребовать настройки, — это attr_update_reserve, позволяющий изменить размер выделенного дополнительного пространства в конце блоба для избежания частых перераспределений, когда новые значения больше существующих в блобе.

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