Manticore Search

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:55, 26 июня 2020.
Manticore Search
Manticore Search.jpg
Выпущена: 6 July 2017 года; 4 years ago (2017-07-06)
Постоянный выпуск: 3.4.2 / 10 April 2020 года; 17 months ago (2020-04-10)
Состояние разработки: Active
Написана на: C++
Операционная система: Кроссплатформенное программное обеспечение
Тип ПО: Поисковая машина
Лицензия: GPLv2
Веб-сайт https://manticoresearch.com/

Manticore Search – база данных с открытым исходным кодом доступная бесплатно, отличительной особенностью которой является минимальное потребление ресурсов и время отклика и высокопроизводительный полнотекстовый поиск. Manticore Search используют тысячи маленьких и больших компаний (таких как, например, Craigslist и Rozetka) для поиска по небольшому объёму данных на одной ноде и петабайтам данных на сотнях нод. Используется такая функциональность, как: полнотекстовая фильтрация, автодополнение (подсказки), подсветка найденных результатов, исправление ошибок, поиск схожих документов, фасетный поиск и многие другие поисковые функции.[Источник 1]

Содержание

Ключевые особенности

Ниже представлены основные компоненты характеристики Manticore Search:

  • Быстрая индексация и поиск в реальном времени
  • Внутреннее хранилище документов
  • Масштабируемость до сотен нод
  • Фасетный поиск
  • Разумное использование оперативной памяти и диска
  • Поддержка многоязычной морфологии
  • Нативная поддержка SQL для более легкого составления запросов
  • HTTP JSON протокол для легкой совместимости с приложениями

История создания

Manticore Search появился в 2017 году как продолжение проекта Sphinx Search (который, в свою очередь, появился в 2001). От Sphinx был взят C++, упор на низкоуровневые структуры данных и оптимальные алгоритмы, а также добавлен больший функционал, исправлено большое количество ошибок, сделано более удобное использование (исходный код при этом остался открытым). В итоге Manticore Search стал ещё менее ресурсоёмким и более высокопроизводительным.

История релизов

Ниже представлена таблица всех версий Manticore Search, в которой содержатся примечания к их выпуску:

Дата Версия Описание (комментарии)
6 июля 2017 Версия 2.3.3 Первый релиз Manticore Search
16 октября 2017 Версия 2.4.1 GA Добавлены оператор OR в пункте WHERE между фильтрами атрибутов и режим технического обслуживания
23 ноября 2017 Версия 2.5.1
29 декабря 2017 Версия 2.6.0 Удалена поддержка 32-битных docids из кода
26 января 2018 Версия 2.6.1 GA Запросы Percolate теперь находятся в HTTP JSON API по адресу / json / pq
23 февраля 2018 Версия 2.6.2 GA Улучшена производительность Percolate Queries в случае использования оператора NOT и для пакетных документов
28 марта 2018 Версия 2.6.3 GA Добавлен jemalloc при компиляции. Если jemalloc присутствует в системе, его можно включить с помощью флага cmake.-DUSE_JEMALLOC=1
3 мая 2018 Версия 2.6.4 GA Добавлена поддержка двигателя MySQL FEDERATED
11 июня 2018 Версия 2.7.0 GA Добавлена полная перезагрузка конфигурации
4 июля 2018 Версия 2.7.1 GA Улучшена производительность подстановочных знаков при сопоставлении нескольких документов в PQ
27 августа 2018 Версия 2.7.2 GA Добавлена совместимость с клиентами MySQL 8
26 сентября 2018 Версия 2.7.3 GA добавлена опция sort_mode для CALL KEYWORDS
1 ноября 2018 Версия 2.7.4 GA
4 декабря 2018 Версия 2.7.5 GA Добавлена функция REGEX
28 января 2019 Версия 2.8.0 GA Добавлены встроенные коллекции стоп-слов для 50 языков
6 марта 2019 Версия 2.8.1 GA Добавлена поддержка SENTENCE и PARAGRAPH для отдельных запросов
2 апреля 2019 Версия 2.8.2 GA Минимальная версия Cmake теперь 3.13. Компиляция требует библиотек boost и libssl
6 мая 2019 Версия 3.0.0 Добавлено новое индексное хранилище. Нескалярные атрибуты больше не ограничены размером 4 ГБ на индекс
31 мая 2019 Версия 3.0.2 Удалена конечная точка HTTP / поиска
16 июля 2019 Версия 3.1.0 Добавлена репликация для индексов RealTime
22 августа 2019 Версия 3.1.2 Улучшена поддержка FreeBSD
17 октября 2019 Версия 3.2.0 Добавлено хранение документов
19 декабря 2019 Версия 3.2.2 Добавлена новая опция field_separator для выделения функций
4 февраля 2020 Версия 3.3.0 Добавлен параллельный поиск по индексу в реальном времени
26 марта 2020 Версия 3.4.0 Репликация теперь доступна только в режиме RT
10 апреля 2020 Версия 3.4.2 Исправлен индекс RT, не индексировавший данные из старой версии[Источник 2]

Начало работы

Установка и запуск с использованием контейнера Docker

Установка Manticore Search производится при помощи следующей команды:

$ docker run --name manticore -p 9306:9306 -d manticoresearch/manticore

или используя docker-compose:

version: '2.2'

services:

  manticore:
    image: manticoresearch/manticore:nodemode
    restart: always
    ulimits:
        nproc: 65535
        nofile:
            soft: 65535
            hard: 65535
        memlock:
            soft: -1
            hard: -1

Установка и запуск с использованием официальных пакетов

Пакеты последней версии GA можно скачать с http://www.manticoresearch.com/downloads

$ wget https://github.com/manticoresoftware/manticore/releases/download/x.y.z/manticore_z.y.z.deb
$ sudo dpkg -i manticore_x.y.z.deb

Запустите сервис:

$ systemctl start manticore

или

$ service manticore start

в зависимости от используемого распределения.

С этого момента вы можете начать использовать Manticore Search. Файл конфигурации находится по адресу /etc/manticoresearch/manticore.conf.

Вы также можете скомпилировать Manticore Search из источников . Компиляция проста и использует cmake. Вы также можете создавать пакеты для своей операционной системы.

Миграция из Manticore или Sphinx Search 2.x

Начиная с 3.3.2, Manticore поддерживает два режима работы: классический ( простой режим ), в котором индексы определяются в файле конфигурации, и современный подход ( режим RT ), который позволяет создавать / удалять индексы с помощью операторов SQL / HTTP-запросов.

Режим RT не поддерживает обычные и шаблонные индексы. Это руководство по миграции описывает переход на обычный режим .

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

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

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

  • Индексы RealTime должны быть сброшены в существующей версии (см. Ниже)
  • Простые индексы со списками уничтожений требуют добавления новой директивы в конфигурации индекса (см. Ниже)

Manticore Search 3 включает в себя новый инструмент - index_converter - который может конвертировать индексы 2.x в формат 3.x. Инструмент index_converter поставляется в отдельном пакете, который должен быть установлен первым. Используя инструмент конвертации, создайте 3.x версии ваших индексов. Index_converter может записывать новые файлы в существующую папку данных и делать резервные копии старых файлов, или он может записывать новые файлы в выбранную папку. Если ваш

Если у вас есть один сервер:

  • установить пакет manticore-converter
  • используйте index_converter для создания новых версий индексов в папке, отличной от существующей папки данных (используя опцию –output-dir)
  • остановите существующую Manticore, обновите до 3.0, переместите новые индексы в папку данных, запустите Manticore

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

Если у вас есть запасной ящик (например, тестовый или промежуточный сервер), вы можете сначала выполнить обновление индекса и даже установить Manticore 3, чтобы выполнить несколько тестов и, если все в порядке, скопировать новые файлы индекса на рабочий сервер. Если у вас есть несколько серверов, которые можно извлечь из производства, сделайте это один за другим и выполните обновление на каждом. Для распределенных установок 2.x searchd может работать как мастер с узлами 3.x, поэтому вы можете выполнить обновление сначала на узлах данных, а затем на главном узле.

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

Механизм хранения индекса

Manticore Search 3 получил переработанное хранилище индексов. Индексы, созданные с помощью Manticore / Sphinx 2.x, не могут быть загружены Manticore Search 3.

Существующие индексы (RealTime или обычный) можно конвертировать с помощью инструмента index_converter или перестраивать с нуля. В случае индексов RealTime перед преобразованием вам необходимо сбросить его фрагмент памяти на диск с помощью flush ramchunk.

Из-за ограничения в 4 ГБ индекс RealTime в 2.x может все еще иметь несколько дисковых блоков после операции оптимизации. После обновления до 3.x эти индексы теперь могут быть оптимизированы для фрагмента с 1 диском с помощью обычной команды optimize.

Индексные файлы также изменились. Единственный компонент, который не получил никаких структурных изменений - это sppфайл (списки совпадений). sps(строки / json) и spm(MVA) теперь хранятся в spb(атрибуты var-length). В новом формате присутствует spmфайл, но он используется для отображения строк (ранее он был выделен для атрибутов MVA). Добавлены новые расширения: spt(поиск в docid), sphi(гистограммы вторичного индекса), spds(хранение документов).

Если вы используете скрипты, которые манипулируют индексными файлами, они должны быть адаптированы к новым расширениям файлов.

Удалённые ключи конфигурации

  • docinfo - все теперь внешне
  • inplace_docinfo_gap - больше не нужен
  • mva_updates_pool - у MVA больше нет выделенного пула для обновлений, так как теперь они могут обновляться прямо в blob-объекте (см. ниже).

Обновление атрибутов var-length

Атрибуты String, JSON и MVA теперь можно обновлять с помощью оператора UPDATE.

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

Идентификаторы документов

Идентификаторы документов раньше были 64-битными целыми числами без знака. Теперь они являются позитивно подписанными 64-битными целыми числами.

Руководство по файлу конфигурации

До Manticore Search 3.3.0 индексы должны были быть определены в файле конфигурации, который теперь называется «простой режим».

В 3.3.0 был введен «режим RT», в котором файл конфигурации содержит только настройки демона, и индексы можно создавать / удалять на лету.

Режим RT

Режим реального времени не требует определения индекса в конфигурации и наличия data_dir директивы в разделе «Searchd». Индексные файлы хранятся внутри data_dir .

Начиная с 3.3.2, функция репликации доступна только в этом режиме. В этом режиме обычные и шаблонные индексы не поддерживаются.

Индексы можно создавать и удалять с помощью операторов create / drop table, как в традиционных базах данных.

Обратите внимание, что этот режим все еще развивается, и в ближайшем будущем возможны незначительные изменения синтаксиса.

Обычный режим

В этом режиме индексы, независимо от их типа, должны быть определены в файле конфигурации. Новые индексы могут быть добавлены в файл конфигурации, а sighup, отправленный на поиск или синтаксис reload indexes, может оживить индекс.

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

Путь к файлам индекса должен быть явно определен в этом режиме.

Разделы

Файл конфигурации находится в текстовом формате и может быть отредактирован любым текстовым редактором. Конфигурация логически разбита на разделы. Это содержание вложено в {и }. Существует 5 типов разделов:

  • searchd - обязательный и может быть объявлен только один раз, содержит настройки демона searchd
  • indexer - необязательно, может быть объявлен только один раз, содержит настройки для инструмента indexer
  • common - необязательный, может быть объявлен только один раз, содержит общие настройки для searchd и indexer
  • index - может быть объявлен несколько раз, поддерживает наследование, требует объявления имени индекса, содержит конфигурацию индекса. По крайней мере, один индекс должен быть объявлен.
  • source - может быть объявлен несколько раз, поддерживает наследование, требует объявления имени источника, содержит конфигурацию источника, необязательно

Разделы 'index' и 'source' запрещено использовать в режиме узла.

Индексы и источники анализируются при чтении файла конфигурации. В случае унаследованных разделов дочерние разделы должны следовать после деклараций родителей. То же самое относится к распределенным индексам с локальными индексами.

Там нет правила для порядка разделов. Они могут быть объявлены в начале или в конце файла или даже смешаны между объявлениями индекса / источника.

Руководство по подключению

Manticore Search предлагает 3 протокола, которые позволяют клиентам подключаться несколькими способами.

Обратите внимание, что в настоящее время ни один из протоколов не реализует никакой аутентификации. Кто-то, кто может подключиться к вашим поисковым экземплярам, ​​может сканировать ваши данные, выполнять сложные запросы, которые могут замедлять работу серверов, или вносить изменения в индексы. Ваши поисковые серверы не должны быть доступны для внешнего мира. Если приложение, которое подключается к Manticore, находится на том же сервере, listenпункты должны связывать протоколы только с локальным интерфейсом.

В случае, если к поисковым экземплярам требуется доступ извне, соединения должны быть ограничены с помощью брандмауэра только известными IP-адресами, разрешенными для подключения. Для SphinxQL прокси, такие как ProxySQL, могут добавить уровень аутентификации. Для протокола HTTP резервный прокси, такой как Nginx, может реализовывать аутентификации на основе HTTP.

Протокол SphinxAPI

Протокол SphinxAPI используется как для связи с клиентами, так и для подключения нескольких экземпляров демона для настройки кластера. Порт по умолчанию (и назначенный IANA) для протокола SphinxAPI - 9312.

Клиенты могут подключаться к Manticore по протоколу SphinxAPI, используя клиентские библиотеки API. Официально мы поддерживаем клиентские библиотеки API для:

У клиента Go есть собственный репозиторий на github , а остальные клиенты находятся в каталоге / api .

Для других языков существуют сторонние клиенты APi. Старые клиентские библиотеки API, включая версии для Sphinx Search, должны работать с более новыми демонами, однако они не смогут получить доступ к новым функциям.

Протокол SphinxAPI также используется плагином SphinxSE MySQL, который действует как механизм прокси, который позволяет выполнять запросы Manticore с сервера MySQL. Для получения дополнительной информации о SphinxSE см. Механизм хранения MySQL (SphinxSE) .

Протокол SphinxQL

SphinxQL - это реализация протокола MySQL 4.1. Manticore не реализует полный набор команд или функций SQL, доступных в MySQL. Существуют пользовательские предложения и функции, такие как match (), реализованные в MySQL, которых нет в MYSQL.

Manticore Search не поддерживает подготовленные операторы на стороне сервера. Подготовленные на стороне клиента заявления могут использоваться с Manticore. Следует отметить, что Manticore реализует тип данных с несколькими значениями (MVA), для которого нет эквивалента в MySQL или библиотеках, реализующих подготовленные операторы. В этих случаях значения MVA необходимо будет обработать в необработанном запросе.

Manticore Search не имеет такой концепции базы данных, как MySQL, и пока не реализовано управление доступом пользователей. Однако некоторые клиенты / коннекторы MySQL требуют значения для имени пользователя / пароля или имени базы данных. Они могут быть установлены произвольно, поскольку Manticore будет просто игнорировать значения.

Порт по умолчанию (и назначенный IANA) для протокола SphinxQL - 9306.

Руководство по индексам

Демон Manticore Search может обслуживать несколько коллекций данных, называемых индексами.

Manticore Search поддерживает два типа индексов хранилища:

обычный (также называемый автономным или дисковым) индекс. Данные индексируются один раз при создании, они поддерживают онлайн-перестроение и онлайн-обновления для нетекстовых атрибутов (доступно только для простого режима ) Индекс в реальном времени. Подобно таблице базы данных, онлайн-обновления возможны в любое время Кроме того, специальный индекс, основанный на типе реального времени, называемый percolate , может использоваться для хранения запросов Percolate .

В текущей версии индексы используют схему, подобную обычной таблице базы данных. Схема может иметь 3 больших типа столбцов:

  • первый столбец всегда представляет собой 64-разрядное ненулевое число без знака, называемое id . В отличие от базы данных, механизм автоматического увеличения отсутствует, поэтому необходимо убедиться, что идентификаторы документов уникальны.
  • полнотекстовые поля - они содержат проиндексированный контент. В каждом индексе может быть несколько полнотекстовых полей. Полнотекстовый поиск может быть сделан по всем полям или выборочно. Начиная с версии 3.2 можно также сохранять исходный контент и извлекать его в результатах.
  • атрибуты - их значения сохраняются и не используются при полнотекстовом сопоставлении. Вместо этого их можно использовать для регулярной фильтрации, группировки, сортировки. Они также могут быть использованы в выражениях рейтинга.

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

В атрибутах могут храниться следующие типы:

  • беззнаковые 32-битные и 64-битные целые числа со знаком
  • 32-разрядные поплавки одинарной точности
  • Метки времени UNIX
  • булевы
  • строки (их можно использовать только для сравнения, группировки или сортировки)
  • Объекты JSON
  • список многозначных атрибутов беззнаковых 32-битных целых

Manticore Search поддерживает тип индекса без хранения, называемый распределенным, который позволяет выполнять поиск по нескольким индексам. Связанные индексы могут быть локальными или удаленными. Распределенные индексы позволяют распределять большие данные по нескольким машинам или создавать установки высокой доступности. Поскольку поиск по индексу является однопоточным, локальные распределенные индексы могут использоваться для использования нескольких ядер ЦП.

Руководство по поиску

Нет никакой разницы между RealTime или простыми индексами с точки зрения того, как вы выполняете запросы.

Рекомендуемый и самый простой способ запроса Manticore - использовать интерфейс SphinxQL. Вы можете получить к нему доступ с любого клиента или библиотеки MySQL, просто сделайте

$ mysql -P9306 -h0

Хотя он реализует протокол MySQL, SphinxQL не на 100% совместим с синтаксисом MySQL. Существуют определенные расширения, такие как предложение match [самая мощная вещь в Manticore] или within group by, и многие функции, доступные в MySQL, не реализованы (или они являются фиктивными только для обеспечения совместимости с коннектором MySQL, например) или joins между индексами, которые пока не поддерживаются.

Индексирование

Индексы

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

Идентификатор индекса должен быть одним словом, которое может содержать буквы, цифры и подчеркивания. Это должно начинаться с буквы.

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

Manticore предоставляет 2 разных бэкэнда: бэкэнд дискового индекса и бэкэнд индекса RT (в реальном времени) .

Простые индексы

Дисковые индексы предназначены для обеспечения максимальной скорости индексации и поиска при минимальном объеме оперативной памяти. Это происходит за счет обновления текстовых индексов. Вы не можете обновить существующий документ или постепенно добавить новый документ в индекс диска. Вы можете только перестроить весь индекс диска с нуля. (Обратите внимание, что вы по-прежнему можете обновлять атрибуты документа на лету, даже с использованием дисковых индексов.)

Это ограничение «только перестроить» на первый взгляд может показаться большим ограничением. Но на самом деле его можно очень легко обойти, настроив несколько дисковых индексов, выполнив поиск по всем из них и перестроив только тот, который содержит часть недавно измененных данных. См. Обновления индекса в реальном времени для деталей.

Простые индексы доступны только в обычном режиме поиска.

Индексы в реальном времени

Индексы RT позволяют вам реализовывать динамические обновления и инкрементные добавления к полнотекстовому индексу. RT означает «Реальное время», и они действительно «мягкие в реальном времени» с точки зрения записи, что означает, что большинство изменений индекса становятся доступными для поиска всего за 1 миллисекунду или менее, но иногда могут останавливаться на секунды. (Поиск по-прежнему будет работать даже во время этой случайной записи.) Подробнее см. В индексах реального времени .

Распределённые индексы

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

Шаблоны индексов

Шаблонные индексы - это индексы без внутреннего хранилища. Они могут быть использованы операции, которые включают только данные из ввода, такие как генерация ключевых слов и фрагментов. Доступно только в обычном режиме .

Percolate индексы

Индексы Percolate - это специальные индексы реального времени, которые хранят запросы вместо документов. Они используются для предполагаемых поисков (или «поиск в обратном направлении»). Обратитесь к запросу Percolate для более подробной информации.

Для каждого файла конфигурации может быть столько индексов, сколько необходимо. indexerУтилита может переиндексировать либо все из них (если --allуказана опция), либо определенное явно указанное подмножество. searchd Утилита будет обслуживать все указанные индексы, а клиенты смогут указать, какие индексы искать во время выполнения.

Индексные файлы

Каждый индекс состоит из нескольких файлов.

Компоненты малого индекса полностью загружаются в память. Большие компоненты индекса считываются с диска по мере необходимости. В настоящее время они используют seek + read или mmap () для извлечения данных с диска. Компоненты атрибутов открываются и отображаются с помощью mmap (). Они могут быть полностью загружены в память или оставлены на диске и считаны при необходимости.

Доступ к индексным файлам

Демон использует два режима доступа для чтения данных индекса - поиск + чтение и mmap.

В seek + Режим чтения демона выполняет системный вызов pread (2) читать списки документов и ключевые позиции, то есть spdи sppфайлы. Внутренние буферы чтения используются для оптимизации чтения. Размер этих буферов можно настроить с помощью параметров read_buffer_docs и read_buffer_hits . Также есть опция preopen, которая позволяет контролировать количество файлов, открываемых демоном при запуске.

В режиме доступа к mmap поисковый демон просто отображает файл индекса в память с помощью системного вызова mmap (2), а ОС самостоятельно кэширует содержимое файла. Параметры read_buffer_docs и read_buffer_hits не действуют для соответствующих файлов в этом режиме. Этот читатель может быть использован для скалярных (междунар, поплавка, логическое значение, метки времени) атрибуты, вар длины (строка, MVA, JSON) атрибуты, списки документов и ключевых слов позиций, то есть spa, spb, spd и sppфайлов.

mmapЧитатель может также блокировать индексные данные в памяти через mlock (2) привилегированный вызов , который предотвращает подкачку из кэшированных данных на диск операционной системы.

Чтобы контролировать, какой режим доступа будет использоваться , доступны access_plain_attrs , параметры access_blob_attrs , access_doclists и access_hitlists со следующими значениями:

  • file демон читает индексный файл с диска с поиском + чтением, используя внутренние буферы при доступе к файлу
  • mmap Демон отображает индексный файл в память, а ОС кэширует его содержимое при доступе к файлу.
  • mmap_preread демон отображает файл индекса в память, а фоновый поток читает его один раз, чтобы прогреть кеш
  • mlock демон отображает индексный файл в память, а затем выполняет системный вызов mlock для кэширования содержимого файла и блокировки его в памяти, чтобы предотвратить его выгрузку

Также есть опция командной строки searchd, --force-prereadкоторая инструктирует демона дождаться чтения файлов атрибутов, прежде чем начинать принимать входящие соединения. Запуск демона с этой опцией позволяет убедиться, что все отображенные индексные файлы будут «подогреты», касаясь каждой страницы карт. ОС, в свою очередь, обычно старается хранить все «теплые» данные в кеше диска, обеспечивая максимальную производительность.

Рекомендации:

  • Если производительность поиска очень важна и у вас достаточно памяти - используйте mlock для атрибутов и mmap для списков / списков совпадений. Имейте в виду, что mlock - это привилегированный системный вызов, и пользователь, выполняющий searchd, должен иметь достаточно привилегий. Читайте здесь для деталей
  • Если вы не можете позволить себе более низкую производительность на старте и готовы ждать дольше на старте, пока он не прогреется - используйте –force-preread
  • Если вы хотите, чтобы searchd мог перезапуститься быстрее - оставайтесь с mmap_preread
  • Если вы хотите сэкономить ОЗУ - не используйте mlock, тогда ваша ОС решит, что должно быть в памяти в любой момент времени, в зависимости от того, что чаще читается с диска.
  • Если производительность поиска не имеет значения, и вы хотите сэкономить максимальный объем оперативной памяти - используйте access_doclists / access_hitlists = file и access_plain_attrs / access_blob_attrs = mmap

Режим по умолчанию состоит в том, чтобы отображать и предварительно считывать атрибуты и получать доступ к спискам / спискам попаданий непосредственно с диска, что обеспечивает приличную производительность поиска, оптимальное использование памяти и более быстрый перезапуск searchd в большинстве случаев.

Операции с индексами

В режиме RT поддерживаемые индексы (RT, PQ и распределенные) можно создавать / удалять с помощью синтаксиса create table / синтаксиса drop table [if exists] .

В обычном режиме в конфигурации можно объявить индексы percolate и template, и они будут созданы (с пустыми данными) при запуске демона.

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

Загрузка или удаление индексов

Этот раздел предназначен для простого режима .

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

Сигнал hup может быть использован для того, чтобы демон перезагрузил конфигурацию. Таким образом, новые индексы могут быть загружены или существующие индексы могут быть отброшены во время работы демона. Изменение типа индекса, например, с шаблона на режим реального времени, также можно выполнить во время перезагрузки конфигурации.

В качестве альтернативы сигнализации hup для демона searchd можно использовать команду reload indexes SphinxQL.

Обновление простого индекса, уже загруженного демоном, требует запуска индексатора с параметром –rotate . В этом случае создается новая версия обычного индекса, и когда он готов, hup отправляется демону, который загружает новую версию индекса в память и удаляет старую.

Изменение индекса

Схема индекса может быть изменена на лету в случае атрибута. Однако полнотекстовые поля требуют пересоздания индекса.

Изменение настроек токенизации требует переделки в случае простых индексов. Для индексов в реальном времени их можно создавать на лету с помощью alter reconfigure, но они будут влиять только на новый контент, добавляемый в индекс, так как пока невозможно повторно токенизировать уже проиндексированные тексты.

Некоторые параметры, такие как access_plain_attrs , которые никак не влияют на индекс, не требуют перестроения индекса, только перезагрузки.

Типы данных

В Manticore Search поддерживаются следующие типы данных:

Идентификатор документа

Идентификатор документа в индексе. Идентификаторы документов должны быть уникальными 64-разрядными целыми числами с положительной подписью . Идентификаторы документов неявны и не имеют декларации. Операция обновления запрещена для идентификаторов документов.

Текст

Один или несколько текстовых столбцов образуют полнотекстовую часть индекса. Текст передается через конвейер анализатора, который преобразует текст в слова, применяет преобразования морфологии и т. д. Полнотекстовые поля могут использоваться только в предложении match () и не могут использоваться для сортировки или агрегирования. Слова хранятся в перевернутом индексе вместе со ссылками на поля, которым они принадлежат, и позициями в поле. Это позволяет искать слово внутри каждого поля и использовать расширенные операторы, такие как близость. По умолчанию исходный текст полей индексируется и сохраняется. До 3.3.0 тексты могли быть только проиндексированы. Можно выбрать не сохранять исходные тексты для уменьшения размера индекса и размера результирующего набора.

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

Строка

В отличие от полнотекстовых полей строковые атрибуты сохраняются по мере их поступления и не могут использоваться в полнотекстовом поиске. Вместо этого они возвращаются в результатах, их можно использовать в предложении where для литерального сравнения или фильтрации regex, и их можно использовать для сортировки и агрегирования. В общем, рекомендуется не хранить большие тексты в строковых атрибутах, а использовать строковые атрибуты для метаданных, таких как имена, заголовки, теги, ключи. Строковые атрибуты хранятся в компоненте blob-объектов вместе с атрибутами MVAs и JSON, для которых можно задать способ загрузки в память (см. Индексные файлы ).

Целое число

Целочисленный тип допускает 32-битные целые числа без знака . Целые числа могут быть сохранены в более коротких размерах, чем 32-битные, указав количество бит. Например, если мы хотим сохранить числовое значение, которое, как мы знаем, не будет больше 8, целое число может быть определено как

sql_attr_uint = myattr:3

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

Big Integer

Большие целые числа являются 64-битовыми подписанными целыми числами.

Timestamps

Отметка времени позволяет представить отметку времени UNIX, которая хранится в виде 32-разрядного целого числа. Для меток времени доступно семейство функций даты и времени .

JSON

Позволяет хранить объекты JSON для данных без схемы. Свойства JSON можно использовать в большинстве операций, а специальные функции, такие как all () , any () , greatest () , least () и indexof (), позволяют обходить массивы свойств.

Свойства текста обрабатываются так же, как строки, поэтому их нельзя использовать в выражениях полнотекстовых совпадений, но можно использовать такие строковые функции, как regex .

В случае свойств JSON принудительное приведение типа данных должно быть приведено в некоторых ситуациях для надлежащей функциональности. Например, в случае значений с плавающей запятой double () должен использоваться для правильной сортировки:

SELECT * FROM myindex ORDER BY DOUBLE (myjson.myfloat) DESC

JSON-объекты, а также их свойства могут быть проверены на NULL с помощью оператора IS (NOT) NULL.

Атрибуты JSON хранятся в компоненте blob вместе со строковыми атрибутами и атрибутами MVA (см. Индексные файлы ).

Многозначное целое число

Это специальный тип, который позволяет хранить списки переменной длины из 32-разрядных целых чисел без знака. Его можно использовать для хранения числовых значений «один ко многим», таких как теги, категории продуктов, свойства. Поддерживает фильтрацию и агрегацию, но не сортировку. Фильтрация может быть выполнена из условия, которое требует прохождения хотя бы одного элемента (используя any ()) или всех (используя all () ). Информация как наименьший или наибольший элемент и длина списка могут быть извлечены.

Атрибуты MVA хранятся в компоненте blob вместе со строковыми и JSON-атрибутами (см. Индексные файлы ).

Многозначное большое целое число

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

Полнотекстовые поля

Полнотекстовые поля (или просто поля для краткости) - это текстовые документы, которые индексируются Manticore и могут (быстро) искать по ключевым словам.

Поля имеют имена, и вы можете ограничить свои поиски одним полем (например, поиск только по «заголовку») или подмножеством полей (например, только «заголовком» и «абстрактным»). Формат индекса Manticore обычно поддерживает до 256 полей.

Текст, который вы отправляете в Manticore, обрабатывается, и из этого текста создается полнотекстовый индекс (специальная структура данных, позволяющая осуществлять быстрый поиск по ключевому слову). До поиска Manticore 3.2 исходное содержимое полей отбрасывается, и восстановить его полностью невозможно . В более новых версиях исходный контент может быть дополнительно сохранен в индексе.

Атрибуты

Атрибуты - это дополнительные значения, связанные с каждым документом, которые можно использовать для выполнения дополнительной фильтрации и сортировки во время поиска.

Часто желательно дополнительно обрабатывать результаты полнотекстового поиска, основываясь не только на совпадении идентификатора документа и его ранга, но и на ряде других значений для каждого документа. Например, может потребоваться отсортировать результаты поиска новостей по дате, а затем по релевантности, или выполнить поиск по продуктам в пределах указанного ценового диапазона, или ограничить поиск в блоге сообщениями, сделанными выбранными пользователями, или сгруппировать результаты по месяцам. Для этого Manticore позволяет прикрепить ряд дополнительных атрибутов к каждому документу и сохранить их значения в полнотекстовом индексе. Затем можно использовать сохраненные значения для фильтрации, сортировки или группировки полнотекстовых совпадений.

Атрибуты, в отличие от полей, не полнотекстовые. Они хранятся в индексе, но невозможно найти их как полнотекстовые, и попытка сделать это приводит к ошибке.

Например, невозможно использовать выражение расширенного режима сопоставления для сопоставления документов, где столбец равен 1, если столбец является атрибутом, и это все еще верно, даже если числовые цифры обычно индексируются.@column 1

Атрибуты могут использоваться для фильтрации, однако, для ограничения возвращаемых строк, а также для сортировки или группировки результатов ; вполне возможно отсортировать результаты исключительно на основе атрибутов и игнорировать инструменты релевантности поиска. Кроме того, атрибуты возвращаются из демона поиска, а индексированный текст - нет.

Хорошим примером атрибутов будет таблица сообщений на форуме. Предположим, что только полям заголовка и содержимого необходимо выполнять полнотекстовый поиск, но иногда необходимо также ограничить поиск определенным автором или подфорумом (т. е. Искать только те строки, которые имеют некоторые конкретные значения author_id или forum_id столбцы в таблице SQL); или сортировать совпадения по столбцу post_date; или сгруппировать соответствующие сообщения по месяцу post_date и рассчитать количество совпадений для каждой группы.

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

MVA (многозначные атрибуты)

MVAs, или многозначные атрибуты, являются важным специальным типом атрибутов для каждого документа в Manticore. MVAs позволяют вам прикреплять наборы числовых значений к каждому документу. Это полезно для реализации тегов статей, категорий товаров и т. д. Поддерживается фильтрация и группировка (но не сортировка) атрибутов MVA.

Значения MVA могут быть 32-разрядными целыми числами без знака (unsigned integer) или 64-разрядными целыми числами со знаком (bigint).

Размер набора не ограничен, вы можете иметь произвольное количество значений, прикрепленных к каждому документу, если позволяет ОЗУ ( .spbфайл, содержащий значения MVA, будет предварительно кэшироваться в ОЗУ searchd). Исходные данные могут быть взяты либо из отдельного запроса, либо из поля документа; см. тип источника в sql_attr_multi . В первом случае запрос должен будет вернуть пары идентификаторов документов и значений MVA, во втором - поле будет проанализировано для целочисленных значений. Нет абсолютно никаких требований к порядку входящих данных; значения будут автоматически сгруппированы по идентификатору документа (и внутренне отсортированы по одному и тому же идентификатору) во время индексации в любом случае.

При фильтрации документ будет соответствовать фильтру по атрибуту MVA, если таковой имеется.из значений удовлетворяют условию фильтрации. (Следовательно, документы, которые проходят через фильтры исключения, не будут содержать никаких запрещенных значений.) При группировании по атрибуту MVA документ будет содержать столько групп, сколько разных значений MVA связано с этим документом. Например, если коллекция содержит ровно 1 документ, имеющий MVA «тег» со значениями 5, 7 и 11, группировка по «тегу» приведет к созданию 3 групп с «count (*)», равным 1, и «groupby ()» ключевые значения 5, 7 и 11 соответственно. Также обратите внимание, что группировка по MVA может привести к дублированию документов в наборе результатов: поскольку каждый документ может участвовать во многих группах, его можно выбрать как лучший в нескольких группах, что приведет к дублированию идентификаторов. PHP API исторически использует упорядоченный хэш идентификатора документа для результирующих строк; так что вам также нужно будет использовать SetArrayResult () для использования группирования на MVA с PHP API.

Ограничения на исходные данные

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

Все документы должны быть уникальными подписанными позитивными ненулевыми 64-битными цифрами.

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

Источники данных

Индексируемые данные обычно могут поступать из самых разных источников: базы данных SQL, текстовые файлы, файлы HTML, почтовые ящики и т. Д. С точки зрения Manticore, данные, которые он индексирует, представляют собой набор структурированных документов , каждый из которых имеет одинаковый набор полей и атрибутов . Это похоже на SQL, где каждая строка будет соответствовать документу, а каждый столбец - полю или атрибуту.

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

На момент написания этой статьи были встроенные драйверы для MySQL, PostgreSQL, MS SQL (в Windows) и ODBC. Существует также универсальный драйвер с именем xmlpipe2, который запускает указанную команду и считывает данные из нее stdout. См. Раздел источника данных xmlpipe2 для описания формата. Источник данных tsvpipe (Tab Separated Values) и csvpipe (Comma Separated Values) также доступен и описан в источнике данных TSV / CSV .

Для каждого индекса может быть сколько угодно источников. Они будут последовательно обрабатываться в том же порядке, который был указан в определении индекса. Все документы, поступающие из этих источников, будут объединены, как если бы они поступали из одного источника.

Источники данных SQL (MySQL, PostgreSQL)

Со всеми драйверами SQL индексирование обычно работает следующим образом.

  • установлено соединение с базой данных;
  • предварительный запрос (см. sql_query_pre ) выполняется для выполнения любых необходимых начальных настроек, таких как настройка кодирования для каждого соединения с MySQL;
  • основной запрос (см. sql_query ) выполняется, а возвращаемые строки индексируются;
  • post-query (см. sql_query_post ) выполняется для выполнения любой необходимой очистки;
  • подключение к базе данных закрыто;
  • индексатор выполняет этап сортировки (чтобы быть педантичным, специфическая для типа индекса пост-обработка);
  • вновь установлено соединение с базой данных;
  • пост-индексный запрос (см. sql_query_post_index ) выполняется для выполнения любой необходимой окончательной очистки;
  • подключение к базе данных снова закрыто.

Большинство параметров, таких как пользователь базы данных / хост / пароль, просты. Тем не менее, есть несколько тонких вещей, которые обсуждаются здесь более подробно.

Ранжированные запросы

Основной запрос, который должен извлечь все документы, может наложить блокировку чтения на всю таблицу и остановить параллельные запросы (например, insert в таблицу MyISAM), потратить много памяти для набора результатов и т. д. Чтобы избежать этого, Manticore поддерживает так называемые ранжированные запросы . При использовании ранжированных запросов Manticore сначала извлекает минимальные и максимальные идентификаторы документов из таблицы, а затем подставляет различные интервалы идентификаторов в основной текст запроса и запускает измененный запрос для получения другого фрагмента документов.

sql_query_post против sql_query_post_index

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

Источник данных xmlpipe2

xmlpipe2 позволяет передавать произвольные полнотекстовые и атрибутивные данные в Manticore в еще одном пользовательском формате XML. Это также позволяет указать схему (т. е. Набор полей и атрибутов) либо в самом потоке XML, либо в настройках источника.

При индексации источника xmlpipe2 indexer запускает данную команду, открывает канал для своего стандартного вывода и ожидает правильно сформированный поток XML. Вот пример потока данных:

<?xml version="1.0" encoding="utf-8"?>
<sphinx:docset>

<sphinx:schema>
<sphinx:field name="subject"/>
<sphinx:field name="content"/>
<sphinx:attr name="published" type="timestamp"/>
<sphinx:attr name="author_id" type="int" bits="16" default="1"/>
</sphinx:schema>

<sphinx:document id="1234">
<content>this is the main content <![CDATA[[and this <cdata> entry
must be handled properly by xml parser lib]]></content>
<published>1012325463</published>
<subject>note how field/attr tags can be
in <b> class="red">randomized</b> order</subject>
<misc>some undeclared element</misc>
</sphinx:document>

<sphinx:document id="1235">
<subject>another subject</subject>
<content>here comes another document, and i am given to understand,
that in-document field order must not matter, sir</content>
<published>1012325467</published>
</sphinx:document>

<!-- ... even more sphinx:document entries here ... -->

<sphinx:killlist>
<id>1234</id>
<id>4567</id>
</sphinx:killlist>

</sphinx:docset>

Произвольные поля и атрибуты разрешены. Они также могут появляться в потоке в произвольном порядке в каждом документе; заказ игнорируется. Существует ограничение на максимальную длину поля; поля, длина которых превышает 2 МБ, будут усечены до 2 МБ (этот предел можно изменить в источнике).

Схема, т.е. Полный список полей и атрибутов должен быть объявлен до того, как любой документ может быть проанализирован. Это можно сделать либо в файле конфигурации, используя xmlpipe_fieldи xmlpipe_attr_XXX настройки, либо прямо в потоке, используя элемент <sphinx: schema>. <sphinx: схема> является необязательной. Он допускается только как самый первый вложенный элемент в <sphinx: docset>. Если определение схемы в потоке отсутствует, будут использованы параметры из файла конфигурации. В противном случае настройки потока имеют приоритет.

Неизвестные теги (которые не были объявлены ни как поля, ни как атрибуты) будут игнорироваться с предупреждением. В приведенном выше примере <misc> будет игнорироваться. Все встроенные теги и их атрибуты (такие как ** в <subject> в примере выше) будут игнорироваться.

Поддержка кодирования входящего потока зависит от того iconv, установлен ли он в системе. xmlpipe2 анализируется с использованием libexpatсинтаксического анализатора, который изначально распознает US-ASCII, ISO-8859-1, UTF-8 и несколько вариантов UTF-16. configureСкрипт Manticore также проверяет libiconv наличие и использует его для обработки других кодировок. libexpatтакже соблюдает требование использовать кодировку UTF-8 на стороне Manticore, потому что проанализированные данные, которые он возвращает, всегда находятся в UTF-8.

Источник данных TSV / CSV

Это самый простой способ передачи данных в индексатор. Он был создан из-за ограничений xmlpipe2. А именно, индексатор должен сопоставить каждый атрибут и тег поля в XML-файле с соответствующим элементом схемы. Это отображение требует некоторого времени. Время увеличивается с увеличением количества полей и атрибутов в схеме. В tsvpipe такой проблемы нет, потому что каждое поле и атрибут - это определенный столбец в файле TSV. Так, в некоторых случаях tsvpipe может работать немного быстрее, чем xmlpipe2.

Первый столбец в файле TSVCSV должен быть идентификатором документа. Остальные должны отражать объявление полей и атрибутов в определении схемы.

Разница между tsvpipe и csvpipe заключается в правилах разделения и цитирования. tsvpipe имеет символ табуляции как жесткий разделитель и не имеет правил цитирования. csvpipe имеет опцию csvpipe_delimiter для разделителя со значением по умолчанию ',', а также имеет правила цитирования, такие как:

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

tsvpipe и csvpipe имеют те же поля и атрибуты объявления атрибута, что и xmlpipe.

Обновление индекса в реальном времени

Существует два основных подхода к поддержанию содержимого полнотекстового индекса в актуальном состоянии. Однако обратите внимание, что оба этих подхода имеют дело с задачей обновления полнотекстовых данных , а не обновления атрибутов (которые уже поддерживаются, для получения подробной информации обратитесь к описанию вызова API UpdateAttributes ).

Во-первых, вы можете использовать дисковые индексы, разбивать их вручную и часто перестраивать только меньшие разделы (так называемые «дельты»). Минимизируя размер перестроения, вы можете уменьшить среднее отставание индексации до 30-60 секунд. На огромных коллекциях это может быть самым эффективным. Обратитесь к обновлению индекса Delta для деталей.

Во-вторых, использование индексов в реальном времени (RT-индексы для краткости), которые на лету обновляют полнотекстовые данные. Обновления индекса RT могут появляться в результатах поиска через 1-2 миллисекунды, т.е. 0,001-0,002 секунды. Однако RT-индекс менее эффективен для массовой индексации огромных объемов данных. Обратитесь к Индексам в реальном времени для деталей.

Обновления дельта-индекса

Часто встречается ситуация, когда общий набор данных слишком велик, чтобы часто переиндексировать его с нуля, но количество новых записей довольно мало. Пример: форум с 1 000 000 заархивированных сообщений, но только 1000 новых сообщений в день.

В этом случае «живые» (почти в реальном времени) обновления индекса могут быть реализованы с использованием так называемой схемы «main + delta».

Идея состоит в том, чтобы установить два источника и два индекса, с одним «основным» индексом для данных, который изменяется редко (если когда-либо), и одной «дельтой» для новых документов. В приведенном выше примере 1 000 000 заархивированных постов попадут в основной индекс, а вновь добавленные 1 000 постов в день - в дельта-индекс. Дельта-индекс можно затем очень часто переиндексировать, и документы можно сделать доступными для поиска в считанные минуты.

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

Лучшая переменная разделения - это использование столбца меток времени вместо идентификатора, поскольку метки времени могут отслеживать не только новые документы, но и измененные.

Для наборов данных, которые могут иметь измененные или удаленные документы, дельта-индекс должен также предоставить список документов, которые претерпели изменения, чтобы быть подавленными и не использоваться в поисковых запросах. Это достигается с помощью функции, называемой списки убийств. Идентификаторы документов, которые нужно уничтожить, могут быть предоставлены во вспомогательном запросе, определенном sql_query_killlist . Дельта должна указывать индексы, для которых списки уничтожений будут применяться директивой killlist_target . Эффект списка уничтожения является постоянным для целевого индекса, то есть, даже если поиск выполняется без дельта-индекса, подавленные документы не будут отображаться в результатах поиска.

Обратите внимание, как мы переопределяем sql_query_preисточник дельты. Нам нужно явно иметь это переопределение. В противном случае replace запрос будет выполняться и при индексации дельта-источника, что приведет к его аннулированию. Однако когда мы в первый раз выдаем директиву в унаследованном источнике, она удаляет все унаследованные значения, поэтому настройка кодировки также теряется. Так что sql_query_pre в дельте не может быть просто пусто; и нам нужно еще раз явно выполнить запрос на установку кодировки.

Индекс слияния

Объединение двух существующих индексов может быть более эффективным, чем индексирование данных с нуля, и в некоторых случаях желательно (например, объединение индексов main и delta вместо простого переиндексации main в схеме разбиения main + delta). Так что indexerесть возможность сделать это. Слияние индексов обычно быстрее, чем переиндексация, но все еще не происходит мгновенно для огромных индексов. По сути, ему нужно будет прочитать содержимое обоих индексов один раз и записать результат один раз. Например, объединение индекса 100 ГБ и 1 ГБ приведет к 202 ГБ ввода-вывода (но это, вероятно, все еще меньше, чем требуется для индексации с нуля).

Основной синтаксис команды следующий:

indexer --merge DSTINDEX SRCINDEX [--rotate]

Будет затронут только индекс dstindex: содержимое srcindex будет включено в него. --rotate. Переключатель потребуется, если dstindex уже обслуживается searchd. Первоначально разработанный шаблон использования состоит в том, чтобы объединить меньшее обновление из srcindex в dstindex. Таким образом, при объединении атрибутов значения из srcindex выиграют, если встретятся повторяющиеся идентификаторы документов. Однако обратите внимание, что «старые» ключевые слова не будут автоматически удаляться в таких случаях. Например, если есть ключевое слово «old», связанное с документом 123 в dstindex, и ключевое слово «new», связанное с ним в srcindex, документ 123 будет найден обоими ключевыми словами после слияния. Вы можете предоставить явное условие для удаления документов из dstindex, чтобы смягчить это; соответствующий переключатель --merge-dst-range:

indexer --merge main delta --merge-dst-range deleted 0 0

Этот переключатель позволяет применять фильтры к целевому индексу вместе со слиянием. Там может быть несколько фильтров; все их условия должны быть выполнены, чтобы включить документ в итоговый объединенный индекс. В приведенном выше примере фильтр пропускает только те записи, где «удалено» равно 0, удаляя все записи, помеченные как удаленные (например, с помощью вызова UpdateAttributes () ).

Manticore Search и Sphinx Search

Manticore Search был создан на основе проекта Sphinx Search. Ниже представлена их сравнительная таблица

Manticore Search Sphinx Search
Основное
Открытый исходный код Да Нет, окрытый исходный код имеют только старые версии
Лицензия GPLv2 Delayed FOSS, Commercial
Производительность До 2 раз выше
Стабильность Выше (основано на отзывах клиентов мигрировавших на Manticore со Sphinx 2/3)
Известные крэши или критические баги (начиная с 2019) Всего - 118, Актуальных- 29, Исправленных - 89 Всего - 23 , Актуальных - 23 , Исправленных - 0
Количество релизов (начиная с 2019) 11 1
Последний релиз 3.4.2 (10 апреля 2020) 3.2.1 (31 января 2020)
Функционал
Многопоточные Real-time индексы Да Нет
Источники для индексации MySQL, PostgreSQL, MSSQL, XML , CSV/TSV, ODBC MySQL, PostgreSQL, MSSQL, XML, CSV/TSV, ODBC
Типы индексов Обычный (plain), Real-time, шаблоны (template), распределённый (distributed), обратный (percolate) Обычный (plain), Real-time, шаблоны (template), распределённый (distributed)
Зеркалирование и load balancing Да Да
Обратный поиск (Percolate) Да Нет
Репликация Да Нет
Морфология Автоматическая токенизация большинства языков. Стоп-слова для 50 языков. Сегментация Китайского. 25 стеммеров. Лемматизаторы для 3 языков. По умолчанию токенизация только русского/английского. Лемматизаторы для 3 языков. 15 стеммеров.
Хранилище документов Да Да
Вторичный индекс Нет Да
OR в WHERE Да Нет
Больше строковых функций Да Нет
Конвертация индексов из Manticore / Sphinx v2 Да Нет
Неблокирующая ротация индексов Да Нет
Умная ротация plain индексов Да Нет
Безопасность: поддержка https Да Нет
EXPLAIN QUERY Да Нет
Поддержка сообщества и сервисы
Бесплатный аудит Да Нет
Форум Да Да
Публичный чат Slack Нет
Багтрекер Github Mantis
Принятые pull-реквесты 9 0
Публикации в 2019 36 1
Интерактивные курсы Да Нет
Интеграции
SphinxSE Да Да
MySQL/MariaDB FEDERATED engine Да Нет
ProxySQL Да Нет
Интерфейсы
SphinxQL Да Да
Binary API Да Да
JSON через HTTP Да Базовый, только реализация поиска
Клиенты
PHP Oфициальный Oфициальный, но не поддерживается
Perl Неофициальный Oфициальный, но не поддерживается
Java Oфициальный Oфициальный, но не поддерживается
.NET Неофициальный От сообщества
Ruby Oфициальный Oфициальный, но не поддерживается
Python Oфициальный Oфициальный, но не поддерживается
C++ Oфициальный Oфициальный, но не поддерживается
Go Официальный Нет
Пакеты
Linux Пакеты для Ubuntu, Debian, RHEL/Centos 6/7/8 Архив
Windows Архив Архив
MacOS Архив, Homebrew Архив
FreeBSD Нет Архив
Docker Да Нет официального образа
Открытый исходный код Да Нет
Поддерживаемый YUM репозиторий Да Нет[Источник 3]

Источники

  1. Про Manticore Search // Manticore Search. URL: https://manticoresearch.com/pro-manticore-search/ (дата обращения: 01.06.2020).
  2. Release notes // Manticore Search's Documentation. URL: https://docs.manticoresearch.com/latest/html/releasenotes.html#version-2-3-3-06-july-2017 (дата обращения: 01.06.2020).
  3. Сравнение Manticore Search и Sphinx Search. URL: https://habr.com/ru/company/pvs-studio/blog/342298/ (дата обращения: 22.06.2020).