Die Indexierungswarteschlangen für Google Cloud Search

Mit dem Connector SDK und der Google Cloud Search API können Sie Cloud Search Indexierungswarteschlangen, die zum Ausführen der folgenden Aufgaben verwendet werden:

• Dokumentstatus beibehalten (Status, Hashwerte usw.), der bei Bedarf wird verwendet, um Ihren Index mit Ihrem Repository zu synchronisieren.

• Liste der Elemente verwalten, 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 pflegen, z. B. Prüfpunkte, Änderung von Tokens 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 hängt von seiner ItemStatus Code. Im Folgenden sind die möglichen ItemStatus Codes in der Reihenfolge ihrer Priorität (erste und letzte Bearbeitung):

• ERROR: Beim Indexieren des Elements ist ein asynchroner Fehler aufgetreten. und muss neu indexiert werden.

• MODIFIED – Element, das zuvor indexiert und seitdem geändert wurde das Repository seit der letzten Indexierung hinzugefügt wurde.

• NEW_ITEM: Element, das nicht indexiert ist.

• ACCEPTED: Dokument, das zuvor indexiert wurde und im seit der letzten Indexierung.

Wenn zwei Elemente in einer Warteschlange denselben Status haben, erhält das Element Elemente, die sich am längsten in der Warteschlange befinden

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

Abbildung 1 zeigt die Schritte zur Indexierung eines neuen oder geänderten Elements mithilfe einer Indexierung. in die Warteschlange stellen. Diese Schritte zeigen REST API-Aufrufe. Entsprechende SDK-Aufrufe finden Sie unter Vorgänge in der Warteschlange (Connector SDK).

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

<ph type="x-smartling-placeholder">

</ph>

1. Der Inhaltsconnector verwendet items.push um Elemente (Metadaten und Hash) in eine Indexierungswarteschlange zu verschieben, um die Status (MODIFIED, NEW_ITEM, DELETED) Im Detail:

   • Beim Drücken enthält der Connector explizit eine Push-Benachrichtigung type oder contentHash.
   • Wenn type nicht im Connector enthalten ist, kann Cloud Search verwendet contentHash automatisch, um den Status des Artikels zu bestimmen.
   • 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 zur Festlegung des Artikelstatus finden Sie in der GitHub-Repositories durchlaufen Beispielcode in der Einführung in Cloud Search

   Normalerweise wird der Push-Vorgang mit dem Inhaltsdurchlauf und/oder der Änderungserkennung verbunden. von Prozessen im Connector.

2. Der Inhaltsconnector verwendet items.poll , um die Warteschlange abzufragen, um zu indexierende Elemente zu ermitteln. Cloud Search teilt dem Connector mit welche Elemente am meisten indexiert werden müssen. nach Zeit in der Warteschlange.

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

4. Der Connector verwendet items.index um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den Status ACCEPTED die Verarbeitung des Elements abgeschlossen hat.

Ein Connector kann ein Element auch löschen, wenn es im Repository nicht mehr vorhanden ist, oder ein Element erneut verschieben, wenn es nicht geändert wurde oder Quell-Repository-Fehler. Informationen zum Löschen von Elementen finden Sie in den nächsten .

Hinweis: Bei einigen Durchlaufstrategien wie dem vollständigen Durchlauf werden mehrere Durchlaufstrategien verwendet. Indexierungswarteschlange. Ein Beispiel für die Verwendung von zwei Warteschlangen finden Sie in der nächsten Abschnitt.

Indexierungswarteschlangen zum Löschen von Elementen verwenden

Die Full Traversal-Strategie verwendet einen Zwei-Warteschlangen-Prozess, um Elemente zu indexieren. und Löschungen zu erkennen. Abbildung 2 zeigt die Schritte zum Löschen eines Elements mithilfe von Indexierungswarteschlangen. Abbildung 2 zeigt insbesondere den zweiten Durchlauf mit einer Full-Traversal-Strategie. In diesen Schritten werden die REST API-Aufrufe verwendet. Für Entsprechende SDK-Aufrufe finden Sie im Hilfeartikel Warteschlangenvorgänge (Connector SDK).

Abbildung 2. Elemente werden gelöscht

Hinweis: In der folgenden Liste von Schritten sind die Schritte 1–4 in Abbildung 2 nicht als sind dieselben wie die Schritte 1 bis 4 im vorherigen Diagramm und diesem Abschnitt. Schritt 5 wird nicht angezeigt, da der Aufruf deleteQueueItems für eine leere Warteschlange wird in diesem Abschnitt nicht behandelt. Dieses Diagramm konzentriert sich beim zweiten Durchlauf.

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

   Hinweis :Der Connector kann über das Feld queue des Elements ein Warteschlangenlabel zuweisen. eines item.push- oder item.index-Vorgangs hinzufügen. Dieses Label kann wenn das Element neu hochgeladen oder indexiert wird.

2. Der Inhaltsconnector verwendet items.poll um die zu indexierenden Elemente zu ermitteln. Cloud Search teilt dem Connector mit welche Elemente am meisten indexiert werden müssen. nach Zeit in der Warteschlange.

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

4. Der Connector verwendet items.index um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den Status ACCEPTED die Verarbeitung des Elements abgeschlossen hat.

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

6. Beim zweiten Durchlauf mit vollständiger Indexierung items.push um Elemente (Metadaten und Hash) in Warteschlange B zu verschieben:

   • Beim Drücken enthält der Connector explizit eine Push-Benachrichtigung type oder contentHash.
   • Wenn type nicht im Connector enthalten ist, kann Cloud Search verwendet contentHash automatisch, um den Status des Artikels zu bestimmen.
   • Ist das Element unbekannt, wird der Elementstatus auf NEW_ITEM gesetzt und die Warteschlange geändert in "B".
   • Wenn das Element vorhanden ist und die Hashwerte übereinstimmen, wird der Status als ACCEPTED beibehalten. und das Warteschlangenlabel ändert sich in "B".
   • Wenn das Element vorhanden ist und sich die Hashwerte unterscheiden, wird der Status zu MODIFIED und die Warteschlange geändert in "B".

7. Der Inhaltsconnector verwendet items.poll , um die Warteschlange abzufragen, um zu indexierende Elemente zu ermitteln. Cloud Search teilt dem Connector mit welche Elemente am meisten indexiert werden müssen. nach Zeit in der Warteschlange.

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

9. Der Connector verwendet items.index um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den Status ACCEPTED die Verarbeitung des Elements abgeschlossen hat.

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

11. Bei nachfolgenden vollständigen Durchläufen wird die Warteschlange für die Indexierung verwendet. und die zum Löschen verwendete Warteschlange wird vertauscht.

Vorgänge in der Warteschlange (Connector SDK)

Das Content Connector SDK bietet Vorgänge zum Hoch- und Herunterladen von Elementen. aus einer Warteschlange.

Wenn Sie ein Element verpacken und in eine Warteschlange verschieben möchten, verwenden Sie den pushItems Builder-Klasse.

Sie müssen nichts weiter tun, um Elemente aus einer Warteschlange Datenverarbeitung. Stattdessen ruft das SDK die Elemente automatisch nach Priorität aus der Warteschlange ab. mit der Methode Repository-Klasse getDoc .

Vorgänge in der Warteschlange (REST API)

Die REST API bietet die folgenden zwei Methoden, um Elemente per Push an und Elemente aus einer Warteschlange abrufen:

• 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 um Elemente während der Indexierung der Warteschlange hinzuzufügen. Elemente, die während für die Indexierung type und erhalten automatisch den Status ACCEPTED.

Items.push

Die Items.push fügt der Warteschlange IDs hinzu. Diese Methode kann mit einem bestimmten type -Wert, der das Ergebnis des Push-Vorgangs bestimmt. Eine Liste der type-Werte finden Sie unter zu den item.type in Items.push .

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

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

Wenn ein Element abgefragt wird, ist es reserviert, d. h. es kann nicht von einen weiteren Anruf bei Items.poll Mit Items.push mit type als NOT_MODIFIED, REPOSITORY_ERROR oder REQUEUE hebt die Reservierung auf abgefragten Einträge. 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 Hashwerte für Metadaten und Inhalte angegeben werden am Items.index -Anfragen. Anstelle von type, die Metadaten- und/oder Inhalts-Hashwerte kann mit einer Push-Anfrage angegeben werden. In der Cloud Search-Indexierungswarteschlange wird die bereitgestellten Hashwerte mit den gespeicherten Werten, die für das Element im Datenquelle verwendet werden. Bei einer Abweichung wird dieser Eintrag als MODIFIED gekennzeichnet. Wenn eine entsprechende nicht im Index vorhanden ist, lautet der Status NEW_ITEM.

Hinweis: Hashwerte mit Items.push Anfragen werden nicht mit dem Element gespeichert. Anhand dieser Elemente wird lediglich festgestellt, wird das Element geändert.

Items.poll

Die Methode Items.poll ruft die Einträge mit der höchsten Priorität aus der Warteschlange ab. Die angeforderten und zurückgegebene status-Werte den bzw. die Status der die angeforderten Prioritätswarteschlangen oder den Status der zurückgegebenen IDs.

Standardmäßig können Einträge aus jedem Abschnitt der Warteschlange basierend auf Priorität haben. Jeder zurückgegebene Eintrag ist reserviert und wird nicht von anderen Anrufe an Items.poll bis 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 einer type NOT_MODIFIED, REPOSITORY_ERROR oder REQUEUE haben.