Сервисы индексирования#

Сервис Index Manager#

Сервис управляет процессом создания индексов для списков, содержащих БШ лиц, и выполняет следующие задачи:

формирует задачи для построения индекса;
отправляет задачи во внутреннюю очередь;
извлекает задачи из внутренней очереди и координирует процесс доставки задач для индексирования в сервис Indexer.

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

Фоновые процедуры#

Сервис Index Manager параллельно выполняет два типа фоновых процедур:

процедура планирования;
процедура поиска.

В процедуре планирования Index Manager проверяет, какие наборы списков должны быть проиндексированы, затем создает задачи под уникальным идентификатором "task_id" и помещает их во внутреннюю очередь. Процедура планирования выполняется с периодом (сек), указанным в настройке "planning_period", или с помощью Cron-подобной строки, указываемой в настройке "planning_schedule".

В процедуре поиска Index Manager проверяет статус всех запущенных экземпляров Indexer. Если какой-либо экземпляр Indexer завершил построение индекса, Index Manager обновляет информацию о задаче и отправляет данные для мониторинга. Если какой-либо экземпляр Indexer готов принять задачу, сервис Index Manager извлекает следующую задачу из внутренней очереди, отправляет задачу свободному экземпляру Indexer и обновляет информацию о задаче. Процедура поиска выполняется с периодом (сек), указанным в настройке "lookup_period".

Настройка перестроения и обновления индекса#

Сервис Index Manager отправляет задачи на создание, перестроение и обновление индекса согласно вышеописанным процедурам.

По умолчанию выполняется полное перестроение индекса. При необходимости можно обновить индексы вместо их перестроения. В целях экономии времени и ресурсов сервис Index Manager может учитывать только вновь добавленные или удаленные биометрически шаблоны. В этом случае сервис Indexer не будет перестраивать индексы с нуля. Чтобы установить приоритет обновления вместо перестроения, нужно задать для настройки "rebuild_rules" > "default" значение false, что означает "не перестраивать, а обновлять". По умолчанию выполняется именно перестроение (значение true).

Обновление подразумевает под собой удаление старых и/или добавление новых биометрических шаблонов из/в собранный индекса. Из-за алгоритма индексирования удаление биометрического шаблона из собранного индекса приводит к деградации индекса. Чем больше биометрических шаблонов было удалено, тем хуже качество индекса, что приводит к снижению точности поиска по этому индексу. Настоятельно рекомендуется перестраивать индексы в случае удаления большого количества лиц из исходного набора данных.

Чтобы указать допустимое количество удалений биометрических шаблонов с момента создания индекса, при котором индекс будет перестраиваться с нуля, можно установить соответствующее значение для параметра "rebuild_rules" > "max_removal_for_rebuild". Например, если этот параметр установлен на 10, это означает, что можно удалить до 10 биометрических шаблонов, прежде чем индекс будет перестроен с нуля для обеспечения его эффективности. По умолчанию установлено значение "0", что означает "никогда не перестраивать с нуля". Рекомендуемый ориентир для перестройки индексов — удаление не более 10% от общего объёма биометрических шаблонов.

Хранилище Index Manager#

Вся информация о созданных задачах хранится в БД Redis. Также с помощью механизма Redis Redlock регулируется работа с несколькими экземплярами.

Работа с несколькими экземплярами#

Режим работы с несколькими экземплярами поддерживается автоматическим выбором экземпляра-мастера (основного экземпляра) на основе Redis Redlock.

См. подробную информацию о распределенных блокировках, выполняющихся с помощью Redis: https://redis.io/docs/reference/patterns/distributed-locks/.

Только экземпляр-мастер может выполнять фоновые процедуры планирования и поиска. Остальные экземпляры могут только принимать запросы на единовременное создание индекса, а также выдавать ответы на GET-запросы.

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

LIM_MANAGER_MASTER_LOCK — имя блокировки Redis для экземпляра-мастера сервиса Index Manager. Эта блокировка используется для обеспечения того, чтобы только один экземпляр Index Manager мог выполнять процедуры планирования и поиска. Значение по умолчанию — lim_manager_master.
LIM_MATCHER_CONSUMER — название группы потребителей Redis для запросов на сравнение. Значение по умолчанию — lim_matcher.
LIM_MATCHER_LOCK_PREFIX — префикс для имени блокировки сервиса Indexed Matcher в Redis. Это позволяет избежать возможных конфликтов имен с другими пользователями Redis. Значение по умолчанию — lim_matcher.

Запросы к сервису#

Взаимодействие с сервисом Index Manager осуществляется с помощью HTTP-запросов. Ниже перечислены основные запросы:

"get queue" — позволяет получить список задач и их количество из очереди
"get tasks" — позволяет получить информацию по задачам:
- task_id — идентификатор задачи
- status — статусы: "pending", "indexing", "success", "error"
- create_time — время создания задачи на построение индекса в формате RFC 3339
- start_time — время начала построения индекса в формате RFC 3339
- end_time — время окончания построения индекса в формате RFC 3339
- indexer — адрес сервера, где запущен экземпляр Indexer, который обрабатывает указанную задачу
- error — ошибка, полученная во время построения индекса
- content — обрабатываемый "list_id"
При необходимости можно отфильтровать получаемые задачи.
"create task" — позволяет единоразово создать задачу на построение индекса
"remove tasks" — позволяет удалить задачи. При необходимости можно отфильтровать удаляемые задачи.
"get indexes" — позволяет получить количество индексов, а также следующую информацию по каждому индексу:
- index_id (равен task_id)
- index_type — тип индекса (только список)
- label — обрабатываемый "list_id"
"remove index" — позволяет удалить индекс из хранилища по идентификатору
"remove indexes" - позволяет удалить индексы по политике, задавемой в параметре запроса и принимающий следующие значения:
- all - удалить все индексы
- outdated - удалить только неактуальные индесы, т.е. те, для которых есть более новые индексы (по умолчанию)
"get most relevant indexes" — позволяет получить информацию по наиболее релевантному индексу, т.е. по последнему построенному индексу для списка.

Более подробную информацию о запросах, выполняемых к сервису Index Manager, и другие запросы см. в спецификации OpenAPI.

Сервис Indexer#

Сервис Indexer предназначен для обработки задач, полученных сервисом Index Manager, и выполнения процесса создания индексов.

Запросы к сервису Indexer не предназначены для пользователя. Все запросы, связанные с LUNA Index Module должны выполняться к сервису Index Manager (см. раздел "Запросы к сервису Index Manager").

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

Сервис Indexed Matcher#

Сервис Indexed Matcher загружает наиболее релевантные индексы из хранилища индексов (файловая система) и обрабатывает запросы на сравнение.

При запуске, сервис Indexed Matcher загружает все индексы последней версии из хранилища индексов в память и настраивает потоки Redis на прием сообщений для сравнения для всех меток сравнения, загруженных в хранилище индексов.

Сервис Indexed Matcher всегда проверяет существование списка при запуске, загрузке нового индекса в память и обновлении индекса в памяти. Индекс без существующего списка будет удален из памяти сервиса.

Для ускорения доступа к индексу, можно настроить кэширование индекса в специальную папку в контейнере сервиса Indexed Matcher (по умолчанию кэширование отключено). Кэширование включается с помощью настройки "LIM_MATCHER_CACHE".

Запросы к сервису Indexed Matcher не предназначены для пользователя. Все запросы, связанные с LUNA Index Module должны выполняться к сервису Index Manager (см. раздел "Запросы к сервису Index Manager").

Сервис Indexed Matcher не взаимодействует с другими сервисами LIM. Он только следит за хранилищем и при появлении индексов загружает их в память. Поскольку обработка запросов на сравнение выполняется через потоки Redis, любое количество экземпляров сервиса Indexed Matcher может быть запущено без каких-либо обновлений конфигурации системы. Количество экземпляров сервиса Indexed Matcher должно определяться требованиями к производительности.

Синхронизация меток сравнения в памяти#

Сервис Indexed Matcher синхронизирует метки для сравнения индексов с ключами Redis у себя в памяти. Для всех меток в памяти, сервис устанавливает ключи в следующем формате:

matching_label__<label>__<matcher_id>

Например, matching_label__17cdbe41-c7f1-440b-b9ad-aad93c7176ee__127.0.0.1:5200.

Поле <matcher_id> в ключе метки — это хост и порт экземпляра Indexed Matcher. Хост считывается из переменной окружения VL_LIM_MATCHER_HOST или, если переменная не задается, угадывается с помощью API сокетов операционной системы. Считывание этих ключей из Redis позволяет плагину сравнения получить информацию о том, для каких экземпляров Indexed Matcher были загружены в память конкретные метки индекса.

Устанавливаемый ключ метки для сравнения имеет срок действия (TTL) и истекает, если не будет обновлен снова. Наличие такого ключа в Redis означает, что некоторые из запущенных экземпляров Indexed Matcher могут обрабатывать запросы на сравнение по метке для сравнения.

Перезагрузка индекса#

Для синхронизации индексов в памяти сервиса Indexed Matcher с хранилищем предназначен переодический фоновый процесс, называемый перезагрузкой индекса.

Если индекс исчезает из хранилища, индекс также удаляется из памяти сервиса Indexed Matcher.

Если в хранилище появится новый индекс с новой меткой сравнения, сервис Indexed Matcher попытается загрузить новый индекс в память.

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

Замена индекса с неактуальной версией списка (Индекс 1) на новый (Индекс 3)

Чтобы гарантировать, что определенный индекс может быть перезагружен только одним сервисом Indexed Matcher одновременно, используется механизм Redis Redlock. Если блокировка установлена, более старая версия индекса удаляется из памяти сервиса Indexed Matcher, а более новая загружается.

Если при загрузке индекса возникает проблема, например, нехватка памяти, в логи и мониторинг отправляется соответствующее сообщение.

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

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

Обновление индекса в памяти#

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

Использование данного функционала регулируется настройкой "enabled".

Данная информация описывается для индекса, который уже загружен в память сервиса Indexed Matcher. Индекс в памяти сервиса и индекс в хранилище могут отличаться.

При обновлении индекса в памяти, сервис Indexed Matcher останавливает сравнение по этому индексу, но продолжает принимать новые запросы на сравнение для этого индекса. Благодаря тому, что в индекс в памяти добавляется небольшое количество биометрических шаблонов (не более 10 БШ за 1 раз), процесс сравнения выполняется с минимальным прерыванием. Однако следует учитывать то, что если в список слишком часто вставляются элементы (десятки и сотни добавлений), то это отразится на существенной деградации в скорости работы, вплоть до почти полной остановки процесса сравнения.

Во время обновления индекса, сервис Index Matcher выводит следующую информацию в логи:

Refresh index for: 2d5832ad-8c8f-415f-a0b4-d12d69fabd60
Sync: 5->6, 0->0
Refresh index for: 2d5832ad-8c8f-415f-a0b4-d12d69fabd60 has finished successfully

где:

2d5832ad-8c8f-415f-a0b4-d12d69fabd60 — идентификатор списка;
5->6 — информация о выкачивании пакетов с БШ (1 пакет равен 10 БШ) из базы данных Faces. Здесь 6 — общее количество пакетов, которые необходимо выкачать из БД, а 5 — текущее количество выкачанных пакетов. Таким образом, сообщение 5->6 означает, что синхронизация будет продолжена и будет выкачан еще один пакет.
0->0 — информация об удалении пакетов с БШ (1 пакет равен 10 БШ) из индекса в памяти. Принцип работы аналогичен выкачиванию пакетов из базы данных Faces.

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

Если используется данный функционал, то нет необходимости и не рекомендуется выполнять частые перестроения индекса. Соответственно, рекомендуется увеличить период процедуры планирования (настройка "planning_period"). Однако добавление новых лиц в индекс в памяти происходит медленнее, чем перестроение индекса, поэтому нет смысла использовать данную функцию если в список было добавлено очень большое количество лиц. В таком случае проще заново перестроить индекс.

Открепление лиц от списка не приводит к удалению этих лиц из индекса в памяти. В таком случае биометрические шаблоны помечаются как недоступные для поиска, поэтому индекс сохраняет выделенное для них место для хранения.

См. диаграмму последовательности для обновления индекса в разделе "Диаграмма обновления индекса".

Кэширование индекса#

Можно включить кэширование индекса для ускорения процесса загрузки данных в память сервиса Indexed Matcher. Использование кэширования позволяет не загружать индекс в память из Хранилища, а загружать его из кэшированного каталога в случае непредвиденной перезагрузки сервиса Indexed Matcher.

Кэширование включается при задании промежуточного каталога для хранения и загрузки индексов в настройке "lim_matcher_cache" сервиса Configurator. По умолчанию каталог не указывается, т.е. кэширование отключено.

Промежуточный каталог должен быть расположен в локальной файловой системе (использование таких вещей, как GlusterFS или NFS, может вызвать ошибки). Каждый раз, когда сервис Indexed Matcher перезагружает свои индексы, он пытается очистить каталог кэша, удаляя старое поколение индексов списка. Кэш-система имеет механизм блокировки. В случае нескольких экземпляров сервиса Indexed Matcher, работающих на одном хосте и совместно использующих один и тот же каталог для кэша, блокировка предотвратит загрузку одних и тех же индексов несколько раз. Это означает, что хранилище индексов будет задействовано ровно один раз, когда данные отправляются между хостом сервисов Indexed Matcher и хранилищем.