Manticore Search позволяет получать данные из баз данных с использованием специализированных драйверов или ODBC. Текущие драйверы включают:

• mysql - для баз данных MySQL/MariaDB/Percona MySQL
• pgsql - для базы данных PostgreSQL
• mssql - для базы данных Microsoft SQL
• odbc - для любой базы данных, которая принимает подключения с использованием ODBC

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

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

Хост сервера базы данных для подключения. Обратите внимание, что клиентская библиотека MySQL выбирает, подключаться через TCP/IP или через UNIX-сокет, на основе имени хоста. В частности, "localhost" заставит использовать UNIX-сокет (это режим по умолчанию и, как правило, рекомендуемый), а "127.0.0.1" заставит использовать TCP/IP.

IP-порт сервера для подключения. Для mysql по умолчанию используется 3306, а для pgsql — 5432.

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

Имя пользователя, используемое для подключения.

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

Имя UNIX-сокета для подключения к локальным серверам баз данных. Обратите внимание, что фактическое использование этого значения зависит от настройки sql_host.

sql_sock = /var/lib/mysql/mysql.sock

Флаги подключения клиента MySQL. Необязательный параметр, значение по умолчанию — 0 (не устанавливать никаких флагов).

Этот параметр должен содержать целочисленное значение, представляющее сумму флагов. Значение будет передано в mysql_real_connect() как есть. Флаги перечислены в include-файле mysql_com.h. Флаги, представляющие особый интерес с точки зрения индексации, с их соответствующими значениями, следующие:

• CLIENT_COMPRESS = 32; может использовать протокол сжатия
• CLIENT_SSL = 2048; переключиться на SSL после рукопожатия
• CLIENT_SECURE_CONNECTION = 32768; новая аутентификация 4.1 Например, можно указать 2080 (2048+32) для использования как сжатия, так и SSL, или 32768 для использования только новой аутентификации. Изначально эта опция была введена, чтобы иметь возможность использовать сжатие, когда индексатор и mysqld находятся на разных хостах. Сжатие на каналах 1 Гбит/с, скорее всего, увеличит время индексации, хотя и уменьшает сетевой трафик, как в теории, так и на практике. Однако включение сжатия на каналах 100 Мбит/с может значительно улучшить время индексации (сообщалось об улучшении до 20-30% от общего времени индексации). Ваши результаты могут отличаться.

mysql_connect_flags = 32 # enable compression

• mysql_ssl_cert — путь к SSL-сертификату
• mysql_ssl_key — путь к файлу SSL-ключа
• mysql_ssl_ca — путь к сертификату CA

unpack_mysqlcompress_maxsize = 1M

Столбцы для распаковки с использованием алгоритма MySQL UNCOMPRESS(). Множественное значение, необязательный параметр, значение по умолчанию — пустой список столбцов.

Столбцы, указанные с помощью этой директивы, будут распакованы индексатором с использованием модифицированного алгоритма zlib, который используется функциями MySQL COMPRESS() и UNCOMPRESS(). При индексации на машине, отличной от базы данных, это позволяет разгрузить базу данных и сэкономить сетевой трафик. Эта функция доступна только если zlib и zlib-devel были доступны во время сборки.

unpack_mysqlcompress = body_compressed
unpack_mysqlcompress = description_compressed

По умолчанию для распаковки данных используется буфер размером 16 МБ. Это можно изменить, установив параметр unpack_mysqlcompress_maxsize.

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

unpack_zlib = col1
unpack_zlib = col2

Столбцы для распаковки с использованием zlib (также известного как deflate, gunzip). Множественное значение, необязательный параметр, значение по умолчанию — пустой список столбцов. Применяется только к типам источников mysql и pgsql.

Столбцы, указанные с помощью этой директивы, будут распакованы indexer с использованием стандартного алгоритма zlib (называемого deflate и также реализованного в gunzip). При индексации на машине, отличной от базы данных, это позволяет разгрузить базу данных и сэкономить сетевой трафик. Эта функция доступна только если zlib и zlib-devel были доступны во время сборки.

Флаг аутентификации Windows для MS SQL. Определяет, использовать ли учетные данные текущей учетной записи Windows для аутентификации при подключении к MS SQL Server.

mssql_winauth = 1

Источники, использующие ODBC, требуют наличия строки DSN (Data Source Name, имя источника данных), которую можно задать с помощью odbc_dsn.

odbc_dsn = Driver={Oracle ODBC Driver};Dbq=myDBName;Uid=myUsername;Pwd=myPassword

Обратите внимание, что формат зависит от используемого конкретного драйвера ODBC.

Для всех SQL-драйверов построение простой таблицы, как правило, происходит следующим образом.

• Устанавливается соединение с базой данных.
• Выполняются запросы sql_query_pre_all для выполнения необходимой начальной настройки, например, установки кодировки на соединение в MySQL. Эти запросы выполняются до всего процесса индексирования, а также после переподключения для индексирования атрибутов MVA и связанных полей.
• Выполняется предварительный запрос sql_query_pre для выполнения необходимой начальной настройки, например, создания временных таблиц или ведения счетчиков. Эти запросы выполняются один раз за весь процесс индексирования.
• Выполняется предварительный запрос sql_query_pre для выполнения необходимой начальной настройки, например, создания временных таблиц или ведения счетчиков. Эти запросы выполняются один раз за весь процесс индексирования.
• Выполняется основной запрос sql_query, результаты которого обрабатываются.
• Выполняется пост-запрос sql_query_post для выполнения необходимой очистки.
• Соединение с базой данных закрывается.
• Индексатор выполняет фазу сортировки (точнее говоря, специфическую для типа таблицы постобработку).
• Соединение с базой данных устанавливается снова.
• Выполняется запрос постобработки sql_query_post_index для выполнения необходимой окончательной очистки.
• Соединение с базой данных снова закрывается.

Пример источника, выбирающего данные из MYSQL:

source mysource {
  type             = mysql
  path             = /path/to/realtime
  sql_host         = localhost
  sql_user         = myuser
  sql_pass         = mypass
  sql_db           = mydb
  sql_query_pre    = SET CHARACTER_SET_RESULTS=utf8
  sql_query_pre    = SET NAMES utf8
  sql_query        =  SELECT id, title, description, category_id  FROM mytable
  sql_query_post   = DROP TABLE view_table
  sql_query_post_index = REPLACE INTO counters ( id, val ) \
    VALUES ( 'max_indexed_id', $maxid )
  sql_attr_uint    = category_id
  sql_field_string = title
 }
table mytable {
  type   = plain
  source = mysource
  path   = /path/to/mytable
  ...
 }

Это запрос, используемый для извлечения документов из SQL-сервера. Может быть объявлен только один sql_query, и его наличие обязательно. См. также Обработка полученных данных

Предварительный запрос выборки или pre-query. Это настройка с множественным значением, необязательная, по умолчанию – пустой список запросов. Предварительные запросы выполняются перед sql_query в том порядке, в каком они указаны в конфигурационном файле. Результаты предварительных запросов игнорируются.

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

Вероятно, наиболее частое использование предварительного запроса – указание кодировки, которую сервер будет использовать для возвращаемых строк. Обратите внимание, что Manticore принимает только текст в кодировке UTF-8. Два специфических для MySQL примера установки кодировки:

sql_query_pre = SET CHARACTER_SET_RESULTS=utf8
sql_query_pre = SET NAMES utf8

Также, специфично для источников MySQL, полезно отключить кэш запросов (только для соединения индексатора) в предварительном запросе, поскольку индексационные запросы все равно часто не будут выполняться повторно, и нет смысла кэшировать их результаты. Это может быть сделано так:

sql_query_pre = SET SESSION query_cache_type=OFF

Пост-запрос выборки. Эта настройка необязательна, значение по умолчанию – пустое.

Этот запрос выполняется сразу после успешного завершения sql_query. Если при выполнении пост-запроса возникают ошибки, они регистрируются как предупреждения, но индексирование не прерывается. Его результирующий набор игнорируется. Обратите внимание, что в момент выполнения этого запроса индексирование еще не завершено, и оно все еще может завершиться ошибкой. Поэтому из этого запроса не следует выполнять постоянные обновления. Например, обновления вспомогательной таблицы, которые перманентно изменяют последний успешно индексированный ID, не должны выполняться из sql_query_post; вместо этого они должны выполняться из запроса sql_query_post_index.

Запрос постобработки. Эта настройка необязательна, значение по умолчанию – пустое.

Этот запрос выполняется, когда индексирование полностью и успешно завершено. Если этот запрос вызывает ошибки, они регистрируются как предупреждения, но индексирование не прерывается. Его результирующий набор игнорируется. В тексте запроса можно использовать макрос $maxid; он будет расширен до максимального ID документа, который был фактически извлечен из базы данных во время индексирования. Если документы не индексировались, $maxid будет расширен до 0.

Пример:

sql_query_post_index = REPLACE INTO counters ( id, val ) \
    VALUES ( 'max_indexed_id', $maxid )

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