Die Indexierungswarteschlangen für Google Cloud Search

Mit dem Connector SDK und der Google Cloud Search API können Sie Cloud Search-Indexierungswarteschlangen erstellen, die für folgende Aufgaben verwendet werden:

• Dokumentstatus (Status, Hashwerte usw.) beibehalten, um den Index mit Ihrem Repository zu synchronisieren.

• Pflegen Sie eine Liste der Elemente, die während des Durchlaufs als erkannt indexiert werden sollen.

• Elemente in Warteschlangen anhand 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 ist, z. B. „Standard“ 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. Im Folgenden finden Sie die möglichen ItemStatus-Codes in der Reihenfolge ihrer Priorität (erste und letzte Verarbeitung):

• ERROR: Beim Indexierungsprozess ist ein asynchroner Fehler aufgetreten und das Element muss neu indexiert werden.

• MODIFIED: Element, das zuvor indexiert und seit der letzten Indexierung im Repository geändert wurde.

• NEW_ITEM: Element, das nicht indexiert ist.

• 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, werden den Elementen, die sich am längsten in der Warteschlange befunden haben, eine höhere Priorität eingeräumt.

Übersicht über die Verwendung von Indexierungswarteschlangen zum Indexieren neuer oder geänderter Elemente

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

1. Der Inhaltsconnector verwendet items.push, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu verschieben, um den Status des Elements (MODIFIED, NEW_ITEM, DELETED) zu ermitteln. Insbesondere:

   • Beim Push-Verfahren enthält der Connector explizit ein Push-type oder contentHash.
   • Wenn der Connector type nicht enthält, verwendet Cloud Search automatisch den contentHash, um den Status des Elements zu ermitteln.
   • Ist das Element unbekannt, wird sein Status auf „NEW_ITEM“ gesetzt.
   • Wenn das Element vorhanden ist und die Hashwerte übereinstimmen, wird der Status als ACCEPTED beibehalten.
   • Wenn das Element vorhanden ist und sich die Hashwerte unterscheiden, wird der Status zu MODIFIED.

   Weitere Informationen zum Ermitteln des Elementstatus finden Sie im Beispielcode GitHub-Repositories durchsuchen in der Einführung in Cloud Search.

   Normalerweise ist die Push-Ü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 ehesten indexiert werden müssen. Diese werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.

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 dann in den Status ACCEPTED, wenn Cloud Search die Verarbeitung erfolgreich abgeschlossen hat.

Ein Connector kann ein Element auch löschen, wenn es nicht mehr im Repository vorhanden ist, oder es noch einmal per Push übertragen, wenn es nicht geändert wurde oder ein Fehler im Quell-Repository auftritt. Informationen zum Löschen von Elementen finden Sie im nächsten Abschnitt.

Indexierungswarteschlangen zum Löschen von Elementen 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. In diesen Schritten werden die REST API-Aufrufe verwendet. Entsprechende SDK-Aufrufe finden Sie unter Warteschlangenvorgänge (Connector SDK).

1. Beim ersten Durchlauf verwendet der Inhaltsconnector items.push, um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu verschieben („Warteschlange A“ als NEW_ITEM, da diese Elemente in der Warteschlange nicht vorhanden sind). Jedem Element wird das Label „A“ für „Warteschlange A“ zugewiesen. Die Inhalte werden in Cloud Search indexiert.

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 ehesten indexiert werden müssen. Diese werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.

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 dann in den Status ACCEPTED, wenn Cloud Search die Verarbeitung erfolgreich abgeschlossen hat.

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

6. Beim zweiten Durchlauf mit vollständiger Ausführung (Full Traversal) verschiebt der Inhaltsconnector items.push, um Elemente (Metadaten und Hash) in Warteschlange B zu verschieben:

   • Beim Push-Verfahren enthält der Connector explizit ein Push-type oder contentHash.
   • Wenn der Connector type nicht enthält, verwendet Cloud Search automatisch den 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, wird der Status als ACCEPTED beibehalten und das Warteschlangenlabel in „B“ geändert.
   • Wenn das Element vorhanden ist und sich die Hashes unterscheiden, wird der Status zu MODIFIED und das Warteschlangenlabel in „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 ehesten indexiert werden müssen. Diese werden zuerst nach Statuscode und dann nach Zeit in der Warteschlange sortiert.

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

9. Der Connector verwendet items.index, um die Elemente zu indexieren. Das Element wechselt erst dann 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 verwendete Warteschlange und die zum Löschen verwendete Warteschlange ausgetauscht.

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 eine Warteschlange verschieben möchten, verwenden Sie die Builder-Klasse pushItems.

Sie müssen keine speziellen Schritte ausführen, um Elemente zur Verarbeitung aus einer Warteschlange abzurufen. Stattdessen ruft das SDK Elemente mithilfe der Methode getDoc der Klasse Repository automatisch nach Priorität aus der Warteschlange ab.

Vorgänge in der Warteschlange (REST API)

Die REST API bietet die folgenden zwei Methoden, um Elemente in eine Warteschlange bzw. aus einer Warteschlange abzurufen und Elemente daraus abzurufen:

• 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 der Indexierung in die Warteschlange gestellt werden, benötigen keine 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 type-Wert 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.

Beim Senden einer neuen ID wird ein neuer Eintrag mit dem NEW_ITEM-Code ItemStatus hinzugefügt.

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 abgefragte Einträge aufgehoben. 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. Anstelle von type können die Hashwerte für Metadaten und/oder Inhalte mit 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 im Index kein entsprechendes Element 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 bzw. die Status der angeforderten Prioritätswarteschlangen oder den Status der zurückgegebenen IDs an.

Standardmäßig können Einträge aus jedem Abschnitt der Warteschlange je nach Priorität zurückgegeben werden. Jeder zurückgegebene Eintrag ist reserviert und wird bei anderen Aufrufen von Items.poll erst zurückgegeben, wenn einer der folgenden Fälle erfüllt ist:

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