Today we look at Dynamodb's design ideas.
Dynamodb primarily wants to achieve high availability (availability) because of the CAP theory, so only consistency is sacrificed, but eventual consistency is achieved. It also wants to achieve the goal of high scalability (scalability), which facilitates horizontal scaling, meaning that high availability and high scalability are the two goals that Dynamodb has to achieve because it is a distributed system, Therefore the failure treatment needs to be treated to the same as normal conditions.
Dynamodb also uses a consistent hash (consistent hashing) without exception to partition and replicate the data. Its data consistency is implemented using the object version (versioning). Let's take a look at how Dynamodb achieves eventual consistency.
The final consistency of DYNAMODB implementation solves two problems, and the first question is when to resolve the update conflict, that is, if the conflict is to be resolved at read or write time. Many data storage systems are conflict-resolved at the time of writing, in which case the write operation is likely to be rejected if all copies of the data are not agreed. Dynamodb is always writable, so it can be used for conflict resolution when reading.
The second question is who will resolve the update conflict. The data storage system can also be used to resolve conflicts. If the data storage System resolves the conflict, then only simple policies, such as last write wins, are available. Here dynamodb can make the application resolve the conflict, because the app knows how to choose the right data, which is to kick the ball to the app. In addition, if the application does not want to resolve the conflict, it can choose to let Dynamodb solve it, of course, it will use the last write effective strategy to resolve the conflict, so the design is really flexible.
Several features of Dynamodb:
1 is always writable.
2 all nodes in a single admin domain are trusted.
3 No hierarchical naming is required.
4 Read and write operations can be done at a level of hundred milliseconds in 99.9% of cases. So it does not rely on multi-hop routing (multi Hop routing), but is implemented by Zero-hop DHT.
Original: http://blog.csdn.net/hongchangfirst/article/details/26818503
Author: Hongchangfirst
Hongchangfirst's homepage: http://blog.csdn.net/hongchangfirst