Очереди индексирования 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) .

Рисунок 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) .

Рисунок 2. Удаление элементов

Примечание. В следующем списке шагов шаги 1–4 не показаны на рисунке 2, поскольку они аналогичны шагам 1–4 на предыдущей схеме и не входят в сферу применения данного раздела. Шаг 5 не показан, поскольку вызов deleteQueueItems в пустой очереди выходит за рамки этого раздела. Эта диаграмма фокусируется на втором обходе.

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

   Примечание. Соединитель может назначить метку очереди, используя поле queue элемента, элементу во время операции item.push или item.index . Эту метку можно изменить всякий раз, когда элемент перезагружается или переиндексируется.

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.push , не сохраняются вместе с элементом. Эти элементы используются только для определения того, был ли элемент изменен.

Items.poll

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

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

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