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).
<ph type="x-smartling-placeholder">- </ph>
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
odercontentHash
. - Wenn
type
nicht im Connector enthalten ist, kann Cloud Search verwendetcontentHash
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.
- Beim Drücken enthält der Connector explizit eine Push-Benachrichtigung
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.Der Connector ruft diese Elemente aus dem Repository ab und erstellt einen Index. API-Anfragen.
Der Connector verwendet
items.index
um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den StatusACCEPTED
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 .
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).
Beim ersten Durchlauf verwendet der Inhaltsconnector
items.push
um Elemente (Metadaten und Hash) in eine Warteschlange für die Indexierung, „Warteschlange A“, zu verschieben alsNEW_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.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.Der Connector ruft diese Elemente aus dem Repository ab und erstellt einen Index. API-Anfragen.
Der Connector verwendet
items.index
um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den StatusACCEPTED
die Verarbeitung des Elements abgeschlossen hat.Die
deleteQueueItems
wird für Warteschlange B aufgerufen. Es wurden jedoch keine Elemente in Warteschlange B verschoben. kann nichts gelöscht werden.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
odercontentHash
. - Wenn
type
nicht im Connector enthalten ist, kann Cloud Search verwendetcontentHash
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".
- Beim Drücken enthält der Connector explizit eine Push-Benachrichtigung
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.Der Connector ruft diese Elemente aus dem Repository ab und erstellt einen Index. API-Anfragen.
Der Connector verwendet
items.index
um die Elemente zu indexieren. Das Element wechselt erst nach Cloud Search in den StatusACCEPTED
die Verarbeitung des Elements abgeschlossen hat.Schließlich:
deleteQueueItems
wird in Warteschlange A aufgerufen, um alle zuvor indexierten CCloud Search-Elemente zu löschen, die haben noch eine Warteschlange „A“ .Bei nachfolgenden vollständigen Durchläufen wird die Warteschlange für die Indexierung verwendet. und die zum Löschen verwendete Warteschlange vertauscht werden.
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. In die Warteschlange verschobene Elemente 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
.
Items.poll
Die Datei 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 einertype
NOT_MODIFIED
,REPOSITORY_ERROR
oderREQUEUE
haben.