Files d'attente d'indexation Google Cloud Search

Le SDK Connector et l'API Google Cloud Search permettent de créer des applications Cloud Search Les files d'attente d'indexation servent à effectuer les tâches suivantes:

  • Conservez l'état par document (état, valeurs de hachage, etc.), qui peut être utilisé pour synchroniser votre index avec votre dépôt.

  • Conserver une liste des éléments à indexer tels qu'ils ont été découverts lors du balayage processus.

  • Hiérarchisez les éléments de la file d'attente en fonction de leur état.

  • de conserver des informations d'état supplémentaires pour une intégration efficace, par exemple les points de contrôle, le jeton de modification, etc.

Une file d'attente est un libellé attribué à un élément indexé, tel que "par défaut" pour le file d'attente par défaut ou "B" pour la file d'attente B.

État et priorité

La priorité d'un document dans une file d'attente ItemStatus du code source. Voici les options possibles ItemStatus codes par ordre de priorité (traité de la première à la dernière):

  • ERROR : élément ayant rencontré une erreur asynchrone lors de l'indexation et doit être réindexée.

  • MODIFIED : élément précédemment indexé, mais qui a été modifié depuis depuis la dernière indexation.

  • NEW_ITEM : élément non indexé.

  • ACCEPTED : document précédemment indexé et qui n'a pas été modifié au cours des depuis la dernière indexation.

Lorsque deux éléments d'une file d'attente ont le même état, une priorité plus élevée est attribuée les éléments en file d'attente depuis le plus longtemps.

Présentation de l'utilisation des files d'attente d'indexation pour indexer un élément nouveau ou modifié

La figure 1 illustre les étapes d'indexation d'un élément nouveau ou modifié à l'aide d'une fonction d'indexation file d'attente. Ces étapes présentent les appels d'API REST. Pour les appels de SDK équivalents, Opérations de file d'attente (SDK Connector).

Présentation de l'indexation de Google Cloud Search
Figure 1. Procédure d'indexation pour l'ajout ou la mise à jour d'un élément

  1. Le connecteur de contenu utilise items.push pour placer des éléments (métadonnées et hachage) dans une file d'attente d'indexation afin d'établir leur (MODIFIED, NEW_ITEM, DELETED). Plus précisément:

    • Lors du transfert, le connecteur inclut explicitement une commande type ou contentHash.
    • Si le connecteur n'inclut pas type, Cloud Search utilise automatiquement contentHash pour déterminer l'état de l'élément.
    • Si l'élément est inconnu, son état est défini sur NEW_ITEM.
    • Si l'élément existe et que les valeurs de hachage correspondent, l'état est conservé sur ACCEPTED.
    • Si l'élément existe et que les valeurs de hachage diffèrent, l'état devient MODIFIED.

    Pour en savoir plus sur la manière dont l'état d'un article est établi, consultez les Traverser les dépôts GitHub l'exemple de code Tutoriel de mise en route de Cloud Search

    Généralement, la transmission est associée à un balayage de contenu et/ou à une détection des modifications. dans le connecteur.

  2. Le connecteur de contenu utilise items.poll pour interroger la file d'attente et déterminer les éléments à indexer. Cloud Search indique au connecteur les éléments nécessitant le plus d'indexation, triés d'abord par code d'état, puis en fonction du temps passé en file d'attente.

  3. Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.

  4. Le connecteur utilise items.index pour indexer les éléments. L'élément n'est à l'état ACCEPTED qu'après Cloud Search termine le traitement de l'élément.

Un connecteur peut également supprimer un élément s'il n'existe plus dans le dépôt. ou transférer à nouveau un élément s'il n'a pas été modifié ou s'il existe erreur du dépôt source. Pour en savoir plus sur la suppression d'éléments, consultez les .

Présentation de l'utilisation de files d'attente d'indexation pour supprimer un élément

La stratégie de balayage complet utilise un processus à deux files d'attente pour indexer les éléments et détecter les suppressions. La figure 2 illustre les étapes de suppression d'un élément à l'aide de deux des files d'attente d'indexation. Plus précisément, la figure 2 illustre le deuxième balayage effectué à l'aide d'une stratégie de balayage complet. Ces étapes utilisent des appels d'API REST. Pour équivalents, consultez la section Opérations de file d'attente (SDK Connector).

Présentation de l'indexation de Google Cloud Search
Figure 2. Supprimer des éléments

  1. Lors du balayage initial, le connecteur de contenu utilise items.push pour placer des éléments (métadonnées et hachage) dans une file d'attente d'indexation, la "file d'attente A" en tant que NEW_ITEM, car il n'existe pas dans la file d'attente. Chaque élément se voit attribuer le libellé "A" pour "file d'attente A". Le contenu est indexé dans Cloud Search.

  2. Le connecteur de contenu utilise items.poll pour interroger la file d'attente A afin de déterminer les éléments à indexer. Cloud Search indique au connecteur les éléments nécessitant le plus d'indexation, triés d'abord par code d'état, puis en fonction du temps passé en file d'attente.

  3. Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.

  4. Le connecteur utilise items.index pour indexer les éléments. L'élément n'est à l'état ACCEPTED qu'après Cloud Search termine le traitement de l'élément.

  5. La deleteQueueItems est appelée sur la "file d'attente B". Mais aucun élément n'a été placé dans la file d'attente B. rien ne peut être supprimé.

  6. Lors du deuxième balayage complet, le connecteur de contenu utilise items.push pour placer les éléments (métadonnées et hachage) dans la file d'attente B:

    • Lors du transfert, le connecteur inclut explicitement une commande type ou contentHash.
    • Si le connecteur n'inclut pas type, Cloud Search utilise automatiquement contentHash pour déterminer l'état de l'élément.
    • Si l'élément est inconnu, son état est défini sur NEW_ITEM et la file d'attente le libellé est remplacé par « B ».
    • Si l'élément existe et que les valeurs de hachage correspondent, l'état est conservé sur ACCEPTED. et le libellé de la file d'attente est remplacé par « B ».
    • Si l'élément existe et que les valeurs de hachage diffèrent, l'état passe à MODIFIED et la file d'attente le libellé est remplacé par « B ».

  7. Le connecteur de contenu utilise items.poll pour interroger la file d'attente et déterminer les éléments à indexer. Cloud Search indique au connecteur les éléments nécessitant le plus d'indexation, triés d'abord par code d'état, puis en fonction du temps passé en file d'attente.

  8. Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.

  9. Le connecteur utilise items.index pour indexer les éléments. L'élément n'est à l'état ACCEPTED qu'après Cloud Search termine le traitement de l'élément.

  10. Enfin, deleteQueueItems est appelé sur la file d'attente A pour supprimer tous les éléments CCloud Search précédemment indexés qui ont toujours une file d'attente "A" libellé.

  11. En cas de balayages complets ultérieurs, la file d'attente utilisée pour l'indexation et la file d’attente utilisée pour la suppression sont échangées.

Opérations de file d'attente (SDK Connector)

Le SDK Content Connector fournit des opérations permettant de transférer des éléments vers et d'extraire éléments d'une file d'attente.

Pour empaqueter un élément et le placer dans une file d'attente, utilisez la fonction pushItems compilateur.

Vous n'avez rien à faire de spécifique pour extraire les éléments d'une file d'attente pour en cours de traitement. À la place, le SDK extrait automatiquement les éléments de la file d'attente, en priorité à l'aide de la commande Repository getDoc .

Opérations de file d'attente (API REST)

L'API REST fournit les deux méthodes suivantes pour transférer des éléments vers et les éléments d'une file d'attente:

  • Pour ajouter un élément à une file d'attente, utilisez Items.push.
  • Pour interroger des éléments de la file d'attente, utilisez Items.poll.

Vous pouvez également utiliser Items.index pour placer des éléments dans la file d'attente pendant l'indexation. Éléments placés dans la file d'attente pendant la période et l'indexation ne nécessitent pas type et se voient automatiquement attribuer le statut ACCEPTED

Items.push

La Items.push ajoute des identifiants à la file d'attente. Cette méthode peut être appelée avec un type qui détermine le résultat de l'opération d'envoi. Pour obtenir la liste des valeurs type, consultez vers Champ item.type dans Items.push .

Le transfert d'un nouvel ID entraîne l'ajout d'une nouvelle entrée avec un NEW_ITEM. ItemStatus du code source.

La charge utile facultative est toujours stockée, traitée comme une valeur opaque et renvoyée de Items.poll

Lorsqu'un élément est interrogé, il est réservé, ce qui signifie qu'il ne peut pas être renvoyé par un autre appel à Items.poll En utilisant Items.push par type comme NOT_MODIFIED, REPOSITORY_ERROR ou REQUEUE, annule la réservation les entrées interrogées. Pour en savoir plus sur les entrées réservées et non réservées, reportez-vous à la section Items.poll.

Items.push avec hachage

L'API Google Cloud Search permet de spécifier les valeurs de hachage des métadonnées et du contenu. sur Items.index requêtes. Au lieu de spécifier type, les valeurs de hachage des métadonnées et/ou du contenu ; peut être spécifié à l'aide d'une requête push. La file d'attente d'indexation Cloud Search compare les valeurs de hachage fournies avec les valeurs stockées disponibles avec l'élément dans source de données. En cas d'incohérence, cette entrée est marquée comme MODIFIED. Si un opérateur n'existe pas dans l'index, l'état est donc NEW_ITEM.

Items.poll

Le fichier Items.poll récupère les entrées ayant la priorité la plus élevée dans la file d'attente. Les opérateurs et Les valeurs d'état renvoyées indiquent le ou les états du ou des ou l'état des ID renvoyés.

Par défaut, les entrées de n'importe quelle section de la file d'attente peuvent être renvoyées, en fonction leur priorité. Chaque entrée renvoyée est réservée et n'est pas renvoyée par d'autres appels à Items.poll jusqu'à ce que l'un des cas suivants soit satisfait:

  • La réservation expire.
  • L'entrée est de nouveau mise en file d'attente par Items.index.
  • Items.push est appelé avec une type valeur de NOT_MODIFIED, REPOSITORY_ERROR ou REQUEUE.