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.

Dimensionierung Ihres DAX Clusters

Die Gesamtkapazität und Verfügbarkeit eines DAX Clusters hängt vom Knotentyp und der Anzahl der Knoten ab. Mehr Knoten im Cluster erhöhen die Lesekapazität, nicht jedoch die Schreibkapazität. Größere Knotentypen (bis zu r5.8xlarge) können mehr Schreibvorgänge verarbeiten, aber zu wenige Knoten können die Verfügbarkeit beeinträchtigen, wenn ein Knoten ausfällt. Weitere Informationen zur Dimensionierung Ihres DAX Clusters finden Sie unter. DAX-Clustergrößenleitfaden

In den folgenden Abschnitten werden die verschiedenen Aspekte der Dimensionierung erörtert, die Sie berücksichtigen sollten, um ein ausgewogenes Verhältnis zwischen Knotentyp und Knotenanzahl herzustellen und so einen skalierbaren und kostengünstigen Cluster zu erstellen.

Verfügbarkeit planen

Bei der Dimensionierung eines DAX Clusters sollten Sie sich zunächst auf dessen angestrebte Verfügbarkeit konzentrieren. Die Verfügbarkeit eines geclusterten DienstesDAX, z. B., ist eine Dimension der Gesamtzahl der Knoten im Cluster. Da ein Cluster mit einem Knoten keine Fehlertoleranz hat, entspricht seine Verfügbarkeit der eines Knotens. In einem Cluster mit 10 Knoten hat der Verlust eines einzelnen Knotens nur minimale Auswirkungen auf die Gesamtkapazität des Clusters. Dieser Verlust hat keine direkten Auswirkungen auf die Verfügbarkeit, da die verbleibenden Knoten weiterhin Leseanforderungen erfüllen können. Nominiert DAX schnell einen neuen Primärknoten, um Schreibvorgänge wieder aufzunehmen.

DAXist VPC basiert. Es verwendet eine Subnetzgruppe, um zu bestimmen, in welchen Availability Zones Knoten ausgeführt werden können und welche IP-Adressen aus den Subnetzen verwendet werden sollen. Für Produktionsworkloads empfehlen wir dringend, mindestens drei Knoten in verschiedenen DAX Availability Zones zu verwenden. Dadurch wird sichergestellt, dass dem Cluster mehr als ein Knoten zur Bearbeitung von Anfragen zur Verfügung steht, auch wenn ein einzelner Knoten oder eine Availability Zone ausfällt. Ein Cluster kann bis zu 11 Knoten haben, wobei einer ein primärer Knoten und 10 Read Replicas sind.

Planung des Schreibdurchsatzes

Alle DAX Cluster haben einen primären Knoten für Write-Through-Anfragen. Die Größe des Knotentyps für den Cluster bestimmt dessen Schreibkapazität. Durch das Hinzufügen zusätzlicher Read Replicas wird die Schreibkapazität des Clusters nicht erhöht. Daher sollten Sie die Schreibkapazität bei der Clustererstellung berücksichtigen, da Sie den Knotentyp später nicht ändern können.

Wenn Ihre Anwendung zur Aktualisierung des Elementcaches Schreibvorgänge durchführen DAX muss, sollten Sie eine verstärkte Nutzung von Clusterressourcen in Betracht ziehen, um das Schreiben zu erleichtern. Schreibvorgänge gegen DAX verbrauchen etwa 25-mal mehr Ressourcen als Lesevorgänge im Cache. Dies erfordert möglicherweise einen größeren Knotentyp als für Nur-Lese-Cluster.

Weitere Hinweise zur Bestimmung, ob Write-Through oder Write-Around für Ihre Anwendung am besten geeignet ist, finden Sie unter. Strategien für Schreibvorgänge

Planung des Lesedurchsatzes

Die Lesekapazität eines DAX Clusters hängt von der Cache-Trefferquote Ihres Workloads ab. Da Daten aus DynamoDB DAX gelesen werden, wenn ein Cache-Fehler auftritt, verbraucht es ungefähr zehnmal mehr Clusterressourcen als ein Cache-Treffer. Um die Anzahl der Cache-Treffer zu erhöhen, erhöhen Sie die TTLCache-Einstellung, um den Zeitraum zu definieren, für den ein Element im Cache gespeichert wird. Eine höhere TTL Dauer erhöht jedoch die Wahrscheinlichkeit, dass ältere Elementversionen gelesen werden, sofern keine Updates durchgeschrieben werdenDAX.

Um sicherzustellen, dass der Cluster über ausreichende Lesekapazität verfügt, skalieren Sie den Cluster horizontal, wie unter beschriebenHorizontales Skalieren eines Clusters. Durch das Hinzufügen weiterer Knoten werden Read Replicas zum Ressourcenpool hinzugefügt, während durch das Entfernen von Knoten die Lesekapazität reduziert wird. Wenn Sie die Anzahl der Knoten und deren Größe für einen Cluster auswählen, sollten Sie sowohl die minimale als auch die maximale benötigte Lesekapazität berücksichtigen. Wenn Sie einen Cluster mit kleineren Knotentypen nicht horizontal skalieren können, um Ihre Leseanforderungen zu erfüllen, verwenden Sie einen größeren Knotentyp.

Größe des Planungsdatensatzes

Jeder verfügbare Knotentyp hat eine festgelegte Speichergröße für DAX das Zwischenspeichern von Daten. Wenn ein Knotentyp zu klein ist, passt der Arbeitsdatensatz, den eine Anwendung anfordert, nicht in den Speicher, was zu Cache-Fehlern führt. Da größere Knoten größere Caches unterstützen, sollten Sie einen Knotentyp verwenden, der größer ist als der geschätzte Datensatz, den Sie zwischenspeichern müssen. Ein größerer Cache verbessert auch die Cache-Trefferquote.

Sie erhalten möglicherweise abnehmende Ergebnisse, wenn Sie Elemente mit wenigen wiederholten Lesevorgängen zwischenspeichern. Berechnen Sie die Speichergröße für Elemente, auf die häufig zugegriffen wird, und stellen Sie sicher, dass der Cache groß genug ist, um diesen Datensatz zu speichern.

Berechnung der ungefähren Clusterkapazitätsanforderungen

Sie können den Gesamtkapazitätsbedarf Ihres Workloads abschätzen, um Ihnen bei der Auswahl der geeigneten Größe und Anzahl der Clusterknoten zu helfen. Um diese Schätzung durchzuführen, berechnen Sie die Variable normalisierte Anforderung pro Sekunde (normalisiertRPS). Diese Variable stellt die Gesamtzahl der Arbeitseinheiten dar, die der DAX Cluster für Ihre Anwendung unterstützen muss, einschließlich Cache-Treffer, Cache-Fehlschläge und Schreibvorgänge. Verwenden Sie die folgenden EingabenRPS, um den Wert „Normalisiert“ zu berechnen:

Mit der folgenden Formel können Sie den Normalisierten Wert berechnen. RPS

Normalized RPS = (ReadRPS_CacheHit * Size) + (ReadRPS_CacheMiss * Size * 10x_ReadMissFactor) + (WriteRequestRate * 25x_WriteFactor * Size * DaxNodeCount)

Betrachten Sie beispielsweise die folgenden Eingabewerte:

Wenn Sie diese Werte in der Formel einsetzen, können Sie den Wert Normalisiert RPS wie folgt berechnen.

Normalized RPS = (50,000 Cache Hits/Sec * 2KB) + (1,000 Cache Misses/Sec * 2KB * 10) + (100 Writes/Sec * 25 * 2KB * 3)

In diesem Beispiel ist der berechnete Wert von RPS Normalisiert 135.000. Dieser normalisierte RPS Wert berücksichtigt jedoch nicht, dass die Clusterauslastung unter 100% bleibt oder dass Knoten verloren gehen. Wir empfehlen, zusätzliche Kapazität einzukalkulieren. Ermitteln Sie dazu den größeren von zwei Multiplikationsfaktoren: Zielauslastung oder Knotenverlusttoleranz. Multiplizieren Sie dann den Wert Normalisiert RPS mit dem größeren Faktor, um eine Zielanforderung pro Sekunde (ZielRPS) zu erhalten.

Mit der folgenden Formel können Sie das Ziel berechnen. RPS

Target RPS = Normalized RPS * CEILING(TargetUtilization, NodeLossTolerance)

Um beispielsweise das Ziel zu berechnenRPS, sollten Sie die folgenden Werte berücksichtigen:

Wenn Sie diese Werte in der Formel einsetzen, können Sie das Ziel RPS wie folgt berechnen.

Target RPS = 135,000 * CEILING(1.43, 1.5)

Da in diesem Beispiel der Wert von größer als NodeLossTolerance istTargetUtilization, berechnen wir den Wert von Target RPS mit. NodeLossTolerance Dies gibt uns einen Zielwert RPS von 202.500, was der Gesamtkapazität entspricht, die der DAX Cluster unterstützen muss. Um die Anzahl der Knoten zu ermitteln, die Sie in einem Cluster benötigen, ordnen Sie das Ziel einer entsprechenden Spalte in der folgenden Tabelle RPS zu. Für dieses Beispiel mit einem Ziel RPS von 202.500 benötigen Sie den Knotentyp dax.r5.large mit drei Knoten.

Ungefähre Cluster-Durchsatzkapazität nach Knotentyp

Mithilfe von können Sie die Target RPS formula Clusterkapazität für verschiedene Knotentypen schätzen. Die folgende Tabelle zeigt ungefähre Kapazitäten für Cluster mit 1, 3, 5 und 11 Knotentypen. Diese Kapazitäten ersetzen nicht die Notwendigkeit, Lasttests DAX mit Ihren eigenen Daten und Anforderungsmustern durchzuführen. Darüber hinaus beinhalten diese Kapazitäten keine Instances vom Typ T, da es an fester CPU Kapazität mangelt. Die Einheit für alle Werte in der folgenden Tabelle ist RPS Normalisiert.

Aufgrund der Höchstgrenze von 1 Million NPS (Netzwerkoperationen pro Sekunde) für jeden Knoten tragen Knoten des Typs dax.r5.8xlarge oder größer nicht zur zusätzlichen Clusterkapazität bei. Knotentypen, die größer als 8xlarge sind, tragen möglicherweise nicht zur Gesamtdurchsatzkapazität des Clusters bei. Solche Knotentypen können jedoch hilfreich sein, um einen größeren Arbeitsdatensatz im Speicher zu speichern.

Skalierung der Schreibkapazität in DAX Clustern

Jeder Schreibzugriff DAX verbraucht 25 normalisierte Anfragen auf jedem Knoten. Da es für jeden Knoten ein RPS Limit von 1 Million gibt, ist ein DAX Cluster auf 40.000 Schreibvorgänge pro Sekunde begrenzt, wobei die Lesenutzung nicht berücksichtigt wird.

Wenn Ihr Anwendungsfall mehr als 40.000 Schreibvorgänge pro Sekunde im Cache erfordert, müssen Sie separate DAX Cluster verwenden und die Schreibvorgänge auf diese verteilen. Ähnlich wie bei DynamoDB können Sie den Partitionsschlüssel für die Daten, die Sie in den Cache schreiben, hashen. Verwenden Sie dann Modulus, um zu bestimmen, auf welchen Shard die Daten geschrieben werden sollen.

Im folgenden Beispiel wird der Hash einer Eingabezeichenfolge berechnet. Anschließend wird der Modul des Hashwerts mit 10 berechnet.

def hash_modulo(input_string):
    # Compute the hash of the input string
    hash_value = hash(input_string)

    # Compute the modulus of the hash value with 10
    bucket_number = hash_value % 10

    return bucket_number

#Example usage
if _name_ == "_main_":
    input_string = input("Enter a string: ")
    result = hash_modulo(input_string)
    print(f"The hash modulo 10 of '{input_string}' is: {result}.")