Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dimensionnement de votre cluster DAX

La capacité et la disponibilité totales d'un DAX cluster dépendent du type et du nombre de nœuds. Un plus grand nombre de nœuds dans le cluster augmente sa capacité de lecture, mais pas sa capacité d'écriture. Les types de nœuds plus importants (jusqu'à r5,8xlarge) peuvent gérer un plus grand nombre d'écritures, mais un nombre insuffisant de nœuds peut avoir un impact sur la disponibilité en cas de défaillance d'un nœud. Pour plus d'informations sur le dimensionnement de votre DAX cluster, consultez leGuide de dimensionnement de cluster DAX.

Les sections suivantes traitent des différents aspects du dimensionnement que vous devez prendre en compte pour équilibrer le type et le nombre de nœuds afin de créer un cluster évolutif et rentable.

Planification de la disponibilité

Lorsque vous dimensionnez un DAX cluster, vous devez d'abord vous concentrer sur sa disponibilité ciblée. La disponibilité d'un service en cluster, par exempleDAX, est une dimension du nombre total de nœuds du cluster. Étant donné qu'un cluster à nœud unique ne tolère aucune défaillance, sa disponibilité est égale à un nœud. Dans un cluster à 10 nœuds, la perte d'un seul nœud a un impact minimal sur la capacité globale du cluster. Cette perte n'a pas d'impact direct sur la disponibilité car les nœuds restants peuvent toujours répondre aux demandes de lecture. Pour reprendre les écritures, désigne DAX rapidement un nouveau nœud principal.

DAXest VPC basé sur. Il utilise un groupe de sous-réseaux pour déterminer les zones de disponibilité dans lesquelles il peut exécuter des nœuds et les adresses IP à utiliser à partir des sous-réseaux. Pour les charges de travail de production, nous vous recommandons vivement d'utiliser DAX au moins trois nœuds situés dans différentes zones de disponibilité. Cela garantit que le cluster dispose de plus d'un nœud pour traiter les demandes, même en cas de défaillance d'un seul nœud ou d'une seule zone de disponibilité. Un cluster peut comporter jusqu'à 11 nœuds, dont un est un nœud principal et 10 sont des répliques de lecture.

Planification du débit d'écriture

Tous les DAX clusters disposent d'un nœud principal pour les demandes d'écriture directe. La taille du type de nœud du cluster détermine sa capacité d'écriture. L'ajout de répliques de lecture supplémentaires n'augmente pas la capacité d'écriture du cluster. Par conséquent, vous devez tenir compte de la capacité d'écriture lors de la création du cluster, car vous ne pourrez pas modifier le type de nœud ultérieurement.

Si votre application a besoin d'une procédure d'écriture pour mettre DAX à jour le cache d'éléments, envisagez d'utiliser davantage les ressources du cluster pour faciliter l'écriture. Les écritures contre DAX consomment environ 25 fois plus de ressources que les lectures en cache. Cela peut nécessiter un type de nœud plus important que pour les clusters en lecture seule.

Pour obtenir des conseils supplémentaires sur la manière de déterminer si la version écrite ou écrite convient le mieux à votre candidature, consultez. Politiques pour les écritures

Planification du débit de lecture

La capacité de lecture d'un DAX cluster dépend du taux de réussite du cache de votre charge de travail. Dans la mesure où DynamoDB DAX lit les données en cas d'échec du cache, il consomme environ 10 fois plus de ressources de cluster qu'un accès au cache. Pour augmenter le nombre d'accès au cache, augmentez les TTLparamètres du cache afin de définir la période pendant laquelle un élément est stocké dans le cache. Une TTL durée plus longue augmente toutefois les chances de lire les anciennes versions des éléments, à moins que les mises à jour ne soient écritesDAX.

Pour vous assurer que le cluster dispose d'une capacité de lecture suffisante, redimensionnez-le horizontalement comme indiqué dansMise à l'échelle horizontale d'un cluster. L'ajout de nœuds supplémentaires ajoute des répliques de lecture au pool de ressources, tandis que la suppression de nœuds réduit la capacité de lecture. Lorsque vous sélectionnez le nombre de nœuds et leur taille pour un cluster, tenez compte de la capacité de lecture minimale et maximale requise. Si vous ne pouvez pas redimensionner horizontalement un cluster avec des types de nœuds plus petits pour répondre à vos exigences de lecture, utilisez un type de nœud plus grand.

Taille du jeu de données de planification

Chaque type de nœud disponible possède une taille de mémoire définie pour DAX mettre en cache les données. Si le type de nœud est trop petit, l'ensemble de données de travail demandé par une application ne tiendra pas sa place dans la mémoire et entraînera des erreurs de cache. Étant donné que les nœuds de grande taille prennent en charge des caches de plus grande taille, utilisez un type de nœud supérieur à l'ensemble de données estimé que vous devez mettre en cache. Un cache plus important améliore également le taux de réussite du cache.

Vous pouvez obtenir des rendements décroissants pour la mise en cache d'éléments après quelques lectures répétées. Calculez la taille de la mémoire pour les éléments fréquemment consultés et assurez-vous que le cache est suffisamment grand pour stocker cet ensemble de données.

Calcul approximatif des exigences de capacité du cluster

Vous pouvez estimer les besoins en capacité totale de votre charge de travail pour vous aider à sélectionner la taille et le nombre appropriés de nœuds de cluster. Pour effectuer cette estimation, calculez la variable demande normalisée par seconde (normaliséeRPS). Cette variable représente le nombre total d'unités de travail que votre application doit prendre en charge par le DAX cluster, y compris les accès au cache, les erreurs de cache et les écritures. Pour calculer la valeur normaliséeRPS, utilisez les entrées suivantes :

À l'aide de la formule suivante, vous pouvez calculer la valeur normalisée. RPS

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

Par exemple, considérez les valeurs d'entrée suivantes :

En substituant ces valeurs dans la formule, vous pouvez calculer la valeur normalisée RPS comme suit.

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

Dans cet exemple, la valeur calculée de Normalized RPS est 135 000. Toutefois, cette RPS valeur normalisée ne tient pas compte du maintien de l'utilisation du cluster en dessous de 100 % ou de la perte de nœuds. Nous vous recommandons de prendre en compte les capacités supplémentaires. Pour ce faire, déterminez le plus élevé des deux facteurs multiplicateurs : l'utilisation cible ou la tolérance à la perte de nœuds. Multipliez ensuite la valeur normalisée RPS par le facteur le plus élevé pour obtenir une demande cible par seconde (cibleRPS).

À l'aide de la formule suivante, vous pouvez calculer la cibleRPS.

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

Par exemple, pour calculer TargetRPS, considérez les valeurs suivantes :

En substituant ces valeurs dans la formule, vous pouvez calculer la cible RPS comme suit.

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

Dans cet exemple, étant donné que la valeur de NodeLossTolerance est supérieure àTargetUtilization, nous calculons la valeur de Target RPS avecNodeLossTolerance. Cela nous donne un objectif RPS de 202 500, soit la capacité totale que le DAX cluster doit prendre en charge. Pour déterminer le nombre de nœuds dont vous aurez besoin dans un cluster, mappez la cible RPS à une colonne appropriée dans le tableau suivant. Pour cet exemple d'une cible RPS de 202 500, vous avez besoin du type de nœud dax.r5.large avec trois nœuds.

Approximation de la capacité de débit du cluster par type de nœud

À l'aide duTarget RPS formula, vous pouvez estimer la capacité du cluster pour différents types de nœuds. Le tableau suivant indique les capacités approximatives des clusters de 1, 3, 5 et 11 types de nœuds. Ces capacités ne remplacent pas la nécessité d'effectuer des tests de charge DAX avec vos propres données et modèles de demandes. De plus, ces capacités n'incluent pas les instances de type t en raison de leur manque de CPU capacité fixe. L'unité de toutes les valeurs du tableau suivant est normalisée. RPS

En raison de la limite maximale de 1 million NPS (opérations réseau par seconde) pour chaque nœud, les nœuds de type dax.r5.8xlarge ou supérieur ne contribuent pas à augmenter la capacité du cluster. Les types de nœuds supérieurs à 8 x peuvent ne pas contribuer à la capacité de débit totale du cluster. Cependant, ces types de nœuds peuvent être utiles pour stocker un ensemble de données de travail plus important en mémoire.

Dimensionnement de la capacité d'écriture dans les DAX clusters

Chaque écriture sur DAX consomme 25 requêtes normalisées sur chaque nœud. Comme il existe une RPS limite d'un million par nœud, un DAX cluster est limité à 40 000 écritures par seconde, sans tenir compte de l'utilisation en lecture.

Si votre cas d'utilisation nécessite plus de 40 000 écritures par seconde dans le cache, vous devez utiliser des DAX clusters distincts et partager les écritures entre eux. Comme dans DynamoDB, vous pouvez hacher la clé de partition pour les données que vous écrivez dans le cache. Utilisez ensuite le module pour déterminer dans quelle partition écrire les données.

L'exemple suivant calcule le hachage d'une chaîne d'entrée. Il calcule ensuite le module de la valeur de hachage avec 10.

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}.")