Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Neptune-Nachschlage-Cache kann Leseabfragen beschleunigen

Amazon Neptune implementiert einen Lookup-Cache, der die NVMe Based der R5d Instance verwendet, SSD um die Leseleistung für Abfragen mit häufigen, sich wiederholenden Abfragen von Eigenschaftswerten oder Literalen zu verbessern. RDF Der Lookup-Cache speichert diese Werte vorübergehend in dem NVMe SSD Volume, sodass schnell auf sie zugegriffen werden kann.

Dieses Feature ist ab Amazon Neptune Engine-Version 1.0.4.2.R1 (01.06.2021) verfügbar.

Leseabfragen, die die Eigenschaften einer großen Anzahl von Scheitelpunkten und Kanten oder vieler RDF Tripel zurückgeben, können eine hohe Latenz haben, wenn die Eigenschaftswerte oder Literale aus Cluster-Speichervolumes und nicht aus dem Arbeitsspeicher abgerufen werden müssen. Beispiele hierfür sind über eine lange Zeit ausgeführte Leseabfragen, die eine große Zahl von vollständigen Namen aus einem Identitätsdiagramm oder von IP-Adressen aus einem Diagramm zur Betrugserkennung zurückgeben. Wenn die Anzahl der von Ihrer Abfrage zurückgegebenen Eigenschaftswerte oder RDF Literale zunimmt, nimmt der verfügbare Speicher ab, und Ihre Abfrageausführung kann sich erheblich verschlechtern.

Anwendungsfälle für den Neptune-Nachschlage-Cache

Der Lookup-Cache hilft nur, wenn Ihre Leseabfragen die Eigenschaften einer sehr großen Anzahl von Scheitelpunkten und Kanten oder von Tripelzahlen zurückgeben. RDF

Um die Abfrageleistung zu optimieren, verwendet Amazon Neptune den Instance-Typ R5d, um einen großen Cache für solche Eigenschaftswerte oder Literale zu erstellen. Der Abruf aus dem Cache ist erfolgt sehr viel schneller als der Abruf aus Cluster-Speichervolumes.

Als Faustregel gilt, dass sich ein Nachschlage-Cache nur dann lohnt, wenn alle drei der folgenden Bedingungen erfüllt werden:

Wenn Sie Gremlin verwenden, können Sie die Materialisierungskosten einer Abfrage mit Gremlin profile API bewerten. Unter „Indexoperationen“ wird die Anzahl der Begriffe angezeigt, die während der Ausführung materialisiert wurden:

Index Operations
Query execution:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 5273
Serialization:
    # of statement index ops: 200
    # of unique statement index ops: 140
    Duplication ratio: 1.43
    # of terms materialized: 32693

Die Anzahl der materialisierten nichtnumerischen Begriffe ist direkt proportional zur Anzahl der Begriffssuchen, die Neptune ausführen muss.

Verwenden des Nachschlage-Caches

Der Nachschlage-Cache ist nur für den Instance-Typ R5d verfügbar, für den er standardmäßig automatisch aktiviert ist. R5dNeptune-Instances haben dieselben Spezifikationen wie R5 Instances und zusätzlich bis zu 1,8 TB lokalen SpeicherNVMe. SSD Nachschlage-Caches sind Instance-spezifisch. Workloads, die von ihnen profitieren, können speziell an R5d-Instances in einem Neptune-Cluster geleitet werden, während andere Workloads an R5 oder andere Instance-Typen geleitet werden können.

Um den Nachschlage-Cache auf einer Neptune-Instance zu verwenden, aktualisieren Sie diese Instance einfach auf den Instance-Typ R5d. Wenn Sie dies tun, setzt Neptune den neptune_lookup_cache DB-Cluster-Parameter automatisch auf 1 (aktiviert) und erstellt den Lookup-Cache für diese bestimmte Instance. Sie können dann den verwenden Instance-StatusAPI, um zu bestätigen, dass der Cache aktiviert wurde.

Ähnlich können Sie eine Instance von einem R5d-Instance-Typ auf einen entsprechenden R5-Instance-Typ herunterskalieren. um den Nachschlage-Cache für diese Instance zu deaktivieren.

Wenn eine R5d-Instance gestartet wird, ist der Nachschlage-Cache aktiviert und im Kaltstartmodus. Das bedeutet, dass er leer ist. Neptune sucht bei der Verarbeitung von Abfragen zunächst im Lookup-Cache nach Eigenschaftswerten oder RDF Literalen und fügt sie hinzu, falls sie noch nicht vorhanden sind. Dies führt zu einer allmählichen „Aufwärmung“ des Cache.

Wenn Sie die Leseabfragen, die Eigenschaftswert- oder RDF -literal-Suchanfragen erfordern, an eine R5d-Leserinstanz weiterleiten, verschlechtert sich die Leseleistung geringfügig, während sich der Cache aufwärmt. Wenn der Cache aufgewärmt ist, verbessert sich die Leseleistung jedoch erheblich und die E/A-Kosten können sinken, da Nachschlagevorgänge für den Cache und nicht für den Clusterspeicher erfolgen. Die Speicherauslastung verbessert sich ebenfalls.

Wenn es sich bei Ihrer Schreib-Instance um eine R5d-Instance handelt, wird ihr Nachschlage-Cache bei jeder Schreiboperation automatisch aufgewärmt. Dieser Ansatz erhöht zwar geringfügig die Latenz für Schreibabfragen, wärmt den Nachschlage-Cache jedoch effizienter auf. Wenn Sie dann die Leseabfragen, die Eigenschaftswert- oder RDF -literal-Suchen erfordern, an die Writer-Instanz weiterleiten, wird die Leseleistung sofort verbessert, da die Werte dort bereits zwischengespeichert wurden.

Wenn Sie den Bulk-Loader auf einer R5d-Schreib-Instance ausführen, stellen Sie möglicherweise fest, dass die Leistung aufgrund des Caches leicht beeinträchtigt ist.

Da der Nachschlage-Cache für jeden Knoten spezifisch ist, wird der Cache bei Ersetzung des Hosts zum Kaltstart zurückgesetzt.

Sie können den Lookup-Cache für alle Instances in Ihrem DB-Cluster vorübergehend deaktivieren, indem Sie den neptune_lookup_cache DB-Cluster-Parameter auf (deaktiviert) setzen. 0 Im Allgemeinen ist es jedoch sinnvoller, den Cache auf bestimmten Instances zu deaktivieren, indem Sie diese von R5d auf R5 Instance-Typen herunterskalieren.