Files d'attente d'indexation Google Cloud Search

Le SDK Connector et l'API REST Cloud Search permettent de créer des files d'attente d'indexation Cloud Search pour effectuer les tâches suivantes:

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

• Maintenir une liste d'éléments à indexer comme détectés lors du processus de balayage.

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

• gérer des informations d'état supplémentaires pour une intégration efficace, telles que les points de contrôle, les jetons de modification, etc. ;

Une file d'attente est un libellé attribué à un élément indexé, tel que "par défaut" pour la 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 est basée sur son code ItemStatus. Voici les codes ItemStatus possibles par ordre de priorité (les premiers à gérer en dernier):

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

• MODIFIED : élément précédemment indexé et modifié depuis dans le dépôt depuis la dernière indexation.

• NEW_ITEM : élément non indexé

• ACCEPTED : document qui était précédemment indexé et qui n'a pas été modifié dans le dépôt depuis la dernière indexation.

Lorsque deux éléments d'une file d'attente ont le même état, une priorité supérieure est accordée aux éléments placés dans la file d'attente pendant la plus longue période.

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

La figure 1 décrit la procédure d'indexation d'un élément nouveau ou modifié à l'aide d'une file d'attente d'indexation. Ces étapes montrent les appels d'API REST. Pour des appels de SDK équivalents, consultez la section Opérations de file d'attente (SDK Connector).

Figure 1. Procédure d'indexation pour ajouter ou mettre à jour un élément

1. Le connecteur de contenu utiliseitems.push pour envoyer des éléments (métadonnées et hachage) dans une file d'attente d'indexation afin d'établir leur état (MODIFIED ;NEW_ITEM ;DELETED à Pour être plus précis:

   • Lors de l'envoi, le connecteur inclut explicitement un élément type ou contentHash.
   • Si le connecteur n'inclut pas la valeur type, Cloud Search utilise automatiquement contentHash pour déterminer l'état de l'élément.
   • Si l'élément est inconnu, il est associé à l'état NEW_ITEM.
   • Si l'élément existe et que les valeurs de hachage correspondent, l'état est conservé comme ACCEPTED.
   • Si l'élément existe et que les hachages diffèrent, l'état passe à MODIFIED.

   Pour plus d'informations sur l'établissement de l'état de l'élément, reportez-vous à l'exemple de code Traversing les dépôts GitHub du tutoriel de mise en route de Cloud Search.

   En général, la transmission est associée à des processus de balayage de contenu et/ou de détection de modifications dans le connecteur.

2. Le connecteur de contenu utilise items.poll pour interroger la file d'attente afin de déterminer les éléments à indexer. Cloud Search indique au connecteur quels éléments sont les plus besoin d'indexation, triés d'abord par code d'état, puis par temps d'attente.

3. Le connecteur récupère ces éléments dans le dépôt et crée des requêtes API d'index.

4. Le connecteur utilise items.index pour indexer les éléments. L'élément ne passe à l'état ACCEPTED qu'une fois que Cloud Search a fini de traiter 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'est pas modifié ou en cas d'erreur de dépôt source. Pour en savoir plus sur les éléments supprimés, consultez la section suivante.

Remarque :Certaines stratégies de balayage, telles que le parcours complet, utilisent plusieurs files d'attente d'indexation. Pour obtenir un exemple d'utilisation de deux files d'attente, reportez-vous à la section suivante.

Présentation de l'utilisation des 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 des éléments et détecter les suppressions. La figure 2 décrit la procédure de suppression d'un élément à l'aide de deux 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 les appels d'API REST. Pour des appels de SDK équivalents, consultez la section Opérations de file d'attente (SDK Connector).

Figure 2. Supprimer des éléments

Remarque: Dans la liste suivante, les étapes 1 à 4 ne sont pas illustrées dans la figure 2, car elles sont identiques aux étapes 1 à 4 décrites dans le schéma précédent et ne sont pas abordées dans le cadre de cette section. L'étape 5 n'est pas affichée, car l'appel de deleteQueueItems sur une file d'attente vide n'entre pas dans le cadre de cette section. Ce diagramme se concentre sur le deuxième balayage.

1. Lors du parcours 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 appelée "file d'attente A" au format NEW_ITEM. car elle n'existe pas dans la file d'attente. Chaque élément se voit attribuer le libellé "A" pour la "file d'attente A". Le contenu est indexé dans Cloud Search.

   Remarque :Le connecteur peut attribuer un libellé de file d'attente à l'élément à l'aide du champ queue de l'élément lors d'une opération item.push ou item.index. (Installation de Python groupée). Ce libellé peut être modifié chaque fois que l'élément est renvoyé ou réindexé.

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 quels éléments sont les plus besoin d'indexation, triés d'abord par code d'état, puis par temps d'attente.

3. Le connecteur récupère ces éléments dans le dépôt et crée des requêtes API d'index.

4. Le connecteur utilise items.index pour indexer les éléments. L'élément ne passe à l'état ACCEPTED qu'une fois que Cloud Search a fini de traiter l'élément.

5. La méthode deleteQueueItems est appelée sur la "file d'attente B". Cependant, aucun élément n'a été transféré vers la file d'attente B. Aucun élément ne peut donc être supprimé.

6. Lors du second balayage complet, le connecteur de contenu utilise items.push pour transférer des éléments (métadonnées et hachage) dans la file d'attente B:

   • Lors de l'envoi, le connecteur inclut explicitement un élément type ou contentHash.
   • Si le connecteur n'inclut pas la valeur type, Cloud Search utilise automatiquement contentHash pour déterminer l'état de l'élément.
   • Si l'élément est inconnu, l'état de l'élément est défini sur NEW_ITEM et le libellé de la file d'attente est remplacé par "B".
   • Si l'élément existe et que les valeurs de hachage correspondent, l'état est conservé comme ACCEPTED et le libellé de la file d'attente est remplacé par "B".
   • Si l'élément existe et que les hachages diffèrent, l'état devient MODIFIED et le libellé de la file d'attente est remplacé par "B".

7. Le connecteur de contenu utilise items.poll pour interroger la file d'attente afin de déterminer les éléments à indexer. Cloud Search indique au connecteur quels éléments sont les plus besoin d'indexation, triés d'abord par code d'état, puis par temps d'attente.

8. Le connecteur récupère ces éléments dans le dépôt et crée des requêtes API d'index.

9. Le connecteur utilise items.index pour indexer les éléments. L'élément ne passe à l'état ACCEPTED qu'une fois que Cloud Search a fini de traiter l'élément.

10. Enfin, deleteQueueItems est appelé dans la file d'attente A pour supprimer tous les éléments Cloud Search indexés précédemment associés à un libellé "A".

11. Avec les balayages complets suivants, la file d'attente utilisée pour l'indexation et la suppression utilisée pour la suppression sont échangées.

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

Le SDK Content Connector propose des opérations permettant d'envoyer des éléments à une file d'attente et d'en extraire des éléments.

Pour empaqueter et envoyer un élément à une file d'attente, utilisez la classe pushItems.

Aucune action n'est requise de votre part pour extraire des éléments d'une file d'attente en vue du traitement. Au lieu de cela, le SDK extrait automatiquement les éléments de la file d'attente, par ordre de priorité, à l'aide de la méthode getDoc de la classe Repository. (Installation de Python groupée).

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

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

• Pour placer un élément dans une file d'attente, utilisez Items.push.
• Pour interroger les éléments de la file d'attente, utilisez Items.poll.

Vous pouvez également envoyer des éléments à la file d'attente pendant l'indexation à l'aide de Items.index. Les éléments envoyés à la file d'attente lors de l'indexation ne nécessitent pas d'élément type et se voient automatiquement attribuer l'état ACCEPTED.

Items.push

La méthode Items.push ajoute des ID à la file d'attente. Cette méthode peut être appelée avec une valeur type spécifique qui détermine le résultat de l'opération d'envoi. Pour obtenir la liste des valeurs type, reportez-vous au champ item.type dans la méthode Items.push. .

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

La charge utile facultative est toujours stockée, traitée comme une valeur opaque et renvoyée par 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. Utiliser Items.push avec type en tant que NOT_MODIFIED, REPOSITORY_ERROR ou REQUEUE, réserve les entrées de sondage. Pour plus d'informations sur les entrées réservées et non réservées, consultez la section Items.poll.

Items.push avec hachages

L'API REST de Cloud Search permet de spécifier des valeurs de hachage des métadonnées et des contenus dans les requêtes Items.index. Au lieu de spécifier type, les valeurs de hachage des métadonnées et/ou du contenu peuvent être spécifiées avec une requête push. La file d'attente d'indexation Cloud Search compare les valeurs de hachage fournies aux valeurs stockées disponibles avec l'élément dans la source de données. En cas de non-concordance, cette entrée est marquée comme MODIFIED. Si un élément correspondant n'existe pas dans l'index, l'état est NEW_ITEM.

Remarque :Les valeurs de hachage fournies avec les requêtes Items.push ne sont pas enregistrées avec l'élément. Ces éléments ne sont utilisés que pour déterminer si l'élément est modifié.

Items.poll

La méthode Items.poll récupère les entrées ayant la priorité la plus élevée dans la file d'attente. Les valeurs d'état demandées et renvoyées indiquent l'état des files d'attente prioritaires demandées 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 de la priorité. Chaque entrée renvoyée est réservée et n'est renvoyée par aucun autre appel à Items.poll tant que l'un des cas suivants n'est pas rempli:

• La réservation expire.
• L'entrée est de nouveau en file d'attente par Items.index.
• Items.pushest appelé avec untype valeur deNOT_MODIFIED ;REPOSITORY_ERROR ouREQUEUE (Installation de Python groupée).