Mit dem Connector SDK und der Google Cloud Search API können Sie Indexierungswarteschlangen in Cloud Search erstellen, mit denen die folgenden Aufgaben ausgeführt werden können:
Behalten Sie den Status pro Dokument (Status, Hashwerte usw.) bei. Er kann verwendet werden, um den Index mit Ihrem Repository synchron zu halten.
Eine Liste der Elemente verwalten, die während des Durchlaufs als erkannt indexiert werden sollen.
Elemente in Warteschlangen basierend auf dem Status der Elemente priorisieren.
Zusätzliche Statusinformationen für eine effiziente Integration verwalten, z. B. Checkpoints, Änderungstokens usw.
Eine Warteschlange ist ein Label, das einem indexierten Element zugewiesen ist, z. B. „default“ für die Standardwarteschlange oder „B“ für Warteschlange B.
Status und Priorität
Die Priorität eines Dokuments in einer Warteschlange basiert auf seinem ItemStatus
-Code. Nachfolgend sind die möglichen ItemStatus
-Codes nach Priorität geordnet (von der ersten bis zur letzten verarbeitet):
ERROR
: Beim Indexieren des Elements ist ein asynchroner Fehler aufgetreten und er muss neu indexiert werden.MODIFIED
: Das Element, das zuvor indexiert und seit der letzten Indexierung im Repository geändert wurde.NEW_ITEM
: nicht indexiertes Element.ACCEPTED
: Das Dokument, das zuvor indexiert wurde und sich seit der letzten Indexierung im Repository nicht geändert hat.
Wenn zwei Elemente in einer Warteschlange denselben Status haben, haben die Elemente, die sich am längsten zurückbefinden, eine höhere Priorität.
Indexierungswarteschlangen zum Indexieren eines neuen oder geänderten Elements verwenden
Abbildung 1 zeigt die Schritte zum Indexieren eines neuen oder geänderten Elements mithilfe einer Indexierungswarteschlange. Diese Schritte zeigen REST API-Aufrufe. Entsprechende SDK-Aufrufe finden Sie unter Warteschlangenvorgänge (Connector SDK).
Der Inhaltsconnector nutzt
items.push
, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu verschieben, um den Status des Elements (MODIFIED
,NEW_ITEM
,DELETED
) zu ermitteln:- Bei der Übertragung fügt der Connector explizit ein Push-
type
odercontentHash
ein. - Wenn der Connector
type
nicht enthält, verwendet Cloud Search automatisch dencontentHash
, um den Status des Elements zu bestimmen. - Wenn das Element unbekannt ist, wird der Elementstatus auf
NEW_ITEM
gesetzt. - Wenn das Element vorhanden ist und die Hashwerte übereinstimmen, wird der Status
ACCEPTED
beibehalten. - Wenn das Element vorhanden ist und sich die Hashes unterscheiden, lautet der Status
MODIFIED
.
Weitere Informationen zum Ermitteln des Elementstatus finden Sie im Beispielcode GitHub-Repositories durchsuchen in der Anleitung zum Einstieg in Cloud Search.
Normalerweise ist die Übertragung mit Inhaltsdurchläufen und/oder Änderungserkennungsprozessen im Connector verknüpft.
- Bei der Übertragung fügt der Connector explizit ein Push-
Der Inhaltsconnector verwendet
items.poll
, um die Warteschlange abzufragen und die zu indexierenden Elemente zu bestimmen. Cloud Search teilt dem Connector mit, welche Elemente am meisten indexiert werden müssen. Diese Elemente werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.Der Connector ruft diese Elemente aus dem Repository ab und erstellt API-Indexanfragen.
Der Connector verwendet
items.index
, um die Elemente zu indexieren. Das Element wechselt erst in den StatusACCEPTED
, nachdem es von Cloud Search verarbeitet wurde.
Ein Connector kann auch ein Element löschen, wenn es nicht mehr im Repository vorhanden ist, oder ein Element noch einmal per Push übertragen, wenn es nicht geändert wurde oder ein Fehler im Quell-Repository vorliegt. Informationen zum Löschen von Elementen finden Sie im nächsten Abschnitt.
Indexierungswarteschlangen zum Löschen eines Elements verwenden
Bei der Strategie mit vollständigem Durchlauf wird ein Zwei-Warteschlangen-Prozess verwendet, um Elemente zu indexieren und Löschvorgänge zu erkennen. Abbildung 2 zeigt die Schritte zum Löschen eines Elements mithilfe von zwei Indexierungswarteschlangen. Abbildung 2 zeigt insbesondere den zweiten Durchlauf mit einer Strategie für vollständigen Durchlauf. In diesen Schritten werden die REST API-Aufrufe verwendet. Entsprechende SDK-Aufrufe finden Sie unter Warteschlangenvorgänge (Connector SDK).
Beim ersten Durchlauf verwendet der Inhaltsconnector
items.push
, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange, „Warteschlange A“, alsNEW_ITEM
zu verschieben, da sie noch nicht in der Warteschlange vorhanden ist. Jedem Element wird das Label „A“ für „Warteschlange A“ zugewiesen. Die Inhalte werden in Cloud Search indexiert.Der Inhaltsconnector verwendet
items.poll
, um Warteschlange A abzufragen und die zu indexierenden Elemente zu bestimmen. Cloud Search teilt dem Connector mit, welche Elemente am meisten indexiert werden müssen. Diese Elemente werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.Der Connector ruft diese Elemente aus dem Repository ab und erstellt API-Indexanfragen.
Der Connector verwendet
items.index
, um die Elemente zu indexieren. Das Element wechselt erst in den StatusACCEPTED
, nachdem es von Cloud Search verarbeitet wurde.Die Methode
deleteQueueItems
wird in „Warteschlange B“ aufgerufen. Es wurden jedoch keine Elemente in die Warteschlange B verschoben, sodass nichts gelöscht werden kann.Beim zweiten vollständigen Durchlauf nutzt der Inhaltsconnector
items.push
, um Elemente (Metadaten und Hash) in Warteschlange B zu verschieben:- Bei der Übertragung fügt der Connector explizit ein Push-
type
odercontentHash
ein. - Wenn der Connector
type
nicht enthält, verwendet Cloud Search automatisch dencontentHash
, um den Status des Elements zu bestimmen. - Wenn das Element unbekannt ist, wird der Elementstatus auf
NEW_ITEM
gesetzt und das Warteschlangenlabel in "B" geändert. - Wenn das Element vorhanden ist und die Hashwerte übereinstimmen, wird der Status
ACCEPTED
beibehalten und das Warteschlangenlabel wird in „B“ geändert. - Wenn das Element vorhanden ist und sich die Hashes unterscheiden, lautet der Status
MODIFIED
und das Warteschlangenlabel wird in „B“ geändert.
- Bei der Übertragung fügt der Connector explizit ein Push-
Der Inhaltsconnector verwendet
items.poll
, um die Warteschlange abzufragen und die zu indexierenden Elemente zu bestimmen. Cloud Search teilt dem Connector mit, welche Elemente am meisten indexiert werden müssen. Diese Elemente werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.Der Connector ruft diese Elemente aus dem Repository ab und erstellt API-Indexanfragen.
Der Connector verwendet
items.index
, um die Elemente zu indexieren. Das Element wechselt erst in den StatusACCEPTED
, nachdem es von Cloud Search verarbeitet wurde.Zum Schluss wird
deleteQueueItems
in Warteschlange A aufgerufen, um alle zuvor indexierten CCloud Search-Elemente zu löschen, die noch das Label der Warteschlange A haben.Bei nachfolgenden Durchläufen mit vollständiger Indexierung werden die für die Indexierung verwendete Warteschlange und die zum Löschen verwendete Warteschlange ausgetauscht.
Vorgänge in der Warteschlange (Connector SDK)
Das Content Connector SDK bietet Vorgänge zum Verschieben von Elementen an eine Warteschlange und zum Abrufen von Elementen aus einer Warteschlange.
Wenn Sie ein Element verpacken und in eine Warteschlange verschieben möchten, verwenden Sie die Builder-Klasse pushItems
.
Sie müssen nichts weiter tun, um Elemente zur Verarbeitung aus einer Warteschlange abzurufen. Stattdessen werden vom SDK mithilfe der Methode getDoc
der Klasse Repository automatisch Elemente nach Priorität aus der Warteschlange abgerufen.
Warteschlangenvorgänge (REST API)
Die REST API bietet die beiden folgenden Methoden zum Verschieben von Elementen in eine Warteschlange und Abrufen von Elementen aus einer Warteschlange:
- Um ein Element in eine Warteschlange zu verschieben, verwenden Sie
Items.push
. - Um Elemente in der Warteschlange abzufragen, verwenden Sie
Items.poll
.
Während der Indexierung kannst du Elemente auch mithilfe von Items.index
in die Warteschlange verschieben. Elemente, die während der Indexierung in die Warteschlange verschoben werden, benötigen kein type
und erhalten automatisch den Status ACCEPTED
.
Items.push
Mit der Methode Items.push
werden der Warteschlange IDs hinzugefügt. Diese Methode kann mit einem bestimmten Wert für type
aufgerufen werden, der das Ergebnis des Push-Vorgangs bestimmt. Eine Liste der type
-Werte finden Sie in der Methode Items.push im Feld item.type
.
Wenn Sie eine neue ID senden, wird ein neuer Eintrag mit dem Code NEW_ITEM
ItemStatus
hinzugefügt.
Die optionale Nutzlast wird immer gespeichert, als intransparenter Wert behandelt und von Items.poll
zurückgegeben.
Wenn ein Element abgefragt wird, wird es reserviert. Das bedeutet, dass es nicht durch einen anderen Aufruf von Items.poll
zurückgegeben werden kann.
Wenn Sie Items.push
mit type
als NOT_MODIFIED
, REPOSITORY_ERROR
oder REQUEUE
verwenden, heben Sie die Reservierung der abgefragten Einträge auf. Weitere Informationen zu reservierten und nicht reservierten Einträgen finden Sie im Abschnitt Items.poll.
Items.push
mit Hashes
Mit der Google Cloud Search API können Sie Metadaten- und Inhalts-Hashwerte in Items.index
-Anfragen angeben. Anstatt type
anzugeben, können die Metadaten- und/oder Inhalts-Hashwerte in einer Push-Anfrage angegeben werden. Die Cloud Search-Indexierungswarteschlange vergleicht die bereitgestellten Hashwerte mit den gespeicherten Werten, die für das Element in der Datenquelle verfügbar sind. Bei einer Abweichung wird dieser Eintrag als MODIFIED
gekennzeichnet. Wenn ein entsprechendes Element nicht im Index vorhanden ist, lautet der Status NEW_ITEM
.
Items.poll
Mit der Methode Items.poll werden die Einträge mit der höchsten Priorität aus der Warteschlange abgerufen. Die angeforderten und zurückgegebenen Statuswerte geben den Status der angeforderten Prioritätswarteschlangen oder den Status der zurückgegebenen IDs an.
Standardmäßig können Einträge aus jedem Abschnitt der Warteschlange nach Priorität zurückgegeben werden. Jeder zurückgegebene Eintrag ist reserviert und wird bei anderen Aufrufen von Items.poll
nicht zurückgegeben, bis einer der folgenden Fälle zutrifft:
- Die Reservierung überschreitet das Zeitlimit.
- Der Eintrag wird von
Items.index
wieder in die Warteschlange eingereiht. Items.push
wird mit demtype
-WertNOT_MODIFIED
,REPOSITORY_ERROR
oderREQUEUE
aufgerufen.