Fiabilité des compteurs atomiques dans DynamoDB

Question

J'envisageais d'utiliser Amazon DynamoDB dans mon application, et j'ai une question concernant son fiabilité des compteurs atomiques .

Je suis en train de créer une application distribuée qui doit simultanément et de manière cohérente , incrémenter / décrémenter un compteur stocké dans un attribut Dynamo. Je me demandais à quel point le compteur atomique du Dynamo était fiable dans un environnement concurrentiel lourd, où le niveau de concurrence est extrêmement élevé (disons, par exemple, un taux moyen de 20k hits simultanés - pour avoir l'idée, ce serait près de 52 milliards d'incréments/ décréments par mois).

Le compteur doit être extrêmement fiable et ne jamais manquer un coup.Quelqu'un a-t-il testé DynamoDB dans des environnements aussi critiques?

Merci

Answer 1

DynamoDB obtient ses propriétés de mise à l'échelle en répartissant les clés sur plusieurs serveurs. Ceci est similaire à la façon dont d'autres bases de données distribuées telles que Cassandra et HBase se mettent à l'échelle. Bien que vous puissiez augmenter le débit sur DynamoDB, cela ne fait que déplacer vos données vers plusieurs serveurs et maintenant chaque serveur peut gérer le nombre total de connexions simultanées / nombre de serveurs. Jetez un œil à à leur FAQ / a> pour une explication sur la façon d'atteindre un débit maximal:

Q: Pourrai-je toujours atteindre mon niveau de débit provisionné?

Amazon DynamoDB suppose un modèle d'accès relativement aléatoire sur toutes les clés primaires. Vous devez configurer votre modèle de données de sorte que vos demandes aboutissent à une répartition assez uniforme du trafic entre les clés primaires. Si vous avez un modèle d'accès très irrégulier ou biaisé, vous ne pourrez peut-être pas atteindre votre niveau de débit provisionné.

Lors du stockage des données, Amazon DynamoDB divise une table en plusieurs partitions et distribue les données en fonction de l'élément clé de hachage de la clé primaire. Le débit provisionné associé à une table est également divisé entre les partitions; Le débit de chaque partition est géré indépendamment en fonction du quota qui lui est alloué. Il n'y a pas de partage du débit provisionné entre les partitions. Par conséquent, une table dans Amazon DynamoDB est mieux à même de répondre aux niveaux de débit provisionnés si la charge de travail est répartie de manière assez uniforme sur les valeurs de clé de hachage. La distribution des demandes entre les valeurs de clé de hachage distribue les demandes entre les partitions, ce qui vous aide à atteindre votre niveau de débit provisionné complet.

Si vous avez un modèle de charge de travail inégal entre les clés primaires et que vous ne parvenez pas à atteindre votre niveau de débit provisionné, vous pourrez peut-être répondre à vos besoins en débit en augmentant davantage votre niveau de débit provisionné, ce qui donnera plus de débit à chaque partition. Cependant, il est recommandé d'envisager de modifier votre modèle de demande ou votre modèle de données afin d'obtenir un modèle d'accès relativement aléatoire entre les clés primaires.

Cela signifie qu'avoir une clé incrémentée directement ne sera pas mise à l'échelle puisque cette clé doit vivre sur un serveur. Il existe d'autres moyens de gérer ce problème, par exemple dans l'agrégation de mémoire avec un incrément de vidage vers DynamoDB (bien que cela puisse avoir des problèmes de fiabilité) ou un compteur partitionné où les incréments sont répartis sur plusieurs clés et relus en tirant toutes les clés dans le partitionné counter ( http://whynosql.com / scaling-shared-counters / ).

Answer 2

En plus de la réponse de gigq sur l'évolutivité, les incréments atomiques DynamoDB ne sont pas idempotents et ne sont donc pas fiables: si la connexion tombe après avoir émis une requête UpdateItem ADD, vous n'avez aucun moyen de savoir si l'ajout a été validé ou non, donc vousje ne sais pas si vous devez réessayer ou non.

Les mises à jour conditionnelles DynamoDB corrigent ce problème, au prix de rendre le système encore moins évolutif, car vous devez réessayer chaque fois que deux modifications de l'attribut sont tentées simultanément, même en l'absence d'erreur.

Answer 3

si vous allez écrire une seule clé de base de données dynamo, vous souffrirez d'un problème de partition chaude .Le problème de partition à chaud commence autour de 300 TPS par index.Donc, si vous avez 5 index dans la table, vous pouvez voir un problème de partition chaude autour de 300/5 ~ 60 TPS.

Sinon, dynamo db est évolutif à environ 10-40K TPS, selon votre cas d'utilisation.