Очереди индексирования Google Cloud Search

Connector SDK и API Google Cloud Search позволяют создавать очереди индексирования Cloud Search, используемые для выполнения следующих задач:

  • Поддерживайте состояние каждого документа (статус, значения хеш-функции и т. д.), которое можно использовать для синхронизации вашего индекса с вашим репозиторием.

  • Ведите список элементов, подлежащих индексации, по мере обнаружения в процессе обхода.

  • Расставьте приоритеты элементов в очередях в зависимости от статуса элемента.

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

Очередь — это метка, присвоенная индексированному элементу, например «по умолчанию» для очереди по умолчанию или «B» для очереди B.

Статус и приоритет

Приоритет документа в очереди основан на его коде ItemStatus . Ниже приведены возможные коды ItemStatus в порядке приоритета (от первой обработки до последней):

  • ERROR . В процессе индексирования элемента произошла асинхронная ошибка, и его необходимо повторно проиндексировать.

  • MODIFIED — элемент, который ранее был проиндексирован и с тех пор был изменен в репозитории с момента последней индексации.

  • NEW_ITEM — элемент, который не проиндексирован.

  • ACCEPTED — Документ, который ранее был проиндексирован и не менялся в репозитории с момента последней индексации.

Если два элемента в очереди имеют одинаковый статус, более высокий приоритет отдается элементам, которые находились в очереди дольше всего.

Обзор использования очередей индексирования для индексации нового или измененного элемента

На рис. 1 показаны этапы индексации нового или измененного элемента с использованием очереди индексирования. Эти шаги показывают вызовы REST API. Эквивалентные вызовы SDK см. в разделе Операции с очередью (Connector SDK) .

Обзор индексации Google Cloud Search
Рисунок 1. Шаги индексирования для добавления или обновления элемента

  1. Коннектор контента использует items.push для помещения элементов (метаданных и хеша) в очередь индексирования для установления статуса элемента ( MODIFIED , NEW_ITEM , DELETED ). Конкретно:

    • При отправке соединитель явно включает type push или contentHash .
    • Если соединитель не содержит type , Cloud Search автоматически использует contentHash для определения статуса элемента.
    • Если элемент неизвестен, статус элемента устанавливается на NEW_ITEM .
    • Если элемент существует и значения хеш-функции совпадают, статус сохраняется как ACCEPTED .
    • Если элемент существует и хэши различаются, статус становится MODIFIED .

    Дополнительные сведения о том, как устанавливается статус элемента, см. в примере кода «Обход репозиториев GitHub» в руководстве по началу работы с Cloud Search .

    Обычно push-уведомление связано с процессами обхода контента и/или обнаружения изменений в коннекторе.

  2. Соединитель содержимого использует items.poll для опроса очереди и определения элементов для индексирования. Cloud Search сообщает соединителю, какие элементы больше всего нуждаются в индексировании, сортируя их сначала по коду состояния, а затем по времени нахождения в очереди.

  3. Коннектор извлекает эти элементы из репозитория и формирует запросы API индекса.

  4. Коннектор использует items.index для индексации элементов. Элемент переходит в состояние ACCEPTED только после того, как Cloud Search успешно завершит его обработку.

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

Обзор использования очередей индексации для удаления элемента

Стратегия полного обхода использует процесс с двумя очередями для индексации элементов и обнаружения удалений. На рис. 2 показаны этапы удаления элемента с использованием двух очередей индексации. В частности, на рисунке 2 показан второй обход, выполненный с использованием стратегии полного обхода. Эти шаги используют вызовы REST API. Эквивалентные вызовы SDK см. в разделе Операции с очередью (Connector SDK) .

Обзор индексации Google Cloud Search
Рисунок 2. Удаление элементов

  1. При начальном обходе соединитель содержимого использует items.push для помещения элементов (метаданных и хеша) в очередь индексирования, «очередь A» как NEW_ITEM , поскольку она не существует в очереди. Каждому элементу присваивается метка «А» для «очереди А». Содержимое индексируется в Cloud Search.

  2. Соединитель содержимого использует items.poll для опроса очереди A и определения элементов для индексирования. Cloud Search сообщает соединителю, какие элементы больше всего нуждаются в индексировании, сортируя их сначала по коду состояния, а затем по времени нахождения в очереди.

  3. Коннектор извлекает эти элементы из репозитория и формирует запросы API индекса.

  4. Коннектор использует items.index для индексации элементов. Элемент переходит в состояние ACCEPTED только после того, как Cloud Search успешно завершит его обработку.

  5. Метод deleteQueueItems вызывается в «очереди B». Но ни один элемент не был помещен в очередь B, поэтому ничего нельзя удалить.

  6. При втором полном обходе соединитель контента использует items.push для помещения элементов (метаданных и хеша) в очередь B:

    • При отправке соединитель явно включает type push или contentHash .
    • Если соединитель не содержит type , Cloud Search автоматически использует contentHash для определения статуса элемента.
    • Если элемент неизвестен, статус элемента устанавливается на NEW_ITEM , а метка очереди меняется на «B».
    • Если элемент существует и его хэш-значения совпадают, статус сохраняется как ACCEPTED , а метка очереди меняется на «B».
    • Если элемент существует и хеши различаются, статус становится MODIFIED , а метка очереди меняется на «B».

  7. Соединитель содержимого использует items.poll для опроса очереди и определения элементов для индексирования. Cloud Search сообщает соединителю, какие элементы больше всего нуждаются в индексировании, сортируя их сначала по коду состояния, а затем по времени нахождения в очереди.

  8. Коннектор извлекает эти элементы из репозитория и формирует запросы API индекса.

  9. Коннектор использует items.index для индексации элементов. Элемент переходит в состояние ACCEPTED только после того, как Cloud Search успешно завершит его обработку.

  10. Наконец, в очереди A вызывается deleteQueueItems , чтобы удалить все ранее проиндексированные элементы CCloud Search, которые все еще имеют метку очереди «A».

  11. При последующих полных обходах очередь, используемая для индексации, и очередь, используемая для удаления, меняются местами.

Операции с очередью (Connector SDK)

Content Connector SDK предоставляет операции для отправки элементов в очередь и извлечения элементов из очереди.

Чтобы упаковать и отправить элемент в очередь, используйте класс-построитель pushItems .

Вам не нужно делать ничего особенного, чтобы извлечь элементы из очереди для обработки. Вместо этого SDK автоматически извлекает элементы из очереди в порядке приоритета, используя метод getDoc класса Repository .

Операции с очередью (REST API)

REST API предоставляет следующие два метода для отправки элементов в очередь и извлечения элементов из очереди:

  • Чтобы поместить элемент в очередь, используйте Items.push .
  • Чтобы опросить элементы в очереди, используйте Items.poll .

Вы также можете использовать Items.index для помещения элементов в очередь во время индексации. Элементы, помещаемые в очередь во время индексации, не требуют type , и им автоматически присваивается статус ACCEPTED .

Items.push

Метод Items.push добавляет идентификаторы в очередь. Этот метод можно вызвать с определенным значением type , которое определяет результат операции push. Список значений type см. в поле item.type метода Items.push .

Нажатие нового идентификатора приводит к добавлению новой записи с кодом NEW_ITEM ItemStatus .

Необязательные полезные данные всегда сохраняются, обрабатываются как непрозрачное значение и возвращаются из Items.poll .

Когда элемент опрашивается, он зарезервирован , что означает, что он не может быть возвращен другим вызовом Items.poll . Использование Items.push с type NOT_MODIFIED , REPOSITORY_ERROR или REQUEUE отменяет резервирование опрашиваемых записей. Дополнительную информацию о зарезервированных и незарезервированных записях см. в разделе Items.poll .

Items.push с хешами

API Google Cloud Search поддерживает указание метаданных и хеш-значений контента в запросах Items.index . Вместо указания type метаданные и/или хеш-значения контента можно указать с помощью push-запроса. Очередь индексирования Cloud Search сравнивает предоставленные значения хеш-функции с сохраненными значениями, доступными для элемента в источнике данных. Если не совпадает, эта запись помечается как MODIFIED . Если соответствующий элемент не существует в индексе, то статус — NEW_ITEM .

Items.poll

Метод Items.poll извлекает из очереди записи с наивысшим приоритетом. Запрошенные и возвращенные значения статуса указывают статус(ы) запрошенной приоритетной очереди(й) или статус возвращенных идентификаторов.

По умолчанию могут быть возвращены записи из любого раздела очереди в зависимости от приоритета. Каждая возвращаемая запись зарезервирована и не возвращается другими вызовами Items.poll до тех пор, пока не будет выполнен один из следующих случаев:

  • Время резервирования истекло.
  • Запись снова ставится в очередь Items.index .
  • Items.push вызывается со значением type NOT_MODIFIED , REPOSITORY_ERROR или REQUEUE .