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: Das Dokument wurde zuvor indexiert und wurde seitdem im Repository nicht geändert.

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. In diesen Schritten werden REST API-Aufrufe veranschaulicht. 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 ist der Push mit dem Durchsuchen von Inhalten und/oder Änderungserkennungsprozessen im Connector verknüpft.

2. Der Content-Connector verwendet items.poll, um die Warteschlange abzufragen und die zu indexierenden 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, nachdem die Verarbeitung durch Cloud Search abgeschlossen wurde.

Ein Connector kann auch ein Element löschen, wenn es nicht mehr im Repository vorhanden ist, oder ein Element noch einmal pushen, wenn es nicht geändert wurde oder ein Fehler im Quell-Repository vorliegt. 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 Volldurchlaufstrategie werden Elemente mithilfe eines Zwei-Warteschlangen-Prozesses indexiert und Löschungen erkannt. Abbildung 2 zeigt die Schritte zum Löschen eines Elements mit zwei Indexierungswarteschlangen. Abbildung 2 zeigt die zweite Durchsuchung, die mit einer vollständigen Durchlaufstrategie durchgeführt wird. Bei diesen Schritten werden die REST API-Aufrufe verwendet. Entsprechende SDK-Aufrufe finden Sie unter Vorgänge in der Warteschlange (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 der Artikel noch einmal gepusht oder neu indexiert wird.

2. Der Content-Connector verwendet items.poll, um Warteschlange A abzufragen und die zu indexierenden 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, nachdem die Verarbeitung durch Cloud Search abgeschlossen wurde.

5. Die Methode deleteQueueItems wird auf „queue B“ aufgerufen. Es wurden jedoch keine Elemente in die Warteschlange B geschoben, 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 Artikelstatus 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 Content-Connector verwendet items.poll, um die Warteschlange abzufragen und die zu indexierenden 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, nachdem die Verarbeitung durch Cloud Search abgeschlossen wurde.

10. Schließlich wird deleteQueueItems auf Warteschlange A aufgerufen, um alle zuvor indexierten Cloud Search-Elemente zu löschen, die noch das Label „Warteschlange A“ 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)

Mit dem Content Connector SDK werden Vorgänge zum Hinzufügen und Abrufen von Elementen zu bzw. aus einer Warteschlange bereitgestellt.

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:

• Zum Hinzufügen zu einer Warteschlange: Items.push
• Zum Abrufen aus einer Warteschlange: Items.poll

Während der Indexierung können Sie Elemente auch mithilfe von Items.index der Warteschlange hinzufügen. 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 nicht transparenter 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

Mit der Google Cloud Search API können in Items.index-Anfragen Hashwerte für Metadaten und Inhalte angegeben werden. 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 :Mit 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.