Ein Inhalts-Connector ist ein Softwareprogramm, mit dem die Daten im Repository eines Unternehmens durchsucht und eine Datenquelle ausgefüllt werden. Google bietet folgende Optionen zum Entwickeln von Inhalts-Connectors:
Das Content Connector SDK Dies ist eine gute Option, wenn Sie in Java programmieren. Das Content Connector SDK ist ein Wrapper um die REST API, mit dem Sie schnell Connectors erstellen können. Informationen zum Erstellen eines Inhaltsconnectors mit dem SDK finden Sie unter Mithilfe des Content Connector SDK Inhaltsconnectors erstellen.
Eine Low-Level-REST API oder API-Bibliotheken. Verwenden Sie diese Optionen, wenn Sie nicht in Java programmieren oder wenn Ihre Codebasis besser für eine REST API oder eine Bibliothek geeignet ist. Informationen zum Erstellen eines Inhaltsconnectors mit der REST API finden Sie unter Mithilfe der REST API Inhaltsconnectors erstellen.
Mit einem typischen Inhaltsconnector werden die folgenden Aufgaben ausgeführt:
- Konfigurationsparameter lesen und verarbeiten
- Diskrete Teile indexierbarer Daten, sogenannte Elemente, aus dem Inhalts-Repository eines Drittanbieters abrufen
- ACLs, Metadaten und Inhaltsdaten zu indexierbaren Elementen kombinieren
- Elemente werden in der Cloud Search-Datenquelle indexiert.
- (Optional) Wartet auf Änderungsbenachrichtigungen aus dem Inhalts-Repository des Drittanbieters. Änderungsbenachrichtigungen werden in Indexierungsanfragen umgewandelt, damit die Cloud Search-Datenquelle mit dem Repository des Drittanbieters synchron bleibt. Der Connector führt diese Aufgabe nur aus, wenn das Repository die Änderungserkennung unterstützt.
Mit dem Content Connector SDK Inhaltsconnectors erstellen
In den folgenden Abschnitten wird erläutert, wie Sie mit dem Content Connector SDK einen Inhaltsconnector erstellen.
Abhängigkeiten einrichten
Sie müssen bestimmte Abhängigkeiten in Ihre Build-Datei aufnehmen, um das SDK verwenden zu können. Klicken Sie unten auf einen Tab, um die Abhängigkeiten für Ihre Build-Umgebung aufzurufen:
Maven
<dependency>
<groupId>com.google.enterprise.cloudsearch</groupId>
<artifactId>google-cloudsearch-indexing-connector-sdk</artifactId>
<version>v1-0.0.3</version>
</dependency>
Gradle
compile group: 'com.google.enterprise.cloudsearch',
name: 'google-cloudsearch-indexing-connector-sdk',
version: 'v1-0.0.3'
Connector-Konfiguration erstellen
Jeder Connector hat eine Konfigurationsdatei mit Parametern, die vom Connector verwendet werden, z. B. die ID für Ihr Repository. Parameter werden als Schlüssel/Wert-Paare definiert, z. B. api.sourceId=1234567890abcdef
.
Das Google Cloud Search SDK enthält mehrere von Google bereitgestellte Konfigurationsparameter, die von allen Connectors verwendet werden. Sie müssen die folgenden von Google bereitgestellten Parameter in Ihrer Konfigurationsdatei angeben:
- Für einen Inhaltsconnector benötigen Sie die Parameter
api.sourceId
undapi.serviceAccountPrivateKeyFile
, da diese den Speicherort des Repositorys und des privaten Schlüssels angeben, die für den Zugriff auf das Repository erforderlich sind.
- Für einen Identitätsconnector müssen Sie den Parameter
api.identitySourceId
deklarieren, da dieser den Speicherort Ihrer externen Identitätsquelle angibt. Wenn Sie Nutzer synchronisieren, müssen Sie auchapi.customerId
als eindeutige ID für das Google Workspace-Konto Ihres Unternehmens deklarieren.
Sofern Sie die Standardwerte anderer von Google bereitgestellter Parameter nicht überschreiben möchten, müssen Sie sie nicht in Ihrer Konfigurationsdatei angeben. Weitere Informationen zu den von Google bereitgestellten Konfigurationsparametern, z. B. wie Sie bestimmte IDs und Schlüssel generieren, finden Sie unter Von Google bereitgestellte Konfigurationsparameter.
Sie können auch eigene Repository-spezifische Parameter zur Verwendung in Ihrer Konfigurationsdatei definieren.
Konfigurationsdatei an den Connector übergeben
Legen Sie das Systemattribut config
fest, um die Konfigurationsdatei an den Connector zu übergeben. Sie können das Attribut mit dem Argument -D
festlegen, wenn Sie den Connector starten. Mit dem folgenden Befehl wird beispielsweise der Connector mit der Konfigurationsdatei MyConfig.properties
gestartet:
java -classpath myconnector.jar;... -Dconfig=MyConfig.properties MyConnector
Wenn dieses Argument fehlt, versucht das SDK, auf eine Standardkonfigurationsdatei mit dem Namen connector-config.properties
zuzugreifen.
Durchlaufstrategie festlegen
Die Hauptfunktion eines Inhaltsconnectors besteht darin, ein Repository zu durchsuchen und die darin enthaltenen Daten zu indexieren. Sie müssen eine Durchlaufstrategie implementieren, die auf der Größe und dem Layout der Daten in Ihrem Repository basiert. Du kannst deine eigene Strategie entwerfen oder aus den folgenden im SDK implementierten Strategien auswählen:
- Durchlauf mit vollständiger Indexierung (Full Traversal)
Bei dieser Strategie wird das gesamte Repository gescannt und blind indexiert. Diese Strategie wird häufig verwendet, wenn Sie ein kleines Repository haben und es sich leisten kann, bei jeder Indexierung einen vollständigen Durchlauf durchzuführen.
Diese Durchlaufstrategie eignet sich für kleine Repositories mit hauptsächlich statischen, nicht hierarchischen Daten. Sie können diese Durchlaufstrategie auch verwenden, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird.
- Durchlauf mit Teilindexierung (List Traversal)
Bei einer List Traversal-Strategie wird das gesamte Repository einschließlich aller untergeordneten Knoten gescannt, um den Status der einzelnen Elemente zu bestimmen. Anschließend führt der Connector einen zweiten Durchlauf aus und indexiert nur Elemente, die neu sind oder seit der letzten Indexierung aktualisiert wurden. Diese Strategie wird häufig verwendet, um inkrementelle Aktualisierungen an einem vorhandenen Index vorzunehmen, anstatt bei jeder Aktualisierung des Index einen vollständigen Durchlauf durchzuführen.
Diese Durchlaufstrategie ist geeignet, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird, Sie nicht hierarchische Daten haben und mit sehr großen Datasets arbeiten.
- Graph Traversal
Bei dieser Strategie wird der gesamte übergeordnete Knoten gescannt, um den Status der einzelnen Elemente zu ermitteln. Anschließend macht der Connector einen zweiten Durchlauf und indexiert nur Elemente im Stammknoten, die neu sind oder seit der letzten Indexierung aktualisiert wurden. Schließlich übergibt der Connector alle untergeordneten IDs und indexiert dann Elemente in den untergeordneten Knoten, die neu sind oder aktualisiert wurden. Der Connector durchläuft rekursiv alle untergeordneten Knoten, bis alle Elemente adressiert sind. Ein solcher Durchlauf wird normalerweise für hierarchische Repositories verwendet, bei denen das Auflisten aller IDs nicht praktikabel ist.
Diese Strategie eignet sich, wenn Sie hierarchische Daten haben, die gecrawlt werden müssen, z. B. eine Reihe von Verzeichnissen oder Webseiten.
Jede dieser Durchlaufstrategien wird im SDK von einer Vorlagen-Connector-Klasse implementiert. Sie können zwar eine eigene Durchlaufstrategie implementieren, diese Vorlagen beschleunigen jedoch die Entwicklung Ihres Connectors erheblich. Wenn Sie einen Connector mithilfe einer Vorlage erstellen möchten, fahren Sie mit dem Abschnitt fort, der Ihrer Durchlaufstrategie entspricht:
- Mithilfe einer Vorlagenklasse einen „Full Traversal“-Connector erstellen
- List Traversal-Connector mithilfe einer Vorlagenklasse erstellen
- Graph Traversal-Connector mithilfe einer Vorlagenklasse erstellen
Mit einer Vorlagenklasse einen „Full Traversal“-Connector erstellen
Dieser Abschnitt bezieht sich auf Code-Snippets aus dem Beispiel FullTraversalSample.
Einstiegspunkt des Connectors implementieren
Der Einstiegspunkt für einen Connector ist die Methode main()
. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz der Klasse Application
zu erstellen und die Methode start()
aufzurufen, um den Connector auszuführen.
Verwenden Sie die Klasse IndexingApplication.Builder
, um die Vorlage FullTraversalConnector
zu instanziieren, bevor Sie application.start()
aufrufen. Für FullTraversalConnector
wird ein Repository
-Objekt akzeptiert, dessen Methoden Sie implementieren. Das folgende Code-Snippet zeigt, wie die Methode main()
implementiert wird:
Das SDK ruft die Methode initConfig()
im Hintergrund auf, nachdem Application.build
von der Methode main()
des Connectors aufgerufen wurde.
Die Methode initConfig()
führt die folgenden Aufgaben aus:
- Ruft die Methode
Configuation.isInitialized()
auf, um zu prüfen, obConfiguration
noch initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit den von Google bereitgestellten Schlüssel/Wert-Paaren. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
-Objekt innerhalb desConfiguration
-Objekts gespeichert.
Repository
-Oberfläche implementieren
Die einzige Aufgabe des Repository
-Objekts besteht darin, Repository-Elemente zu durchsuchen und zu indexieren. Wenn Sie eine Vorlage verwenden, müssen Sie nur bestimmte Methoden innerhalb der Repository
-Oberfläche überschreiben, um einen Inhaltsconnector zu erstellen. Welche Methoden Sie überschreiben, hängt von der verwendeten Vorlage und der Durchlaufstrategie ab. Überschreiben Sie für FullTraversalConnector
die folgenden Methoden:
Die Methode
init()
. Wenn Sie ein Daten-Repository einrichten und initialisieren möchten, überschreiben Sie die Methodeinit()
.Die Methode
getAllDocs()
. Wenn alle Elemente im Daten-Repository durchsucht und indexiert werden sollen, überschreiben Sie die MethodegetAllDocs()
. Diese Methode wird für jeden geplanten Durchlauf einmal aufgerufen (wie in Ihrer Konfiguration definiert).Optional: Die Methode
getChanges()
. Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie die MethodegetChanges()
. Diese Methode wird für jeden geplanten inkrementellen Durchlauf (wie in Ihrer Konfiguration definiert) einmal aufgerufen, um die geänderten Elemente abzurufen und zu indexieren.Optional: Die Methode
close()
. Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie die Methodeclose()
. Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.
Für jede der Methoden des Repository
-Objekts wird ein Objekt vom Typ ApiOperation
zurückgegeben. Ein ApiOperation
-Objekt führt eine Aktion in Form eines einzelnen oder möglicherweise mehrerer IndexingService.indexItem()
-Aufrufe aus, um die tatsächliche Indexierung Ihres Repositorys durchzuführen.
Benutzerdefinierte Konfigurationsparameter abrufen
Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration
-Objekt abrufen. Diese Aufgabe wird normalerweise in der Methode init()
der Klasse Repository
ausgeführt.
Die Klasse Configuration
bietet mehrere Methoden, unterschiedliche Datentypen aus einer Konfiguration abzurufen. Bei jeder Methode wird ein ConfigValue
-Objekt zurückgegeben. Anschließend verwenden Sie die Methode get()
des ConfigValue
-Objekts, um den tatsächlichen Wert abzurufen.
Das folgende Snippet aus FullTraversalSample
zeigt, wie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration
-Objekt abgerufen wird:
Wenn Sie einen Parameter mit mehreren Werten abrufen und parsen möchten, verwenden Sie einen der Typparser der Configuration
-Klasse, um die Daten in separate Blöcke zu parsen.
Das folgende Snippet aus dem Connector für die Anleitung verwendet die Methode getMultiValue
, um eine Liste der GitHub-Repository-Namen abzurufen:
Full-Traversal durchführen
Überschreiben Sie getAllDocs()
, um einen vollständigen Durchlauf (Full Traversal) durchzuführen und das Repository zu indexieren. Die Methode getAllDocs()
akzeptiert einen Prüfpunkt. Er wird verwendet, um die Indexierung bei einem bestimmten Element fortzusetzen, sollte der Prozess unterbrochen werden. Führen Sie für jedes Element in Ihrem Repository die folgenden Schritte in der Methode getAllDocs()
aus:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Kombinieren Sie die Metadaten und das Element in einer indexierbaren
RepositoryDoc
. - Packen Sie jedes indexierbare Element in einen Iterator, der von der Methode
getAllDocs()
zurückgegeben wird.getAllDocs()
gibt tatsächlich einCheckpointCloseableIterable
zurück, bei dem es sich um eine Iteration vonApiOperation
-Objekten handelt. Jedes Objekt steht für eine API-Anfrage, die für einenRepositoryDoc
ausgeführt wird, z. B. die Indexierung.
Wenn die Gruppe von Elementen zu groß ist, um in einem einzigen Aufruf zu verarbeiten, fügen Sie einen Checkpoint ein und legen Sie hasMore(true)
fest, um anzugeben, dass mehr Elemente für die Indexierung verfügbar sind.
Berechtigungen für ein Element festlegen
In Ihrem Repository wird eine Zugriffssteuerungsliste (Access Control List, ACL) verwendet, um die Nutzer oder Gruppen zu identifizieren, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer, die auf das Element zugreifen können.
Du musst die ACL deines Repositorys duplizieren, damit nur Nutzer mit Zugriff auf ein Element dieses Element in den Suchergebnissen sehen können. Die ACL für ein Element muss beim Indexieren enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene für das Element bereitzustellen.
Das Content Connector SDK bietet zahlreiche ACL-Klassen und -Methoden, mit denen sich die ACLs der meisten Repositories modellieren lassen. Sie müssen die ACL für jedes Element in Ihrem Repository analysieren und eine entsprechende ACL für Google Cloud Search erstellen, wenn Sie ein Element indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL-Vererbung verwendet werden, kann es schwierig sein, diese ACL zu modellieren. Weitere Informationen zu ACLs von Google Cloud Search
Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Domainübergreifende ACLs werden nicht unterstützt. Verwenden Sie die Klasse Acl.Builder
, um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Mit dem folgenden Code-Snippet aus dem Beispiel für den vollständigen Durchlauf können alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()
) beim Durchführen einer Suche „Leser“ aller Elemente (.setReaders()
) sein.
Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Beispiel: Sie indexieren möglicherweise Dateien in einem Dateisystem, das ein Vererbungsmodell verwendet, bei dem untergeordnete Ordner Berechtigungen von übergeordneten Ordnern übernehmen. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich. Weitere Informationen finden Sie unter ACLs in Google Cloud Search.
Metadaten für ein Element festlegen
Metadaten werden in einem Item
-Objekt gespeichert. Zum Erstellen eines Item
benötigen Sie mindestens die folgenden Angaben: die eindeutige String-ID, den Elementtyp, die ACL, die URL und die Elementversion.
Das folgende Code-Snippet zeigt, wie ein Item
mit der Helper-Klasse IndexingItemBuilder
erstellt wird.
Indexierbares Element erstellen
Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie mit der Klasse RepositoryDoc.Builder
das tatsächliche indexierbare Element erstellen. Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.
Ein RepositoryDoc
ist ein ApiOperation
-Typ, der die eigentliche IndexingService.indexItem()
-Anfrage ausführt.
Sie können auch die Methode setRequestMode()
der Klasse RepositoryDoc.Builder
verwenden, um die Indexierungsanfrage als ASYNCHRONOUS
oder SYNCHRONOUS
zu identifizieren:
ASYNCHRONOUS
- Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung und eignet sich für ein hohes Durchsatzkontingent bei Indexierungsanfragen. Der asynchrone Modus wird für die anfängliche Indexierung (Backfill) des gesamten Repositorys empfohlen.
SYNCHRONOUS
- Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung geringer und er eignet sich für ein begrenztes Durchsatzkontingent. Der synchrone Modus wird für die Indexierung von Updates und Änderungen am Repository empfohlen. Wenn keine Angabe erfolgt, wird standardmäßig der Anfragemodus
SYNCHRONOUS
verwendet.
Jedes indexierbare Element in einen Iterator verpacken
Die Methode getAllDocs()
gibt ein Iterator
zurück, genauer gesagt ein CheckpointCloseableIterable
von RepositoryDoc
-Objekten. Sie können die Klasse CheckpointClosableIterableImpl.Builder
verwenden, um einen Iterator zu erstellen und zurückzugeben. Das folgende Code-Snippet zeigt, wie ein Iterator erstellt und zurückgegeben wird.
Das SDK führt jeden Indexierungsaufruf aus, der im Iterator enthalten ist.
Nächste Schritte
Als Nächstes könnten Sie Folgendes tun:
- Optional: Wenn Ihr Indexierungsdurchsatz zu niedrig zu sein scheint, lesen Sie den Hilfeartikel Indexierungsrate für
FullTraversalConnector
erhöhen. - Optional: Methode
close()
implementieren, um vor dem Herunterfahren alle Ressourcen freizugeben - Optional: Mit dem Content Connector SDK einen Identitätsconnector erstellen
List Traversal-Connector mithilfe einer Vorlagenklasse erstellen
Die Cloud Search-Indexierungswarteschlange enthält IDs und optionale Hashwerte für jedes Element im Repository. Ein List Traversal-Connector überträgt Element-IDs per Push in die Indexierungswarteschlange von Google Cloud Search und ruft sie nacheinander für die Indexierung ab. In Google Cloud Search werden Warteschlangen verwaltet und Inhalte verglichen, um den Status von Elementen zu ermitteln, z. B. ob ein Element aus dem Repository gelöscht wurde. Weitere Informationen zur Indexierungswarteschlange von Cloud Search
Dieser Abschnitt bezieht sich auf Code-Snippets aus dem Beispiel ListTraversalSample.
Einstiegspunkt des Connectors implementieren
Der Einstiegspunkt für einen Connector ist die Methode main()
. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz der Klasse Application
zu erstellen und die Methode start()
aufzurufen, um den Connector auszuführen.
Verwenden Sie die Klasse IndexingApplication.Builder
, um die Vorlage ListingConnector
zu instanziieren, bevor Sie application.start()
aufrufen. Für ListingConnector
wird ein Repository
-Objekt akzeptiert, dessen Methoden Sie implementieren. Das folgende Snippet zeigt, wie ListingConnector
und das zugehörige Repository
instanziiert werden:
Das SDK ruft die Methode initConfig()
im Hintergrund auf, nachdem Application.build
von der Methode main()
des Connectors aufgerufen wurde.
Die Methode initConfig()
:
- Ruft die Methode
Configuation.isInitialized()
auf, um zu prüfen, obConfiguration
noch initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit den von Google bereitgestellten Schlüssel/Wert-Paaren. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
-Objekt innerhalb desConfiguration
-Objekts gespeichert.
Repository
-Oberfläche implementieren
Die einzige Aufgabe des Repository
-Objekts besteht darin, Repository-Elemente zu durchsuchen und zu indexieren. Wenn Sie eine Vorlage verwenden, müssen Sie nur bestimmte Methoden innerhalb der Repository
-Schnittstelle überschreiben, um einen Inhaltsconnector zu erstellen.
Welche Methoden Sie überschreiben, hängt von der verwendeten Vorlage und der Durchlaufstrategie ab. Überschreiben Sie für ListingConnector
die folgenden Methoden:
Die Methode
init()
. Wenn Sie ein Daten-Repository einrichten und initialisieren möchten, überschreiben Sie die Methodeinit()
.Die Methode
getIds()
. Wenn Sie IDs und Hashwerte für alle Datensätze im Repository abrufen möchten, überschreiben Sie die MethodegetIds()
.Die Methode
getDoc()
. Wenn Sie im Index Elemente hinzufügen, aktualisieren, ändern oder löschen möchten, überschreiben Sie die MethodegetDoc()
.Optional: Die Methode
getChanges()
. Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie die MethodegetChanges()
. Diese Methode wird für jeden geplanten inkrementellen Durchlauf (wie in Ihrer Konfiguration definiert) einmal aufgerufen, um die geänderten Elemente abzurufen und zu indexieren.Optional: Die Methode
close()
. Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie die Methodeclose()
. Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.
Für jede der Methoden des Repository
-Objekts wird ein Objekt vom Typ ApiOperation
zurückgegeben. Ein ApiOperation
-Objekt führt eine Aktion in Form eines einzelnen oder möglicherweise mehrerer IndexingService.indexItem()
-Aufrufe aus, um die tatsächliche Indexierung Ihres Repositorys durchzuführen.
Benutzerdefinierte Konfigurationsparameter abrufen
Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration
-Objekt abrufen. Diese Aufgabe wird normalerweise in der Methode init()
der Klasse Repository
ausgeführt.
Die Klasse Configuration
bietet mehrere Methoden, unterschiedliche Datentypen aus einer Konfiguration abzurufen. Bei jeder Methode wird ein ConfigValue
-Objekt zurückgegeben. Anschließend verwenden Sie die Methode get()
des ConfigValue
-Objekts, um den tatsächlichen Wert abzurufen.
Das folgende Snippet aus FullTraversalSample
zeigt, wie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration
-Objekt abgerufen wird:
Wenn Sie einen Parameter mit mehreren Werten abrufen und parsen möchten, verwenden Sie einen der Typparser der Configuration
-Klasse, um die Daten in separate Blöcke zu parsen.
Das folgende Snippet aus dem Connector für die Anleitung verwendet die Methode getMultiValue
, um eine Liste der GitHub-Repository-Namen abzurufen:
List Traversal durchführen
Überschreiben Sie die Methode getIds()
, um IDs und Hashwerte für alle Datensätze im Repository abzurufen.
An die Methode getIds()
kann ein Prüfpunkt übergeben werden. Dieser dient dazu, die Indexierung bei einem bestimmten Element fortzusetzen, sollte der Prozess unterbrochen werden.
Als Nächstes überschreiben Sie die Methode getDoc()
, um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten.
Element-IDs und Hashwerte per Push übertragen
Überschreiben Sie getIds()
, um die Element-IDs und die zugehörigen Inhalts-Hashwerte aus dem Repository abzurufen. ID- und Hashwert-Paare werden dann in eine Push-Vorgangsanfrage an die Cloud Search-Indexierungswarteschlange gepackt. Stamm- oder übergeordnete IDs werden normalerweise zuerst übertragen, gefolgt von untergeordneten IDs, bis die gesamte Hierarchie der Elemente verarbeitet wurde.
An die Methode getIds()
kann ein Prüfpunkt übergeben werden, der das letzte zu indexierende Element darstellt. Er kann verwendet werden, um die Indexierung bei einem bestimmten Element fortzusetzen, sollte der Prozess unterbrochen werden. Führen Sie für jedes Element in Ihrem Repository die folgenden Schritte in der Methode getIds()
aus:
- Rufen Sie jede Artikel-ID und den zugehörigen Hashwert aus dem Repository ab.
- Verpacken Sie jedes ID-Hashwert-Paar in eine
PushItems
. - Kombinieren Sie alle
PushItems
in einem Iterator, der von der MethodegetIds()
zurückgegeben wird.getIds()
gibt tatsächlich einCheckpointCloseableIterable
zurück, bei dem es sich um eine Iteration vonApiOperation
-Objekten handelt. Jedes Objekt steht für eine API-Anfrage, die an einemRepositoryDoc
ausgeführt wird, z. B. durch Push in die Warteschlange.
Im folgenden Code-Snippet sehen Sie, wie Sie die einzelnen Element-IDs und Hashwerte abrufen und in eine PushItems
einfügen.
PushItems
ist eine ApiOperation
-Anfrage, mit der ein Element in die Cloud Search-Indexierungswarteschlange aufgenommen wird.
Das folgende Code-Snippet zeigt, wie die Klasse PushItems.Builder
verwendet wird, um die IDs und Hashwerte in eine einzelne Push-ApiOperation
zu verpacken.
Elemente werden zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange verschoben.
Jedes Element abrufen und verarbeiten
Überschreiben Sie getDoc()
, um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten.
Ein Element kann neu, geändert oder unverändert sein oder nicht mehr im Quell-Repository vorhanden sein. Rufen Sie jedes neue oder geänderte Element ab und indexieren Sie es. Entfernen Sie Elemente aus dem Index, die nicht mehr im Quell-Repository vorhanden sind.
Die Methode getDoc()
akzeptiert ein Element aus der Google Cloud Search-Indexierungswarteschlange. Führen Sie für jedes Element in der Warteschlange die folgenden Schritte in der Methode getDoc()
aus:
Prüfen Sie, ob die ID des Elements aus der Cloud Search-Indexierungswarteschlange im Repository vorhanden ist. Ist dies nicht der Fall, löschen Sie das Element aus dem Index.
Fragen Sie im Index den Status des Elements ab. Wenn ein Element unverändert ist (
ACCEPTED
), tun Sie nichts.Indexieren Sie geänderte oder neue Elemente:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Kombinieren Sie die Metadaten und das Element in einer indexierbaren
RepositoryDoc
. - Geben Sie
RepositoryDoc
zurück.
Hinweis:Die Vorlage ListingConnector
unterstützt nicht die Rückgabe von null
für die Methode getDoc()
. Die Rückgabe von null
führt zu einem NullPointerException.
.
Umgang mit gelöschten Elementen
Das folgende Code-Snippet zeigt, wie Sie feststellen, ob ein Element im Repository vorhanden ist, und es gegebenenfalls löschen.
Beachten Sie, dass documents
eine Datenstruktur ist, die das Repository darstellt. Wenn documentID
in documents
nicht gefunden wird, geben Sie APIOperations.deleteItem(resourceName)
zurück, um das Element aus dem Index zu löschen.
Umgang mit unveränderten Elementen
Das folgende Code-Snippet zeigt, wie Sie den Status von Elementen in der Cloud Search-Indexierungswarteschlange abfragen und mit unveränderten Elementen umgehen.
Wenn Sie feststellen möchten, ob das Element unverändert ist, prüfen Sie den Status des Elements sowie andere Metadaten, die auf eine Änderung hinweisen können. In diesem Beispiel wird der Metadaten-Hash verwendet, um festzustellen, ob das Element geändert wurde.
Berechtigungen für ein Element festlegen
In Ihrem Repository wird eine Zugriffssteuerungsliste (Access Control List, ACL) verwendet, um die Nutzer oder Gruppen zu identifizieren, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer, die auf das Element zugreifen können.
Du musst die ACL deines Repositorys duplizieren, damit nur Nutzer mit Zugriff auf ein Element dieses Element in den Suchergebnissen sehen können. Die ACL für ein Element muss beim Indexieren enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene für das Element bereitzustellen.
Das Content Connector SDK bietet zahlreiche ACL-Klassen und -Methoden, mit denen sich die ACLs der meisten Repositories modellieren lassen. Sie müssen die ACL für jedes Element in Ihrem Repository analysieren und eine entsprechende ACL für Google Cloud Search erstellen, wenn Sie ein Element indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL-Vererbung verwendet werden, kann es schwierig sein, diese ACL zu modellieren. Weitere Informationen zu ACLs von Google Cloud Search
Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Domainübergreifende ACLs werden nicht unterstützt. Verwenden Sie die Klasse Acl.Builder
, um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Mit dem folgenden Code-Snippet aus dem Beispiel für den vollständigen Durchlauf können alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()
) beim Durchführen einer Suche „Leser“ aller Elemente (.setReaders()
) sein.
Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Beispiel: Sie indexieren möglicherweise Dateien in einem Dateisystem, das ein Vererbungsmodell verwendet, bei dem untergeordnete Ordner Berechtigungen von übergeordneten Ordnern übernehmen. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich. Weitere Informationen finden Sie unter ACLs in Google Cloud Search.
Metadaten für ein Element festlegen
Metadaten werden in einem Item
-Objekt gespeichert. Zum Erstellen eines Item
benötigen Sie mindestens die folgenden Angaben: die eindeutige String-ID, den Elementtyp, die ACL, die URL und die Elementversion.
Das folgende Code-Snippet zeigt, wie ein Item
mit der Helper-Klasse IndexingItemBuilder
erstellt wird.
Indexierbares Element erstellen
Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie mit RepositoryDoc.Builder
das tatsächliche indexierbare Element erstellen.
Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.
Ein RepositoryDoc
ist ein ApiOperation
-Typ, der die eigentliche IndexingService.indexItem()
-Anfrage ausführt.
Sie können auch die Methode setRequestMode()
der Klasse RepositoryDoc.Builder
verwenden, um die Indexierungsanfrage als ASYNCHRONOUS
oder SYNCHRONOUS
zu identifizieren:
ASYNCHRONOUS
- Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung und eignet sich für ein hohes Durchsatzkontingent bei Indexierungsanfragen. Der asynchrone Modus wird für die anfängliche Indexierung (Backfill) des gesamten Repositorys empfohlen.
SYNCHRONOUS
- Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung geringer und er eignet sich für ein begrenztes Durchsatzkontingent. Der synchrone Modus wird für die Indexierung von Updates und Änderungen am Repository empfohlen. Wenn keine Angabe erfolgt, wird standardmäßig der Anfragemodus
SYNCHRONOUS
verwendet.
Nächste Schritte
Als Nächstes könnten Sie Folgendes tun:
- Optional: Methode
close()
implementieren, um vor dem Herunterfahren alle Ressourcen freizugeben - Optional: Mit dem Content Connector SDK einen Identitätsconnector erstellen
Graph Traversal-Connector mithilfe einer Vorlagenklasse erstellen
Die Cloud Search-Indexierungswarteschlange enthält IDs und optionale Hashwerte für jedes Element im Repository. Ein Graph Traversal-Connector überträgt Element-IDs in die Indexierungswarteschlange von Google Cloud Search und ruft sie nacheinander zur Indexierung ab. In Google Cloud Search werden Warteschlangen verwaltet und Inhalte verglichen, um den Status der Elemente zu ermitteln, z. B. ob ein Element aus dem Repository gelöscht wurde. Weitere Informationen zur Indexierungswarteschlange von Google Cloud Search
Während des Indexierens wird der Artikelinhalt aus dem Daten-Repository abgerufen und alle untergeordneten Element-IDs werden in die Warteschlange verschoben. Der Connector verarbeitet dann rekursiv die übergeordneten und untergeordneten IDs, bis alle Elemente verarbeitet wurden.
Dieser Abschnitt bezieht sich auf Code-Snippets aus dem Beispiel GraphTraversalSample.
Einstiegspunkt des Connectors implementieren
Der Einstiegspunkt für einen Connector ist die Methode main()
. Die Hauptaufgabe dieser Methode besteht darin, eine Instanz der Klasse Application
zu erstellen und die Methode start()
aufzurufen, um den Connector auszuführen.
Verwenden Sie die Klasse IndexingApplication.Builder
, um die Vorlage ListingConnector
zu instanziieren, bevor Sie application.start()
aufrufen. Für ListingConnector
wird ein Repository
-Objekt akzeptiert, dessen Methoden Sie implementieren.
Das folgende Snippet zeigt, wie ListingConnector
und das zugehörige Repository
instanziiert werden:
Das SDK ruft die Methode initConfig()
im Hintergrund auf, nachdem Application.build
von der Methode main()
des Connectors aufgerufen wurde.
Die Methode initConfig()
:
- Ruft die Methode
Configuation.isInitialized()
auf, um zu prüfen, obConfiguration
noch initialisiert wurde. - Initialisiert ein
Configuration
-Objekt mit den von Google bereitgestellten Schlüssel/Wert-Paaren. Jedes Schlüssel/Wert-Paar wird in einemConfigValue
-Objekt innerhalb desConfiguration
-Objekts gespeichert.
Repository
-Oberfläche implementieren
Die einzige Aufgabe des Repository
-Objekts besteht darin, Repository-Elemente zu durchsuchen und zu indexieren. Wenn Sie eine Vorlage verwenden, müssen Sie nur bestimmte Methoden in der Repository
-Schnittstelle überschreiben, um einen Inhaltsconnector zu erstellen. Welche Methoden Sie überschreiben, hängt von der verwendeten Vorlage und Durchlaufstrategie ab. Für ListingConnector
überschreiben Sie die folgenden Methoden:
Die Methode
init()
. Wenn Sie ein Daten-Repository einrichten und initialisieren möchten, überschreiben Sie die Methodeinit()
.Die Methode
getIds()
. Wenn Sie IDs und Hashwerte für alle Datensätze im Repository abrufen möchten, überschreiben Sie die MethodegetIds()
.Die Methode
getDoc()
. Wenn Sie im Index Elemente hinzufügen, aktualisieren, ändern oder löschen möchten, überschreiben Sie die MethodegetDoc()
.Optional: Die Methode
getChanges()
. Wenn Ihr Repository die Änderungserkennung unterstützt, überschreiben Sie die MethodegetChanges()
. Diese Methode wird für jeden geplanten inkrementellen Durchlauf (wie in Ihrer Konfiguration definiert) einmal aufgerufen, um die geänderten Elemente abzurufen und zu indexieren.Optional: Die Methode
close()
. Wenn Sie eine Repository-Bereinigung ausführen müssen, überschreiben Sie die Methodeclose()
. Diese Methode wird einmal beim Herunterfahren des Connectors aufgerufen.
Für jede der Methoden des Repository
-Objekts wird ein ApiOperation
-Objekttyp zurückgegeben. Ein ApiOperation
-Objekt führt eine Aktion in Form eines einzelnen oder möglicherweise mehrerer IndexingService.indexItem()
-Aufrufe aus, um die tatsächliche Indexierung Ihres Repositorys durchzuführen.
Benutzerdefinierte Konfigurationsparameter abrufen
Im Rahmen der Konfiguration des Connectors müssen Sie alle benutzerdefinierten Parameter aus dem Configuration
-Objekt abrufen. Diese Aufgabe wird normalerweise in der Methode init()
der Klasse Repository
ausgeführt.
Die Klasse Configuration
bietet mehrere Methoden, unterschiedliche Datentypen aus einer Konfiguration abzurufen. Bei jeder Methode wird ein ConfigValue
-Objekt zurückgegeben. Anschließend verwenden Sie die Methode get()
des ConfigValue
-Objekts, um den tatsächlichen Wert abzurufen.
Das folgende Snippet aus FullTraversalSample
zeigt, wie ein einzelner benutzerdefinierter Ganzzahlwert aus einem Configuration
-Objekt abgerufen wird:
Wenn Sie einen Parameter mit mehreren Werten abrufen und parsen möchten, verwenden Sie einen der Typparser der Configuration
-Klasse, um die Daten in separate Blöcke zu parsen.
Das folgende Snippet aus dem Connector für die Anleitung verwendet die Methode getMultiValue
, um eine Liste der GitHub-Repository-Namen abzurufen:
Graph Traversal durchführen
Überschreiben Sie die Methode getIds()
, um IDs und Hashwerte für alle Datensätze im Repository abzurufen.
An die Methode getIds()
kann ein Prüfpunkt übergeben werden. Dieser dient dazu, die Indexierung bei einem bestimmten Element fortzusetzen, sollte der Prozess unterbrochen werden.
Als Nächstes überschreiben Sie die Methode getDoc()
, um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten.
Element-IDs und Hashwerte per Push übertragen
Überschreiben Sie getIds()
, um die Element-IDs und die zugehörigen Inhalts-Hashwerte aus dem Repository abzurufen. ID- und Hashwert-Paare werden dann in eine Push-Vorgangsanfrage an die Cloud Search-Indexierungswarteschlange gepackt. Stamm- oder übergeordnete IDs werden normalerweise zuerst übertragen, gefolgt von untergeordneten IDs, bis die gesamte Hierarchie der Elemente verarbeitet wurde.
An die Methode getIds()
kann ein Prüfpunkt übergeben werden, der das letzte zu indexierende Element darstellt. Er kann verwendet werden, um die Indexierung bei einem bestimmten Element fortzusetzen, sollte der Prozess unterbrochen werden. Führen Sie für jedes Element in Ihrem Repository die folgenden Schritte in der Methode getIds()
aus:
- Rufen Sie jede Artikel-ID und den zugehörigen Hashwert aus dem Repository ab.
- Verpacken Sie jedes ID-Hashwert-Paar in eine
PushItems
. - Kombinieren Sie alle
PushItems
in einem Iterator, der von der MethodegetIds()
zurückgegeben wird.getIds()
gibt tatsächlich einCheckpointCloseableIterable
zurück, bei dem es sich um eine Iteration vonApiOperation
-Objekten handelt. Jedes Objekt steht für eine API-Anfrage, die an einemRepositoryDoc
ausgeführt wird, z. B. durch Push in die Warteschlange.
Im folgenden Code-Snippet sehen Sie, wie Sie die einzelnen Element-IDs und Hashwerte abrufen und in ein PushItems
einfügen. Eine PushItems
ist eine ApiOperation
-Anfrage, mit der ein Element in die Cloud Search-Indexierungswarteschlange aufgenommen wird.
Das folgende Code-Snippet zeigt, wie Sie die Klasse PushItems.Builder
verwenden, um die IDs und Hashwerte in einem einzigen Push-ApiOperation
zu verpacken.
Elemente werden zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange verschoben.
Jedes Element abrufen und verarbeiten
Überschreiben Sie getDoc()
, um jedes Element in der Cloud Search-Indexierungswarteschlange zu verarbeiten.
Ein Element kann neu, geändert oder unverändert sein oder nicht mehr im Quell-Repository vorhanden sein. Rufen Sie jedes neue oder geänderte Element ab und indexieren Sie es. Entfernen Sie Elemente aus dem Index, die nicht mehr im Quell-Repository vorhanden sind.
Die Methode getDoc()
akzeptiert ein Element aus der Cloud Search-Indexierungswarteschlange. Führen Sie für jedes Element in der Warteschlange die folgenden Schritte in der Methode getDoc()
aus:
Prüfen Sie, ob die ID des Elements aus der Cloud Search-Indexierungswarteschlange im Repository vorhanden ist. Ist dies nicht der Fall, löschen Sie das Element aus dem Index. Ist das Element vorhanden, fahren Sie mit dem nächsten Schritt fort.
Indexieren Sie geänderte oder neue Elemente:
- Legen Sie die Berechtigungen fest.
- Legen Sie die Metadaten für das Element fest, das Sie indexieren.
- Kombinieren Sie die Metadaten und das Element in einer indexierbaren
RepositoryDoc
. - Fügen Sie die untergeordneten IDs zur weiteren Verarbeitung in die Cloud Search-Indexierungswarteschlange ein.
- Geben Sie
RepositoryDoc
zurück.
Umgang mit gelöschten Elementen
Im folgenden Code-Snippet sehen Sie, wie Sie feststellen, ob ein Element im Index vorhanden ist, und es gegebenenfalls löschen.
Berechtigungen für ein Element festlegen
In Ihrem Repository wird eine Zugriffssteuerungsliste (Access Control List, ACL) verwendet, um die Nutzer oder Gruppen zu identifizieren, die Zugriff auf ein Element haben. Eine ACL ist eine Liste von IDs für Gruppen oder Nutzer, die auf das Element zugreifen können.
Du musst die ACL deines Repositorys duplizieren, damit nur Nutzer mit Zugriff auf ein Element dieses Element in den Suchergebnissen sehen können. Die ACL für ein Element muss beim Indexieren enthalten sein, damit Google Cloud Search über die Informationen verfügt, die erforderlich sind, um die richtige Zugriffsebene für das Element bereitzustellen.
Das Content Connector SDK bietet zahlreiche ACL-Klassen und -Methoden, mit denen sich die ACLs der meisten Repositories modellieren lassen. Sie müssen die ACL für jedes Element in Ihrem Repository analysieren und eine entsprechende ACL für Google Cloud Search erstellen, wenn Sie ein Element indexieren. Wenn in der ACL Ihres Repositorys Konzepte wie die ACL-Vererbung verwendet werden, kann es schwierig sein, diese ACL zu modellieren. Weitere Informationen zu ACLs von Google Cloud Search
Hinweis:Die Cloud Search API unterstützt ACLs für einzelne Domains. Domainübergreifende ACLs werden nicht unterstützt. Verwenden Sie die Klasse Acl.Builder
, um den Zugriff auf jedes Element mithilfe einer ACL festzulegen. Mit dem folgenden Code-Snippet aus dem Beispiel für den vollständigen Durchlauf können alle Nutzer oder „Hauptkonten“ (getCustomerPrincipal()
) beim Durchführen einer Suche „Leser“ aller Elemente (.setReaders()
) sein.
Sie müssen die ACLs verstehen, um ACLs für das Repository richtig zu modellieren. Beispiel: Sie indexieren möglicherweise Dateien in einem Dateisystem, das ein Vererbungsmodell verwendet, bei dem untergeordnete Ordner Berechtigungen von übergeordneten Ordnern übernehmen. Für die Modellierung der ACL-Vererbung sind zusätzliche Informationen erforderlich. Weitere Informationen finden Sie unter ACLs in Google Cloud Search.
Metadaten für ein Element festlegen
Metadaten werden in einem Item
-Objekt gespeichert. Zum Erstellen eines Item
benötigen Sie mindestens die folgenden Angaben: die eindeutige String-ID, den Elementtyp, die ACL, die URL und die Elementversion.
Das folgende Code-Snippet zeigt, wie ein Item
mit der Helper-Klasse IndexingItemBuilder
erstellt wird.
Indexierbares Element erstellen
Nachdem Sie die Metadaten für das Element festgelegt haben, können Sie mit RepositoryDoc.Builder
das tatsächliche indexierbare Element erstellen.
Das folgende Beispiel zeigt, wie ein einzelnes indexierbares Element erstellt wird.
Ein RepositoryDoc
ist ein ApiOperation
-Typ, der die eigentliche IndexingService.indexItem()
-Anfrage ausführt.
Sie können auch die Methode setRequestMode()
der Klasse RepositoryDoc.Builder
verwenden, um die Indexierungsanfrage als ASYNCHRONOUS
oder SYNCHRONOUS
zu identifizieren:
ASYNCHRONOUS
- Der asynchrone Modus führt zu einer längeren Latenz zwischen Indexierung und Bereitstellung und eignet sich für ein hohes Durchsatzkontingent bei Indexierungsanfragen. Der asynchrone Modus wird für die anfängliche Indexierung (Backfill) des gesamten Repositorys empfohlen.
SYNCHRONOUS
- Im synchronen Modus ist die Latenz zwischen Indexierung und Bereitstellung geringer und er eignet sich für ein begrenztes Durchsatzkontingent. Der synchrone Modus wird für die Indexierung von Updates und Änderungen am Repository empfohlen. Wenn keine Angabe erfolgt, wird standardmäßig der Anfragemodus
SYNCHRONOUS
verwendet.
Untergeordnete IDs in die Cloud Search-Indexierungswarteschlange aufnehmen
Das folgende Code-Snippet zeigt, wie die untergeordneten IDs für das derzeit verarbeitete übergeordnete Element zur Verarbeitung in die Warteschlange aufgenommen werden. Diese IDs werden verarbeitet, nachdem das übergeordnete Element indexiert wurde.
Nächste Schritte
Als Nächstes könnten Sie Folgendes tun:
- Optional: Methode
close()
implementieren, um vor dem Herunterfahren alle Ressourcen freizugeben - Optional: Mit dem Identity Connector SDK einen Identitätsconnector erstellen
Mit der REST API Inhaltsconnectors erstellen
In den folgenden Abschnitten wird erläutert, wie Sie mithilfe der REST API einen Inhaltsconnector erstellen.
Durchlaufstrategie festlegen
Die Hauptfunktion eines Inhaltsconnectors besteht darin, ein Repository zu durchsuchen und die darin enthaltenen Daten zu indexieren. Sie müssen eine Durchlaufstrategie implementieren, die auf der Größe und dem Layout der Daten in Ihrem Repository basiert. Es gibt drei gängige Durchlaufstrategien:
- Durchlauf mit vollständiger Indexierung (Full Traversal)
Bei dieser Strategie wird das gesamte Repository gescannt und blind indexiert. Diese Strategie wird häufig verwendet, wenn Sie ein kleines Repository haben und es sich leisten kann, bei jeder Indexierung einen vollständigen Durchlauf durchzuführen.
Diese Durchlaufstrategie eignet sich für kleine Repositories mit hauptsächlich statischen, nicht hierarchischen Daten. Sie können diese Durchlaufstrategie auch verwenden, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird.
- Durchlauf mit Teilindexierung (List Traversal)
Bei einer List Traversal-Strategie wird das gesamte Repository einschließlich aller untergeordneten Knoten gescannt, um den Status der einzelnen Elemente zu bestimmen. Anschließend führt der Connector einen zweiten Durchlauf aus und indexiert nur Elemente, die neu sind oder seit der letzten Indexierung aktualisiert wurden. Diese Strategie wird häufig verwendet, um inkrementelle Aktualisierungen an einem vorhandenen Index vorzunehmen, anstatt bei jeder Aktualisierung des Index einen vollständigen Durchlauf durchzuführen.
Diese Durchlaufstrategie ist geeignet, wenn die Änderungserkennung schwierig ist oder vom Repository nicht unterstützt wird, Sie nicht hierarchische Daten haben und mit sehr großen Datasets arbeiten.
- Graph Traversal
Bei dieser Strategie wird der gesamte übergeordnete Knoten gescannt, um den Status der einzelnen Elemente zu ermitteln. Anschließend macht der Connector einen zweiten Durchlauf und indexiert nur Elemente im Stammknoten, die neu sind oder seit der letzten Indexierung aktualisiert wurden. Schließlich übergibt der Connector alle untergeordneten IDs und indexiert dann Elemente in den untergeordneten Knoten, die neu sind oder aktualisiert wurden. Der Connector durchläuft rekursiv alle untergeordneten Knoten, bis alle Elemente adressiert sind. Ein solcher Durchlauf wird normalerweise für hierarchische Repositories verwendet, bei denen das Auflisten aller IDs nicht praktikabel ist.
Diese Strategie eignet sich, wenn Sie hierarchische Daten haben, die gecrawlt werden müssen, z. B. Serienverzeichnisse oder Webseiten.
Durchlaufstrategie und Indexelemente implementieren
Jedes indexierbare Element für Cloud Search wird in der Cloud Search API als Element bezeichnet. Ein Element kann eine Datei, ein Ordner, eine Zeile in einer CSV-Datei oder ein Datenbankeintrag sein.
Sobald Ihr Schema registriert ist, können Sie den Index so befüllen:
Optional: Verwenden Sie
items.upload
, um Dateien mit mehr als 100 KiB für die Indexierung hochzuladen. Bei kleineren Dateien können Sie die Inhalte mititems.index
als inlineContent einbetten.Optional: Verwenden Sie
media.upload
, um Mediendateien für die Indexierung hochzuladen.Verwenden Sie
items.index
, um das Element zu indexieren. Wenn in Ihrem Schema beispielsweise die Objektdefinition aus dem Filmschema verwendet wird, würde eine Indexierungsanfrage für ein einzelnes Element so aussehen:{ "name": "datasource/<data_source_id>/items/titanic", "acl": { "readers": [ { "gsuitePrincipal": { "gsuiteDomain": true } } ] }, "metadata": { "title": "Titanic", "viewUrl": "http://www.imdb.com/title/tt2234155/?ref_=nv_sr_1", "objectType": "movie" }, "structuredData": { "object": { "properties": [ { "name": "movieTitle", "textValues": { "values": [ "Titanic" ] } }, { "name": "releaseDate", "dateValues": { "values": [ { "year": 1997, "month": 12, "day": 19 } ] } }, { "name": "actorName", "textValues": { "values": [ "Leonardo DiCaprio", "Kate Winslet", "Billy Zane" ] } }, { "name": "genre", "enumValues": { "values": [ "Drama", "Action" ] } }, { "name": "userRating", "integerValues": { "values": [ 8 ] } }, { "name": "mpaaRating", "textValues": { "values": [ "PG-13" ] } }, { "name": "duration", "textValues": { "values": [ "3 h 14 min" ] } } ] } }, "content": { "inlineContent": "A seventeen-year-old aristocrat falls in love with a kind but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.", "contentFormat": "TEXT" }, "version": "01", "itemType": "CONTENT_ITEM" }
Optional: Prüfen Sie mithilfe von items.get-Aufrufen, ob ein Element indexiert wurde.
Für einen „Full Traversal“ wird das gesamte Repository regelmäßig neu indexiert. Für einen List Traversal oder Graph Traversal müssen Sie Code für den Umgang mit Repository-Änderungen implementieren.
Repository-Änderungen verarbeiten
Sie können jedes Element regelmäßig aus einem Repository erfassen und indexieren, um eine vollständige Indexierung durchzuführen. Eine vollständige Indexierung kann zwar dafür sorgen, dass Ihr Index aktuell ist, aber bei größeren oder hierarchischen Repositories kostspielig sein.
Anstatt ein ganzes Repository regelmäßig mit Indexaufrufen zu indexieren, können Sie auch die Google Cloud-Indexierungswarteschlange verwenden, um Änderungen nachzuverfolgen und nur geänderte Elemente zu indexieren. Mit items.push-Anfragen können Sie der Warteschlange Elemente für spätere Abfragen und Updates hinzufügen. Weitere Informationen zur Google Cloud-Indexierungswarteschlange finden Sie unter Google Cloud-Indexierungswarteschlange.
Weitere Informationen zur Google Cloud Search API