Die Indexierungswarteschlangen für Google Cloud Search

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).

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

1. 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 oder contentHash ein.
   • Wenn der Connector type nicht enthält, verwendet Cloud Search automatisch den contentHash, 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.

2. 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.

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

4. Der Connector verwendet items.index, um die Elemente zu indexieren. Das Element wechselt erst in den Status ACCEPTED, 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.

Hinweis: Einige Durchlaufstrategien, z. B. der Durchlauf mit vollständiger Indexierung, verwenden mehrere Indexierungswarteschlangen. Ein Beispiel für die Verwendung von zwei Warteschlangen 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).

Abbildung 2. Elemente löschen

Hinweis: Die Schritte 1 bis 4 in der folgenden Liste von Schritten werden in Abbildung 2 nicht dargestellt, da sie mit den Schritten 1 bis 4 im vorherigen Diagramm identisch sind und nicht in diesem Abschnitt behandelt werden. Schritt 5 wird nicht angezeigt, da der Aufruf von deleteQueueItems für eine leere Warteschlange nicht in diesem Abschnitt enthalten ist. Dieses Diagramm konzentriert sich auf den zweiten Durchlauf.

1. Beim ersten Durchlauf verwendet der Inhaltsconnector items.push, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange, „Warteschlange A“, als NEW_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.

   Hinweis: Der Connector kann einem Element während eines item.push- oder item.index-Vorgangs ein Warteschlangenlabel zuweisen. Dazu wird das Feld queue verwendet. Dieses Label kann geändert werden, wenn das Element noch einmal übertragen oder indexiert wird.

2. 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.

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

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

5. Die Methode deleteQueueItems wird in „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 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 oder contentHash ein.
   • Wenn der Connector type nicht enthält, verwendet Cloud Search automatisch den 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, 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.

7. 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.

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

9. Der Connector verwendet items.index, um die Elemente zu indexieren. Das Element wechselt erst in den Status ACCEPTED, nachdem es von Cloud Search verarbeitet wurde.

10. 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.

11. 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.

Hinweis: Hashwerte, die in Items.push-Anfragen angegeben werden, werden nicht mit dem Element gespeichert. Diese Elemente werden nur verwendet, um festzustellen, ob das Element geändert wurde.

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 dem type-Wert NOT_MODIFIED, REPOSITORY_ERROR oder REQUEUE aufgerufen.