Comment DynamoDB gère le débit des lectures indépendamment des écritures

Question

Amazon DynamoDB autorise le client à provision the throughput of reads and writes independently. J'ai lu le Amazon Dynamo paper sur le système qui a précédé DynamoDB et j'ai lu comment Cassandra et Riak ont ​​implémenté ces idées. Je comprends comment il est possible d'augmenter le débit de ces systèmes en ajoutant des nœuds au cluster qui divise ensuite l'espace de hachage des tables sur plusieurs nœuds, permettant ainsi un débit plus important tant que l'accès est relativement aléatoire entre les clés de hachage. Mais dans des systèmes comme Cassandra et Riak, cela ajoute du débit aux lectures et aux écritures en même temps.

Comment DynamoDB est-il architecturé différemment pour pouvoir mettre à l'échelle les lectures et écrire indépendamment? Ou ne le sont-ils pas et Amazon les charge indépendamment pour eux, même s'ils doivent essentiellement allouer suffisamment de nœuds pour couvrir le plus grand des deux?

Answer 1

Vous avez raison de dire que l'ajout de nœuds à une grappe devrait augmenter la quantité de débit disponible, mais ce serait par grappe et non par table. Le cluster DynamoDB est une ressource partagée entre plusieurs tables sur de nombreux comptes. C'est comme un nœud EC2: vous payez pour une machine virtuelle mais cette machine virtuelle est hébergée sur une machine réelle qui est partagée entre plusieurs machines virtuelles EC2 et selon le type d'instance, vous obtenez une certaine quantité de mémoire, CPU, IO réseau Ce que vous payez lorsque vous payez pour le débit est E/S et vous pouvez les réguler indépendamment. Payer plus de débit ne force pas Amazon à partitionner votre table sur plusieurs noeuds. La seule chose qui provoque une partition d'un tableau est si la taille de votre table augmente au point où plus de partitions sont nécessaires pour stocker les données de votre table. La taille maximale de la partition, d'après les informations que j'ai recueillies auprès des ingénieurs de DynamoDB, est basée sur la taille des disques SSD des nœuds du cluster.

L'astuce avec le débit provisionné est qu'il est divisé entre les partitions. Donc, si vous avez une partition chaude, vous pouvez obtenir une limitation et ProvisionedThroughputExceededExceptions même si vos demandes totales ne dépassent pas le débit total de lecture ou d'écriture. Ceci est contraire à ce que votre question demande. Vous vous attendriez à ce que si votre table est divisée entre plus de partitions/noeuds, vous obtiendrez plus de débit, mais en réalité c'est le contraire à moins que vous n'égaliez votre débit avec la taille de votre table.