JanusGraph in GKE mit Bigtable ausführen

Mithilfe von Grafikdatenbanken können Sie Ihre Datenentitäten und die Beziehungen zwischen ihnen modellieren und somit neue Erkenntnisse gewinnen. JanusGraph ist eine Grafikdatenbank, die das Arbeiten mit großen Datenmengen unterstützt. In dieser Anleitung erfahren Sie, wie Sie JanusGraph in Google Cloud mit Google Kubernetes Engine als Orchestrierungsplattform und Bigtable als Speicher-Backend ausführen. Diese Anleitung richtet sich an Systemarchitekten, Datenbankadministratoren und DevOps-Experten, die die JanusGraph-Grafikdatenbank in Google Cloud mit einer verwalteten Datenbank als Speicher-Backend ausführen möchten. Es wird davon ausgegangen, dass Sie mit Google Kubernetes Engine (GKE), Kubernetes-Pods, Helm-Diagrammen, Bigtable und Elasticsearch vertraut sind. Kenntnisse des Graph Computing Frameworks Apache TinkerPop und der Maschine und Sprache Gremlin zum Durchsuchen von Grafiken sind nicht erforderlich. Diese Kenntnisse sind aber notwendig, um JanusGraph über die Beispiele in diesem Tutorial hinaus zu benutzen.

Übersicht

In der Grafikterminologie werden Entitäten als Knoten oder Eckpunkte und Beziehungen als Kanten bezeichnet. In JanusGraph können sowohl Eckpunkte als auch Kanten zusätzliche zugehörige Daten haben, die über Attribute verfügbar gemacht werden.

Beispiel für eine Attributgrafik.

Die obige Abbildung ist ein Beispiel für eine Attributgrafik.

Mit Grafikdatenbanken können Sie eine Vielzahl von Domains und Aktivitäten modellieren:

  • Soziale Netzwerke
  • Finanztransaktionen (für Betrugsanalysen)
  • Physische oder virtuelle Systemnetzwerke

Für neue Grafikdatenbanken erstellen Sie manchmal Millionen oder sogar Milliarden von Eckpunkten und Kanten. Wenn Sie JanusGraph mit Bigtable als zugrundeliegende Speicherebene verwenden, können Sie sowohl schnelle Abfragen (sogenanntes Durchsuchen von Grafiken) durchführen als auch Ihre Speicherebene unabhängig von der Größe und dem Durchsatz skalieren, die Sie benötigen. JanusGraph verwendet auch ein modulares Indexierungs-Backend, um eine Volltextindexierung für Eckpunkt- und Kantenattribute bereitzustellen. In dieser Anleitung stellen Sie eine skalierbare JanusGraph-Infrastruktur in GKE bereit. Sie verwenden Elasticsearch als Indexierungs-Backend, das in Pods in einem StatefulSet ausgeführt wird, und Bigtable als Speicher-Backend. Wenn Sie fertig sind, können Sie die Beziehungen in Ihren Grafikdaten durchsuchen. Das folgende Diagramm zeigt, wie diese Elemente zusammenpassen.

JanusGraph-Deployment mit Bigtable in GKE.

Das Diagramm zeigt die JanusGraph-Bereitstellung in GKE mit Elasticsearch und Bigtable.

JanusGraph-Daten in Bigtable

Grafikdaten werden von JanusGraph als Adjazenzliste gespeichert. Jede Zeile stellt einen Eckpunkt, alle angrenzenden Eckpunkte (Kanten) und Attributmetadaten zu den Eckpunkten und Kanten dar. Der Zeilenschlüssel ist die eindeutige Kennung für den Eckpunkt. Jede Beziehung zwischen dem Eckpunkte und einem anderen Eckpunkt und allen Attributen, die die Beziehung weiter definieren, wird als Kanten- oder Kantenattributspalte gespeichert. Sowohl der Spaltenqualifizierer als auch der Spaltenwert speichern Daten, die die Kante definieren, gemäß den Best Practices für Bigtable. Jedes Eckpunktattribut wird als separate Spalte gespeichert, wobei wiederum sowohl der Spaltenqualifizierer als auch der Spaltenwert verwendet werden, um das Attribut zu definieren.

Das folgende Diagramm zeigt diese Speicherstruktur.

Adjazenz-Listenspeicherstruktur von JanusGraph

Das Diagramm zeigt die logische Speicherstruktur für ein kleines Grafikfragment mit logischen Details für zwei Eckpunktzeilen. Im Diagramm stellen die beiden Beispielzeilen zwei Eckpunkte dar. Der erste Eckpunkt ist mit einem einzelnen Eckpunktattribut gekennzeichnet und bezieht sich auf zwei andere Eckpunkte durch zwei separate Kanten. Der zweite Eckpunkt enthält Spalten mit zwei Attributen und einer Kante.

Die folgende Abbildung des logischen Eckpunkt-Kanten-Datenmodells enthält einige Details zu den Spaltenqualifizierern und Werten einer Kanten- oder Kantenattributspalte.

Spalte "Kante- und Kantenattribut von JanusGraph"

Für jeden angrenzenden Eckpunkt speichert eine Spalte die Metadaten zu dieser Kante. Der Spaltenqualifizierer enthält Metadaten zur Kantenbeziehung und zur Kantenrichtung sowie einen Zeiger auf den angrenzenden Eckpunkt. Der Spaltenwert enthält das Kantenlabel und zusätzliche Kantenattribute. Da Durchläufe in beide Richtungen verfolgt werden können, werden die Kanten zweimal gespeichert, einmal für jedes Ende der Kantenbeziehung. Bidirektionaler Kantenspeicher erhöht die Durchlaufleistung erheblich, hat jedoch aufgrund der Redundanz zusätzlichen Speicherplatzes und nicht atomarer Kantenmutationen einige Nachteile.

Im folgenden Diagramm ist das logische Datenmodell einer Spalte mit einem Eckpunktattribut dargestellt.

JanusGraph-Spaltenwerte für eine Attributspalte.

Die vorherige Abbildung enthält Details zu den Spaltenqualifizierern und Werten für eine Kantenspalte.

Jedes Eckpunktattribut wird als separate Spalte gespeichert. Der Spaltenqualifizierer ist eine eindeutige Kennung für den Attributschlüssel. Der Spaltenwert enthält sowohl eine Kennzeichnung für das Attribut als auch den Wert des Attributs.

JanusGraph beruht auf der lexikografischen Reihenfolge von Zeilen und Spaltenqualifizierern von Bigtable, um die Abfrageleistung zu verbessern.

Ziele

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Bigtable, Compute Engine, and GKE APIs.

    Enable the APIs

    5.

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the Bigtable, Compute Engine, and GKE APIs.

    Enable the APIs

    8.

Umgebung vorbereiten

In dieser Anleitung verwenden Sie Cloud Shell zum Eingeben von Befehlen. Mit Cloud Shell erhalten Sie Zugriff auf die Befehlszeile der Google Cloud Console. Außerdem enthält Cloud Shell die Google Cloud CLI und weitere Tools, die Sie für die Entwicklung in Google Cloud benötigen. Cloud Shell wird am unteren Rand der Google Cloud Console als Fenster angezeigt. Die Initialisierung kann einige Minuten dauern, aber das Fenster ist sofort sichtbar.

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. Legen Sie in Cloud Shell die Umgebungsvariablen für die Compute Engine-Zone fest, in der Sie den Bigtable-Cluster und den GKE-Cluster erstellen, sowie den Namen, den Knotentyp und die Version für den GKE-Cluster:

    export PROJECT_ID=PROJECT_ID
export GCP_ZONE=REGION
export GKE_CLUSTER_NAME=GKE_CLUSTER_NAME
export GKE_NODE_TYPE=n1-standard-4
export GKE_VERSION=1.20

    Ersetzen Sie Folgendes:

    • PROJECT_ID durch Ihre Projekt-ID.
    • REGION durch die Zone, in der der Bigtable-Cluster und der GKE-Cluster erstellt werden.
    • GKE_CLUSTER_NAME ist der Name des GKE-Clusters.

    Der Befehl sollte in etwa wie das folgende Beispiel aussehen:

    export PROJECT_ID=bt-janusgraph-project-id
export GCP_ZONE=us-central1-f
export GKE_CLUSTER_NAME=janusgraph-gke
export GKE_NODE_TYPE=n1-standard-4
export GKE_VERSION=1.20

  3. Erstellen Sie einen GKE-Cluster, in dem JanusGraph bereitgestellt wird:

    gcloud container clusters create ${GKE_CLUSTER_NAME} \
    --zone=${GCP_ZONE} \
    --cluster-version=${GKE_VERSION} \
    --machine-type ${GKE_NODE_TYPE} \
    --scopes "https://www.googleapis.com/auth/cloud-platform"

Bigtable-Instanz erstellen

In dieser Anleitung wird Bigtable als JanusGraph-Speicher-Backend verwendet, das schnell skaliert werden kann, um Ihre Anforderungen zu erfüllen. In dieser Anleitung wird ein Cluster mit nur einem Knoten verwendet. Dies reicht für die Anleitung aus und ist außerdem kostengünstig. Sie können Ihre Projekte in einem kleineren Cluster starten und zu einem größeren Cluster übergehen, wenn Sie so weit sind, mit Produktionsdaten arbeiten zu können. In der Bigtable-Dokumentation finden Sie ausführliche Erläuterungen zu Leistung und Skalierung, die Ihnen helfen, die richtige Clustergröße für Ihre Arbeit zu ermitteln.

  1. Legen Sie in Cloud Shell die Umgebungsvariable für die Bigtable-Instanz-ID fest:

    export BIGTABLE_INSTANCE_ID=BIGTABLE_INSTANCE_ID

    Ersetzen Sie BIGTABLE_INSTANCE_ID durch die ID für Ihre Bigtable-Instanz.

  2. Erstellen Sie die Bigtable-Instanz:

    gcloud bigtable instances create ${BIGTABLE_INSTANCE_ID} \
    --cluster-config=id=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE},zone=${GCP_ZONE},nodes=1 \
    --display-name=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE}

Helm installieren und konfigurieren

Mit Helm stellen Sie Anwendungen in Ihrem Kubernetes-Cluster bereit. In dieser Anleitung verwenden Sie Helm, um die JanusGraph- und Elasticsearch-Dienste auf Ihrem GKE-Cluster bereitzustellen.

  1. Installieren Sie Helm in Cloud Shell:

    curl -fsSL -o get_helm.sh \
    https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod 700 get_helm.sh
DESIRED_VERSION=v3.5.0 ./get_helm.sh

  2. Fügen Sie das Diagramm-Repository elastic hinzu, damit die Elasticsearch-Diagrammabhängigkeit während der Bereitstellung des JanusGraph-Diagramms gefunden wird:

    helm repo add elastic https://helm.elastic.co

    Dieses Diagramm-Repository wird von Elastic gehostet, den Erstellern von Elasticsearch.

JanusGraph und Elasticsearch mithilfe von Helm installieren

In diesem Abschnitt stellen Sie mithilfe eines Helm-Diagramms in Ihrem Kubernetes-Cluster JanusGraph und Elasticsearch bereit.

Das Helm-Diagramm wird von GitHub abgerufen. Die im Helm-Diagramm-Repository enthaltene Bereitstellung stellt eine Reihe von drei JanusGraph-Pods hinter einem Dienst bereit, der einen internen Application Load Balancer startet. Wenn die Pods ausgeführt werden, senden Start- und Aktivitätsprüfungen HTTP-Anfragen, um Systemdiagnosen auf dem JanusGraph-Server auf jedem Pod durchzuführen. Darüber hinaus enthält das Diagramm ein von Elastic bereitgestelltes Abhängigkeitsdiagramm, das drei Elasticsearch-Pods in einem StatefulSet bereitstellt.

  1. Legen Sie in Cloud Shell Umgebungsvariablen für Helm- und JanusGraph-Namen fest:

    export HELM_REPO=bigtable-janusgraph-helm
export JANUSGRAPH_VERSION=0.5.3
export HELM_CHART_RELEASE_VERSION=1
export HELM_CHART_RELEASE_TAG=${JANUSGRAPH_VERSION}-${HELM_CHART_RELEASE_VERSION}
export HELM_CHART_RELEASE_TAG_HASH=f8b271a4854d4a553dd5e9ba014d077fb098d9ab
export HELM_CHART_NAME=janusgraph-bigtable

  2. Rufen Sie das Helm-Diagramm aus GitHub ab:

    git clone https://github.com/GoogleCloudPlatform/${HELM_REPO} \
   --branch ${HELM_CHART_RELEASE_TAG}

  3. Wechseln Sie zum Helm-Diagrammverzeichnis:

    cd ${HELM_REPO}

  4. Überprüfen Sie aus Sicherheitsgründen, ob Sie den Commit-Hash verwenden:

    HEAD_COMMIT_HASH=$(git rev-parse --verify HEAD)
if [ _${HEAD_COMMIT_HASH} == _${HELM_CHART_RELEASE_TAG_HASH} ]
then
    echo "Commit hash verified"
fi

    Wenn die Ausgabe nicht so aussieht, fahren Sie nicht fort, da die Integrität des geklonten Tags nicht überprüft wurde.

    Commit hash verified

  5. Aktualisieren Sie die Diagrammabhängigkeiten:

    helm dep update

  6. Wechseln Sie zum übergeordneten Verzeichnis:

    cd ..

  7. Legen Sie Umgebungsvariablen für die Namen von Helm- und JanusGraph-Entitäten fest:

    export HELM_RELEASE_NAME=janusgraph-bigtable-elastic
export ELASTICSEARCH_CLUSTER_NAME=${HELM_RELEASE_NAME}-elasticsearch
export BIGTABLE_JANUSGRAPH_TABLE=janusgraph-table

  8. Erstellen Sie eine Datei namens values.yaml, die die Konfigurationsattribute für die Bereitstellung des JanusGraph-Diagramms in Helm enthält:

    cat > values.yaml << EOF

image:
  repository: docker.io/janusgraph/janusgraph
  tag: 0.5.3
  pullPolicy: IfNotPresent

replicaCount: 3

service:
  type: LoadBalancer
  port: 8182
  serviceAnnotations:
    networking.gke.io/load-balancer-type: "Internal"

elasticsearch:
  deploy: true
  clusterName: ${ELASTICSEARCH_CLUSTER_NAME}

properties:
  storage.backend: hbase
  storage.directory: null
  storage.hbase.ext.google.bigtable.instance.id: ${BIGTABLE_INSTANCE_ID}
  storage.hbase.ext.google.bigtable.project.id: ${PROJECT_ID}
  storage.hbase.ext.hbase.client.connection.impl: com.google.cloud.bigtable.hbase2_x.BigtableConnection
  storage.hbase.short-cf-names: true
  storage.hbase.table: ${BIGTABLE_JANUSGRAPH_TABLE}
  index.search.backend: elasticsearch
  index.search.hostname: ${ELASTICSEARCH_CLUSTER_NAME}-master
  index.search.directory: null
  index.search.elasticsearch.health-request-timeout: 90s
  cache.db-cache: true
  cache.db-cache-clean-wait: 20
  cache.db-cache-time: 180000
  cache.db-cache-size: 0.5
  cluster.max-partitions: 1024
  graph.replace-instance-if-exists: true

persistence:
  enabled: false

debugLevel: INFO
EOF

  9. Stellen Sie das JanusGraph-Helm-Diagramm mithilfe der von Ihnen erstellten values.yaml-Datei bereit:

    helm upgrade --install \
             --wait \
              --timeout 600s \
              ${HELM_RELEASE_NAME} \
              ./${HELM_REPO} \
              -f values.yaml

    Der Installationsvorgang wartet, bis alle Ressourcen bereit sind, bevor er abgeschlossen wird. Dieser Vorgang kann einige Minuten dauern.

JanusGraph-Bereitstellung prüfen

Wenn der Helm-Installationsprozess abgeschlossen ist, wird der Abschnitt NOTES angezeigt, in dem die ersten Schritte beschrieben werden. Sie können den Schritten folgen, die im Abschnitt NOTES beschrieben sind, um zu überprüfen, ob Ihre JanusGraph-Umgebung funktioniert.

  1. Prüfen Sie in Cloud Shell, ob die in GKE bereitgestellten Helm-Diagrammkomponenten ausgeführt werden:

    1. Prüfen Sie die JanusGraph-Bereitstellung:

      kubectl get deployments

      Wenn die Bereitstellung erfolgreich ist, sieht die Ausgabe so aus:

      NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
janusgraph-bigtable-elastic   3/3     3            3           3m28s

    2. Prüfen Sie das Elasticsearch-StatefulSet:

      kubectl get statefulsets

      Wenn alles funktioniert, sieht die Ausgabe so aus:

      NAME                                               READY   AGE
janusgraph-bigtable-elastic-elasticsearch-master   3/3     4m13s

  2. Legen Sie eine Umgebungsvariable auf den Namen eines Kubernetes-Pods fest, der den JanusGraph Gremlin-Server ausführt. Das Label app für den Pod, auf dem der Gremlin-Server läuft, wird von dem Helm-Diagrammnamen abgeleitet, der in der Datei Chart.yaml definiert ist.

    export APP_LABEL_FROM_CHART_NAME=${HELM_CHART_NAME}
export POD_NAME=$(kubectl get pods \
                     --namespace default \
                     -l "app=${APP_LABEL_FROM_CHART_NAME}, \
                         release=${HELM_RELEASE_NAME}" \
                     -o jsonpath="{.items[0].metadata.name}")

  3. Stellen Sie eine Verbindung zum Pod her und führen Sie die Gremlin-Konsole, eine REPL-Shell (Read-Eval-Print-Loop) aus. Der Name des Containers wird auch vom Namen des Helm-Diagramms in Chart.yaml abgeleitet.

    export GREMLIN_CONTAINER=${HELM_CHART_NAME}
kubectl exec \
        -c ${GREMLIN_CONTAINER} \
        -it $POD_NAME \
        -- /opt/janusgraph/bin/gremlin.sh

  4. Stellen Sie über die Gremlin-Konsole eine Verbindung zum Apache TinkerPop-Server her:

    1. Starten Sie die Sitzung:

      :remote connect tinkerpop.server conf/remote.yaml session

      Die Ausgabe sieht dann ungefähr so aus:

      ==>Configured localhost/127.0.0.1:8182-[b08972f2-a2aa-4312-8018-bcd11bc9812c]

    2. Stellen Sie eine Verbindung zum Server her:

      :remote console

      Die Ausgabe sieht dann ungefähr so aus:

      ==>All scripts will now be sent to Gremlin Server - [localhost/127.0.0.1:8182]-[b08972f2-a2aa-4312-8018-bcd11bc9812c] - type ':remote console' to return to local mode>

  5. Prüfen Sie in der Gremlin-Konsole, ob der Gremlin-Server korrekt ausgeführt wird. Prüfen Sie dazu die Variable graph, die die Grafikinstanz darstellt:

    graph

    Die Ausgabe gibt an, dass der JanusGraph-Server mit einer HBase-kompatiblen Datenbank ausgeführt wird, in diesem Fall Bigtable als Speicher-Backend.

    ==>standardjanusgraph[hbase:[127.0.0.1]]

  6. In Gremlin zwei Eckpunkte erstellen

    v1 = graph.addVertex(label, 'hello')
v2 = graph.addVertex(label, 'world')

    Wenn die Konsolenausgabe in etwa so aussieht, gibt dies an, dass die beiden Eckpunkte hinzugefügt wurden:

    ==>v[4344]
==>v[4152]

  7. Erstellen Sie eine Kante, die die beiden Eckpunkte verbindet:

    v1.addEdge('followedBy', v2)

    Wenn die Konsolenausgabe in etwa so aussieht, gibt dies an, dass die Kante zwischen den beiden Eckpunkten hinzugefügt wurde:

    ==>e[17j-3co-4fmd-oe054][4344-followedBy->4152]

  8. Führen Sie ein Commit der Transaktion durch:

    graph.tx().commit()

    Wenn die Konsolenausgabe null lautet, bedeutet dies, dass Vorgänge mit Commit ausgeführt wurden:

    ==>null

    Das folgende Diagramm zeigt das Diagramm, das von den Befehlen erstellt wird.

    JanusGraph-Beispieleckpunkte und -kante.

    Der Eckpunkt mit dem Label hello ist durch eine gerichtete Kante mit dem Label followedBy mit dem Eckpunkt mit dem Label world verbunden.

  9. Stellen Sie eine Gremlin-Abfrage, um herauszufinden, was das Label für den Eckpunkt ist, der einer Kante mit dem Label followedBy vom Eckpunkt mit dem Label hello folgt:

    g.V().has(label, 'hello').out('followedBy').label()

    Die Abfragesyntax wird im nächsten Abschnitt erläutert. Für den Moment ist nur wichtig zu wissen, dass Ihnen das Wort world als Ausgabe der Abfrage angezeigt wird:

    ==>world

Beispiel-Dataset laden und abfragen

Nachdem Sie JanusGraph bereitgestellt haben und über Gremlin eine Verbindung zu dieser Grafikdatenbank herstellen können, können Sie jetzt mit dem Laden und Abfragen Ihrer eigenen Daten beginnen. Um zu sehen, wie dieser Prozess aussieht, laden Sie den Beispiel-Datensatz, der im Lieferumfang von JanusGraph enthalten ist – die Grafik der Götter, die die mythologischen Gottheiten des römischen Pantheons und ihre Standorteigenschaften darstellt.

  1. Laden Sie in Gremlin die zuvor erstellte Grafik:

    GraphOfTheGodsFactory.load(graph)

    Die Ausgabe sieht so aus:

    ==>null

  2. Senden Sie eine Abfrage zum Durchsuchen der Grafik, die nach allen Brüder von Jupiter sucht:

    g.V().has('name', 'jupiter').out('brother').values('name')

    In der folgenden Tabelle werden die Schritte erläutert, die die Abfrage durchläuft.

    Durchlaufschritt Erklärung
    g.V() Es wird mit der Erfassung von Eckpunkten begonnen.
    has('name', 'jupiter') Darin wird nach einem Eckpunkt gesucht, dessen Attribut name den Wert jupiter hat.
    out('brother') Davon ausgehend wird allen Kanten gefolgt, die mit dem Label brother versehen sind.
    values('name') Für die Eckpunkte, zu denen diese Kanten führen, wird jeweils das Attribut name abgerufen.
    Die Ausgabe sieht so aus:

    ==>neptune
==>pluto

    Wenn Sie sich mit den Durchlaufabfragen, die für das Dataset "Graph of the Gods" möglich sind, näher befassen möchten, können Sie weitere Beispielabfragen aus der JanusGraph-Dokumentation nutzen.

Prüfen, ob Daten in Bigtable gespeichert sind

Nachdem Sie nun einige Beispieldaten in Ihrem JanusGraph-Cluster erstellt haben, können Sie prüfen, ob Bigtable als Speicher-Backend verwendet wurde.

  1. Schließen Sie die Gremlin-Konsole:

    :q

  2. Prüfen Sie in Cloud Shell, ob die Daten in der Tabelle janusgraph in Bigtable persistent sind:

    cbt -project=${PROJECT_ID} \
    -instance=${BIGTABLE_INSTANCE_ID} \
     count ${BIGTABLE_JANUSGRAPH_TABLE}

    Die entsprechende Ausgabe sieht etwa so aus:

    2021/03/02 02:32:19 -creds flag unset, will use gcloud credential
101

    Der Wert 101 in der Ausgabe steht für die Anzahl der Zeilen in der Tabelle janusgraph table und kann bei Ihnen anders lauten.

Erstellung des Suchindex in Elasticsearch prüfen

  1. Legen Sie in Cloud Shell Variablen für den Index und den Namen des Elasticsearch-Pods fest:

    export ELASTICSEARCH_POD_ORDINAL=0
export ELASTICSEARCH_POD_NAME_ROOT=${ELASTICSEARCH_CLUSTER_NAME}-master
export ELASTICSEARCH_POD=${ELASTICSEARCH_POD_NAME_ROOT}-0

    Die Namen der Elasticsearch-Pods werden durch die Elasticsearch-Helm-Abhängigkeiten definiert. Die Pod-Namen bestehen aus dem Clusternamen, der in der von Ihnen erstellten Datei values.yaml angegeben ist, dem Wort master und einer nullindexierten Ordnungszahl, die alle durch Bindestriche getrennt sind. Für diesen Schritt wählen Sie den ersten Pod aus, dargestellt als null (0).

  2. Verwenden Sie die Elasticsearch Aliases REST API, um die Indexe zu prüfen:

    kubectl exec \
        -c elasticsearch \
        -it ${ELASTICSEARCH_POD} \
        --  \
        curl -XGET "127.0.0.1:9200/_aliases?pretty=true";

    Die Ausgabe zeigt zwei Indexe, janusgraph_vertices und janusgraph_edges, die von JanusGraph erstellt wurden, um effiziente Suchvorgänge mit Eckpunkt- und Kantenattributen zu ermöglichen:

    {
  "janusgraph_vertices" : {
    "aliases" : {
      "janusgraph" : { }
    }
  },
  "janusgraph_edges" : {
    "aliases" : {
      "janusgraph" : { }
    }
  }
}

  3. Fragen Sie die Werte aus einem der Indexe mit der Elasticsearch Search REST API ab:

    kubectl exec \
       -c elasticsearch \
       -it ${ELASTICSEARCH_POD} \
       --  \
       curl -XGET "127.0.0.1:9200/janusgraph_edges/_search?pretty=true&q=*";

    Die Suchergebnisse zeigen, dass in den von JanusGraph erstellten Indexen Einträge vorhanden sind. Die angezeigte Ausgabe ähnelt den folgenden abgeschnittenen Ergebnissen, die zeigen, dass der Index janusgraph_edges Einträge enthält.

    {
 "took" : 94,
 "timed_out" : false,
 "_shards" : {
   "total" : 1,
   "successful" : 1,
   "skipped" : 0,
   "failed" : 0
 },
 "hits" : {
   "total" : {
     "value" : 6,
     "relation" : "eq"
   },
   "max_score" : 1.0,
   "hits" : [
     {
       "_index" : "janusgraph_edges",
       "_type" : "_doc",
       "_id" : "6bvp-5ovc-b2t-2yko",
       "_score" : 1.0,
       "_source" : {
         "reason" : "loves waves"
       }
     },
     {
…

Projekt löschen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Nächste Schritte