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).
<ph type="x-smartling-placeholder">- </ph>
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
oucontentHash
. - Si le connecteur n'inclut pas
type
, Cloud Search utilise automatiquementcontentHash
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.
- Lors du transfert, le connecteur inclut explicitement une commande
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.Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.
Le connecteur utilise
items.index
pour indexer les éléments. L'élément n'est à l'étatACCEPTED
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).
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 queNEW_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.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.Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.
Le connecteur utilise
items.index
pour indexer les éléments. L'élément ne passe à l'étatACCEPTED
qu'après Cloud Search termine le traitement de l'élément.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é.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
oucontentHash
. - Si le connecteur n'inclut pas
type
, Cloud Search utilise automatiquementcontentHash
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 ».
- Lors du transfert, le connecteur inclut explicitement une commande
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.Le connecteur récupère ces éléments du dépôt et de l'index des builds Requêtes API.
Le connecteur utilise
items.index
pour indexer les éléments. L'élément n'est à l'étatACCEPTED
qu'après Cloud Search termine le traitement de l'élément.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é.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
avec
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 unetype
valeur deNOT_MODIFIED
,REPOSITORY_ERROR
ouREQUEUE
.