1
votes

I am working on Benchmarking Dynamodb's performance as part of a project at the university and have been looking for more details on the replication system when setting up Global tables as i want to understand its impact on latency / Throughput. I end up by finding 2 confusing Concept, Regions and Availability zones. From what i understood here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.CrossRegionRepl.html By Creating 2 Tables, one in Frankfurt and one in Ireland let's say, This means that i now have 2 multi-master read/write Replicas.

But then i found those links: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html https://aws.amazon.com/blogs/aws/new-for-amazon-dynamodb-global-tables-and-on-demand-backup/

explaining that the data is stored and automatically replicated across multiple Availability Zones in an AWS region but not mentioning the number of replicas and whether they can be used for read / write requests and are also multi-master or slaves or just for recovery purposes. From what i understood here if going back to the example i am using (Frankfurt / Ireland) I will be having: 3 multi-master read/write Replicas in Frankfurt 3 multi-master read/write Replicas in Ireland

Please let me know which one is correct. Thanks in Advance

1

1 Answers

4
votes

Dyanmodb by default puts your data to tables in multiple availability zone irrespective of if it is a global table or not. This is to make sure higher availability in case of one zone going down. However these partition are transparent to the user, and user don't get to choose which one to connect to. Here is a nice video explaining how it works under the hood.

Global table means that data will be replicated across the regions transparently to the user. I did a benchmarking with table in two regions oregon and ohio, it typically took ~1.5 secs. to get replicated. Replication resolution is auto managed by AWS and the last write one wins.

A personal suggestion here is to use only one table to write so that data collision can be minimized. And in the case of disaster failover writes to other region.