Die Indexierungswarteschlangen für Google Cloud Search

Mit dem Connector SDK und der Google Cloud Search API können Sie in der Cloud Search-Indexierungswarteschlange erstellen. Diese erfüllt folgende Zwecke:

• Dokumentstatus beibehalten, z. B. den Status oder Hashwerte. Mithilfe des Zustands können Sie den Index auf Ihr Repository abstimmen.

• Eine Liste der Elemente verwalten, die während des Durchlaufens als erkannt indexiert werden sollen.

• Elemente in Warteschlangen auf Grundlage des Elementstatus 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 wird, 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. In der folgenden Auflistung finden Sie die möglichen ItemStatus-Codes nach Priorität geordnet, angefangen mit der höchsten:

• ERROR: Beim Indexieren des Elements ist ein asynchroner Fehler aufgetreten und der Vorgang muss neu ausgeführt werden.

• MODIFIED: Das Element ist seit der letzten Indexierung im Repository geändert worden.

• NEW_ITEM: Das Element ist nicht indexiert.

• ACCEPTED: Dokument, das zuvor indexiert wurde und seit der letzten Indexierung im Repository nicht geändert wurde.

Wenn zwei Elemente in einer Warteschlange denselben Status haben, erhält dasjenige Vorrang, das sich länger in der Warteschlange befindet.

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 Vorgänge in der Warteschlange (Connector SDK).

Abbildung 1. Indexierung zum Hinzufügen oder Aktualisieren eines Elements

1. Der Inhalts-Connector verwendet items.push, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu schieben, um den Status des Elements (MODIFIED, NEW_ITEM, DELETED) festzulegen. Im Detail:

   • Beim Pushen enthält der Connector explizit einen Push-type oder contentHash.
   • Wenn der Connector die type nicht enthält, verwendet Cloud Search automatisch die contentHash, um den Status des Elements zu bestimmen.
   • Wenn der Artikel unbekannt ist, wird der Artikelstatus auf NEW_ITEM gesetzt.
   • Wenn das Element vorhanden ist und die Hashwerte übereinstimmen, bleibt der Status ACCEPTED.
   • Wenn das Element vorhanden ist und die Hashes sich unterscheiden, ändert sich der Status zu MODIFIED.

   Weitere Informationen dazu, wie der Artikelstatus ermittelt wird, finden Sie im Beispielcode GitHub-Repositories durchsuchen in der Einstiegsleitfaden für Cloud Search.

   Normalerweise wird die Übertragung mit Prozessen zum Durchlauf von Inhalten und/oder zur Änderungserkennung im Connector verknüpft.

2. Der Inhaltsconnector verwendet items.poll, um die Warteschlange abzufragen und zu indexierende Elemente zu ermitteln. Cloud Search teilt dem Connector mit, welche Elemente am dringendsten indexiert werden müssen. Die Sortierung erfolgt zuerst nach Statuscode und dann nach Wartezeit.

3. Der Connector ruft diese Elemente aus dem Repository ab und erstellt Index-API-Anfragen.

4. Der Connector verwendet items.index, um die Elemente zu indexieren. Das Element wechselt erst in den Status ACCEPTED, nachdem die Verarbeitung durch Cloud Search abgeschlossen wurde.

Ein Connector kann ein Element auch 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 auftritt. Informationen zum Löschen von Artikeln finden Sie im nächsten Abschnitt.

Hinweis :Bei einigen Durchlaufstrategien, z. B. der vollständigen Durchlaufstrategie, wird mehr als eine Indexierungswarteschlange verwendet. Ein Beispiel für die Verwendung von zwei Warteschlangen findest du 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öschungen zu erkennen. Abbildung 2 zeigt die Schritte zum Löschen eines Elements mit zwei Indexierungswarteschlangen. Abbildung 2 zeigt insbesondere den zweiten Durchlauf, der unter Verwendung einer Strategie mit vollständigem Durchlauf ausgeführt wurde. Bei diesen Schritten werden die REST API-Aufrufe verwendet. Entsprechende SDK-Aufrufe finden Sie unter Warteschlangenvorgänge (Connector SDK).

Abbildung 2. Elemente löschen

Hinweis :In der folgenden Liste der Schritte sind die Schritte 1 bis 4 in Abbildung 2 nicht aufgeführt, da sie mit den Schritten 1 bis 4 im vorherigen Diagramm identisch sind und nicht in den Zuständigkeitsbereich dieses Abschnitts fallen. Schritt 5 wird nicht angezeigt, da der Aufruf von deleteQueueItems auf eine leere Warteschlange nicht in den Zuständigkeitsbereich dieses Abschnitts fällt. In diesem Diagramm liegt der Schwerpunkt auf der zweiten Durchsuchung.

1. Beim ersten Durchlauf verwendet der Content-Connector items.push, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu schieben. „Queue A“ wird als NEW_ITEM verwendet, da sie noch nicht in der Warteschlange vorhanden ist. Jedem Element wird das Label „A“ für „Queue A“ zugewiesen. Die Inhalte werden in Cloud Search indexiert.

   Hinweis :Der Connector kann einem Element während eines item.push- oder item.index-Vorgangs ein Warteschlangenlabel zuweisen, indem er das Feld queue des Elements verwendet. Dieses Label kann geändert werden, wenn das Element neu per Push übertragen oder indexiert wird.

2. Der Inhaltsconnector verwendet items.poll, um Warteschlange A abzufragen und zu indexierende Elemente zu ermitteln. Cloud Search teilt dem Connector mit, welche Elemente am dringendsten indexiert werden müssen. Die Sortierung erfolgt zuerst nach Statuscode und dann nach Wartezeit.

3. Der Connector ruft diese Elemente aus dem Repository ab und erstellt Index-API-Anfragen.

4. Der Connector verwendet items.index zum Indexieren der Elemente. Das Element wechselt erst in den Status ACCEPTED, wenn Cloud Search die Verarbeitung erfolgreich abgeschlossen hat.

5. Die Methode deleteQueueItems wird für „queue B“ aufgerufen. Es wurden jedoch keine Elemente in Warteschlange B verschoben, sodass nichts gelöscht werden kann.

6. Bei der zweiten vollständigen Durchsuchung verwendet der Content-Connector items.push, um Elemente (Metadaten und Hash) in die Warteschlange B zu schieben:

   • Beim Pushen enthält der Connector explizit einen Push-type oder contentHash.
   • Wenn der Connector die type nicht enthält, verwendet Cloud Search automatisch die contentHash, 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, bleibt der Status ACCEPTED und das Warteschlangenlabel wird in „B.“ geändert.
   • Wenn das Element vorhanden ist und sich die Hashwerte unterscheiden, ändert sich der Status zu MODIFIED und das Warteschlangenlabel zu „B“.

7. Der Inhaltsconnector verwendet items.poll, um die Warteschlange abzufragen und zu indexierende Elemente zu ermitteln. Cloud Search teilt dem Connector mit, welche Elemente am dringendsten indexiert werden müssen. Die Sortierung erfolgt zuerst nach Statuscode und dann nach Wartezeit.

8. Der Connector ruft diese Elemente aus dem Repository ab und erstellt Index-API-Anfragen.

9. Der Connector verwendet items.index zum Indexieren der Elemente. Das Element wechselt erst in den Status ACCEPTED, wenn Cloud Search die Verarbeitung erfolgreich abgeschlossen hat.

10. Schließlich wird deleteQueueItems in Warteschlange A aufgerufen, um alle zuvor indexierten CCloud Search-Elemente zu löschen, die noch das Label „A“ der Warteschlange haben.

11. Bei nachfolgenden vollständigen Durchläufen werden die für die Indexierung und die für das Löschen verwendete Warteschlange getauscht.

Vorgänge in der Warteschlange (Connector SDK)

Das Content Connector SDK bietet Vorgänge, um Elemente in eine Warteschlange bzw. aus einer Warteschlange zu übertragen.

Wenn Sie ein Element verpacken und in einer Warteschlange platzieren möchten, verwenden Sie die Builder-Klasse pushItems.

Sie müssen nichts tun, um Elemente wieder aus der Warteschlange herauszuholen, wenn diese verarbeitet werden sollen. Stattdessen ruft das SDK automatisch Elemente in Prioritätsreihenfolge aus der Warteschlange ab, indem die Methode getDoc der Klasse Repository verwendet wird.

Vorgänge in der Warteschlange (REST API)

Mit der REST API werden die folgenden beiden Methoden zum Hinzufügen und Abrufen von Elementen zu bzw. aus einer Warteschlange bereitgestellt:

• Wenn Sie ein Element in eine Warteschlange verschieben möchten, verwenden Sie Items.push.
• Um Elemente in der Warteschlange abzufragen, verwenden Sie Items.poll.

Sie können auch Items.index verwenden, um Elemente während der Indexierung in die Warteschlange zu stellen. Elemente, die während des Indexierens in die Warteschlange geschoben werden, erfordern kein type und erhalten automatisch den Status ACCEPTED.

Items.push

Mithilfe der Methode Items.push werden der Warteschlange IDs hinzugefügt. Sie kann mit einem bestimmten type-Wert aufgerufen werden, der das Ergebnis der Push-Vorgangs bestimmt. Eine Liste der type-Werte finden Sie im Feld item.type der Methode Items.push.

NEW_ITEM erhält.NEW_ITEM ItemStatus

Die optionale Nutzlast wird immer gespeichert, als opaker Wert behandelt und von Items.poll zurückgegeben.

Wenn ein Element abgefragt wird, ist es reserviert. Das bedeutet, dass es nicht von einem anderen Aufruf von Items.poll zurückgegeben werden kann. Wenn Sie Items.push mit type als NOT_MODIFIED, REPOSITORY_ERROR oder REQUEUE verwenden, werden die abgefragten Einträge entfernt. Weitere Informationen zu reservierten und nicht reservierten Einträgen finden Sie im Abschnitt Items.poll.

Items.push mit Hashes

Die Google Cloud Search API unterstützt die Angabe von Hash-Werten für Metadaten und Inhalte in Items.index-Anfragen. Statt type zu definieren, lassen sich Metadaten-/Inhalts-Hashwerte in einer Push-Anfrage angegeben. In Cloud Search-Indexierungswarteschlangen werden die bereitgestellten Hashwerte mit den gespeicherten Werten verglichen, die für das Element in der Datenquelle verfügbar sind. Falls es keine Übereinstimmung gibt, wird dieser Eintrag als MODIFIED markiert. Wenn im Index kein entsprechendes Element vorhanden ist, lautet der Status NEW_ITEM.

Hinweis: In Items.push-Anfragen bereitgestellte Hashwerte werden nicht mit dem Element gespeichert. Diese Elemente dienen nur dazu festzustellen, ob das Element geändert wurde.

Items.poll

Mithilfe der Items.poll-Methode werden die Einträge mit der höchsten Priorität aus der Warteschlange abgerufen. Die angeforderten und zurückgegebenen Statuswerte geben den oder die Status der angeforderten Prioritätswarteschlangen oder den Status der zurückgegebenen IDs an.

Standardmäßig können aus allen Abschnitten der Warteschlange Einträge 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 eintritt:

• Die Reservierung läuft ab.
• Der Eintrag wird von Items.index wieder in die Warteschlange eingereiht.
• Items.push wird mit dem Wert NOT_MODIFIED, REPOSITORY_ERROR oder REQUEUE für type aufgerufen.