Начиная с версии 3.2.0, Manticore Search представил новую функцию - Хранение Документов.

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

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

Существуют также некоторые сценарии, когда оригинальные данные не находятся в традиционной базе данных, и извлечение оригинальных текстов из данных может быть медленным во время запроса. Требование хранить эти данные в базе данных может рассматриваться как нежелательное, и единственной причиной использования базы данных, чтобы компенсировать неспособность поискового движка хранить оригинальное содержимое. Эти сценарии могут быть:

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

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

Теперь возможно хранить оригинальные тексты и возвращать их обратно в результатах.

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

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

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

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

Использование

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

index myindex {
   type     = rt
   path     = /path/to/myindex
   rt_field  = title
   rt_field = short_description
   rt_field = long_description
   rt_attr_string = title
   rt_attr_uint   = group_id
   stored_fields  = short_description, long_description
}

Без сохраненных полей результат будет выглядеть так:

mysql> SELECT * FROM myindex WHERE ....\G
*************************** 1. row ***************************
      id: 11
   title: Заголовок здесь
group_id:100
*************************** 2. row ***************************
...

С сохраненными полями:

mysql> SELECT * FROM myindex WHERE ....\G
*************************** 1. row ***************************
               id: 11
            title: Заголовок здесь
short_description: Краткое текстовое описание
здесь
 long_description: Длинное текстовое описание
можно найти здесь
         group_id:100
*************************** 2. row ***************************
...

Сравнение между индексом с и без хранения документов можно увидеть в нашем курсе по docstore .

Расширенная настройка

Тексты хранятся в отдельном файле на диске. По умолчанию они сжимаются с использованием алгоритма lz4. Доступен альтернативный алгоритм lz4hc, или сжатие может быть отключено (’none’) с помощью настройки директивы ‘docstore_compression’. Для алгоритма ’lz4hc’ уровень сжатия можно настраивать с помощью директивы индекса docstore_compression_level, которая может принимать значения от 1 до 12 (по умолчанию 9). Тексты сжимаются на диске блоками. Размер блока можно настроить с помощью директивы docstore_block_size. Значение по умолчанию составляет 16k. Увеличение размера блока улучшит коэффициент сжатия и сэкономит больше места на диске, тогда как уменьшение размера блока должно улучшить скорость доступа.

Когда поиск требует текст из хранилища, блок, содержащий его, считывается с диска и распаковывается. Поскольку возможно, что блок содержит тексты из нескольких документов, распакованные блоки могут кэшироваться в памяти. По умолчанию используется кэш размером 16 МБ на уровне демона. Размер кэша можно изменять с помощью настройки docstore_cache_size демона searchd.

Различия между строковыми атрибутами

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

Строковые атрибуты хранятся в блоб-компоненте индекса Manticore Search 3, который также хранит JSON и MVA атрибуты. Чтение из блоб-компонента управляется с помощью mmap() и может оставаться на диске и считываться по мере необходимости, читаться и загружаться полностью при загрузке индекса или считываться, загружаться и блокироваться в памяти. Тексты в строковых атрибутах хранятся в несжатом виде. Если тексты, сохраненные таким образом, длинные (например, описания, содержимое статей), они могут занять много дискового пространства и также увеличат память, используемую блоб-компонентом документа. Для индекса, который ранее не помещался полностью в ОЗУ, добавление длинных текстов в качестве строковых атрибутов означает меньше атрибутов переменной длины (строковые, JSON, MVA), которые могут быть кэшированы в ОЗУ, что приведет к менее желательной производительности. Блокировка в памяти блоб-компонента (access_blob_attrs=mlock) может быть невозможна из-за увеличенного размера. Строковые атрибуты следует использовать для коротких текстов, для которых ожидается выполнение не полнотекстовой фильтрации, группировки и сортировки, помимо простого извлечения.

С другой стороны, хранимые поля представляют собой отдельный компонент. Тексты читаются только с диска, и если ОЗУ доступна, docstore_cache_size можно установить на высокие значения (ГБ), чтобы кешировать хранимые поля в ОЗУ. Кроме того, хранимые поля по умолчанию сжимаются, занимая меньше места на диске, чем строковые атрибуты. Также есть случаи, когда тексты необходимо хранить в индексе, и они используются только на выходе и никогда не используются для фильтрации/сортировки/группировки. С точки зрения управления ресурсами, иметь их в блобе не оптимально. Примерами таких строк могут быть коды продуктов или UUID (которые, как предполагается, уникальные, и сортировка по ним не имеет большого смысла). Перемещение их в хранимые поля уменьшит размер блоба, что означает меньшее использование ОЗУ, более быструю загрузку при запуске и, в зависимости от ситуации, позволение на блокировку. Одной из “проблем”, которая может возникнуть здесь, является то, что новые поля могут играть роль в полнотекстовых совпадениях, которые не ищут в конкретных полях, поэтому будет неплохо использовать оператор поиска игнорирования полей , чтобы исключить их из поиска.