Die Indexierungswarteschlangen für Google Cloud Search

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

• Dokumentzustand 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 – Übersicht

Abbildung 1 zeigt die Schritte zum Indexieren eines neuen oder geänderten Elements mithilfe einer Indexierungswarteschlange. In diesen Schritten werden REST API-Aufrufe gezeigt. Entsprechende SDK-Aufrufe finden Sie unter Vorgänge in der Warteschlange (Connector SDK).

Abbildung 1. Schritte zum Indexieren zum Hinzufügen oder Aktualisieren eines Elements

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

   • Beim Pushing enthält der Connector explizit einen Push-Vorgang type oder contentHash.
   • Wenn der Connector das type nicht enthält, verwendet Cloud Search automatisch das contentHash, um den Status des Elements zu ermitteln.
   • 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 sich die Hashes unterscheiden, ändert sich der Status zu MODIFIED.

   Weitere Informationen dazu, wie der Elementstatus ermittelt wird, finden Sie im Beispielcode GitHub-Repositories durchlaufen in der Cloud Search-Anleitung für den Einstieg.

   Normalerweise ist der Push mit Prozessen zum Durchlaufen von Inhalten und/oder zur Erkennung von Änderungen im Connector verknüpft.

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

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 Cloud Search die Verarbeitung des Elements abgeschlossen hat.

Ein Connector kann ein Element auch löschen, wenn es nicht mehr im Repository vorhanden ist, oder ein Element noch einmal ü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.

Hinweis :Bei einigen Traversal-Strategien, z. B. dem vollständigen Traversal, werden mehrere Indexierungswarteschlangen verwendet. Ein Beispiel für die Verwendung von zwei Warteschlangen finden Sie im nächsten Abschnitt.

Übersicht über die Verwendung von Indexierungswarteschlangen zum Löschen eines Elements

Bei der Strategie für vollständiges Durchlaufen werden Elemente mit zwei Warteschlangen indexiert und Löschungen erkannt. Abbildung 2 zeigt die Schritte zum Löschen eines Elements mit zwei Indexierungswarteschlangen. Abbildung 2 zeigt den zweiten Durchlauf mit einer Strategie für vollständige Durchläufe. In diesen Schritten werden 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 nicht in Abbildung 2 dargestellt, da sie mit den Schritten 1 bis 4 im vorherigen Diagramm identisch sind und nicht in den Umfang dieses Abschnitts fallen. Schritt 5 wird nicht angezeigt, da der Aufruf von deleteQueueItems für eine leere Warteschlange nicht in den Umfang dieses Abschnitts fällt. Dieses Diagramm konzentriert sich auf den zweiten Durchlauf.

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

   Hinweis :Der Connector kann einem Element während eines item.push- oder item.index-Vorgangs mithilfe des Felds queue des Elements ein Warteschlangenlabel zuweisen. Dieses Label kann geändert werden, wenn der Artikel noch einmal übertragen oder neu indexiert wird.

2. Der Content-Connector verwendet items.poll, um die Warteschlange A abzufragen und zu ermitteln, welche Elemente indexiert werden sollen. Cloud Search teilt dem Connector mit, welche Elemente am dringendsten indexiert werden müssen. Die Sortierung erfolgt zuerst nach Statuscode und dann nach der Zeit in der Warteschlange.

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 Cloud Search die Verarbeitung des Elements abgeschlossen hat.

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

6. Beim zweiten vollständigen Durchlauf verwendet der Content-Connector items.push, um Elemente (Metadaten und Hash) in die Warteschlange B zu übertragen:

   • Beim Pushing enthält der Connector explizit einen Push-Vorgang type oder contentHash.
   • Wenn der Connector das type nicht enthält, verwendet Cloud Search automatisch das contentHash, um den Status des Elements zu ermitteln.
   • 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 Hashes unterscheiden, ändert sich der Status zu MODIFIED und das Warteschlangenlabel wird in „B.“ geändert.

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

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 Cloud Search die Verarbeitung des Elements abgeschlossen hat.

10. Schließlich wird deleteQueueItems für die 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 verwendeten Warteschlangen 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 aus der Warteschlange in der Reihenfolge ihrer Priorität ab. Dazu wird die Methode getDoc der Klasse Repository verwendet.

Warteschlangenoperationen (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 der Indexierung in die Warteschlange gestellt werden, erfordern keine 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 des Push-Vorgangs bestimmt. Eine Liste der type-Werte finden Sie im Feld item.type der Methode Items.push.

NEW_ITEM erhält.NEW_ITEMItemStatus

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 abgefragte Einträge nicht mehr reserviert. Weitere Informationen zu reservierten und nicht reservierten Einträgen finden Sie im Abschnitt Items.poll.

Items.push mit Hashwerten

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 Anforderungen erfüllt ist:

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