DynamoDB is a NoSQL database provided by Amazon Web Service (AWS). It can provide extremely high performance, more than 10 trillion requests per day with peaks greater than 20 million requests per second, and can support virtually any size with horizontal scaling. It is not uncommon for DynamoDB to serve over petabytes of data.

DynamoDB是Amazon Web Service(AWS)提供的NoSQL数据库。 它可以提供极高的性能，每天超过10万亿个请求，峰值超过每秒2000万个请求，并且可以通过水平扩展几乎支持任何规模。 DynamoDB服务超过PB数据的情况并不少见。

In this article, we will start with a brief introduction to the APIs of the DynamoDB. We will then look into the architecture of DynamoDB and explain in detail why DynamoDB can provide such high performance.

在本文中，我们将简要介绍DynamoDB的API。 然后，我们将研究DynamoDB的体系结构，并详细解释DynamoDB为什么可以提供如此高性能。

From a 10,000 feet view, DynamoDB is basically a key-value store. It can be thought as a hash-map backed by some persistent storage. Two most important operations supported by DynamoDB are Get and Put.

从10,000英尺的角度来看，DynamoDB本质上是键值存储。 可以将其视为由某些持久性存储支持的哈希映射。 DynamoDB支持的两个最重要的操作是Get和Put。

Unsurprisingly, the semantics of Get and Put operations are consistent with our understanding of hash-map or key-value store. For instance, we can use Put operation to persists a key-value pair to the DynamoDB and a subsequent Get operation will return the value we stored previously.

毫不奇怪，Get和Put操作的语义与我们对哈希映射或键值存储的理解是一致的。 例如，我们可以使用Put操作将键值对持久化到DynamoDB，随后的Get操作将返回我们先前存储的值。

Put(“key”, “value”);

Put(“键”，“值”);

Get(“Key”) → Returns “value”

Get(“键”)→返回“值”

What differentiates DynamoDB is its extremely high performance. In the next sections, we will closely examine the architecture of DynamoDB and understand why DynamoDB is so scalable.

DynamoDB的与众不同之处在于其极高的性能。 在下一部分中，我们将仔细检查DynamoDB的体系结构，并了解DynamoDB为什么如此可伸缩。

• Partitioning
  分区

To achieve horizontal scaling, DynamoDB assigns data to different partitions which are hosted by distinct machines. When there are more data, DynamoDB can create more partitions and use more machines to host those additional partitions. It works as following.

为了实现水平扩展，DynamoDB将数据分配给由不同机器托管的不同分区。 当有更多数据时，DynamoDB可以创建更多分区，并使用更多计算机来托管这些其他分区。 它的工作方式如下。

DynamoDB uses a cluster of machines and each machine is responsible for storing a portion of the data in its local disks. When a machine is added to the DynamoDB machine cluster, it is randomly assigned an integer value, which we call token in our article. In our example, we assume the DynamoDB has 3 machines. A is assigned a token of 100, B 2000 and C 10,000.

DynamoDB使用机器集群，每台机器负责将部分数据存储在其本地磁盘中。 将计算机添加到DynamoDB计算机群集时，会为它随机分配一个整数值，在本文中我们将其称为令牌。 在我们的示例中，我们假设DynamoDB具有3台计算机。 给A分配了代币100，B 2000和C 10,000。

When we insert a key-value pair to the DynamoDB, the key is first hashed into an integer, I. The key-value pair is then stored on the machine that we will meet first if we start from I and walk clockwise around the ring. Therefore keys that are hashed to (1000, 2⁶⁴-1] and [0, 100] are stored on machine A. Machine B therefore stores keys whose hash values are between 100 and 2000. The rest are stored on machine C.

当我们将一个键值对插入DynamoDB时，该键首先被散列为一个整数I。然后，如果我们从I开始并顺时针旋转环，则该键值对将存储在我们首先遇到的机器上。 因此，散列为(1000，2⁶⁴-1]和[0，100]的密钥存储在机器A上。因此，机器B存储其散列值在100到2000之间的密钥，其余的存储在机器C上。

If we receive a lot of data whose hash values are between (10,000, 30,000], machine A will probably be overloaded. What we can do now is add another machine D and split the data stored on A between A and D. Given that data are mostly between (10,000, 30,000], we could assign the machine D a token of 15,000. The load is then more or less evenly spread between machine A and D.

如果我们收到很多哈希值在(10,000，30,000)之间的数据，则机器A可能会过载。现在，我们可以做的是添加另一台机器D并将存储在A上的数据在A和D之间分割。通常在(10,000，30,000)之间，我们可以为机器D分配15,000的令牌，然后负载或多或少地平均分配到机器A和D之间。

When a range becomes hot, that is, we received a lot of data whose hash values fall inside the range, we could add more machines and assign those machine a token value within the range. With this change, the load and data are spread across more machine. If data are deleted and two consecutive ranges become cold, we can merge them. For example, if there is little data whose hash values are inside (100, 2000] and (2000, 10,000], we could remove machine B from the cluster and uses C to host those data.

当范围变热时，也就是说，我们收到了很多哈希值落在该范围内的数据，我们可以添加更多计算机，并为这些计算机分配该范围内的令牌值。 进行此更改后，负载和数据将分散到更多计算机上。 如果数据被删除并且两个连续的范围变冷，我们可以将它们合并。 例如，如果几乎没有哈希值在(100，2000]和(2000，10,000]之内的数据，我们可以从群集中删除计算机B，并使用C托管这些数据。

There are at least two benefits with this design.

这种设计至少有两个好处。

• First, there is basically no scaling limitations. We can always scale up the DynamoDB to store more data by adding more machines.
  首先，基本上没有缩放限制。 我们总是可以通过添加更多计算机来扩大DynamoDB的规模，以存储更多数据。
• Second, this enables incremental scalability. When we first bring up a DynamoDB, we don’t need to allocate a lot of machines. We can add more machines as we have more data. This can greatly save resources.
  其次，这实现了增量可伸缩性。 首次启动DynamoDB时，不需要分配很多机器。 随着我们拥有更多数据，我们可以添加更多机器。 这样可以大大节省资源。

Note that different keys may be hashed to the same value. It is fine because the hash value only decides which machine hosts the data. We retrieve the value from that machine based on the key, not its hash value.

请注意，不同的键可能会散列为相同的值。 很好，因为哈希值仅决定哪台计算机承载数据。 我们基于密钥而不是其哈希值从该计算机检索值。

• Replication
  复写

If the data is only stored on one machine, it is not very reliable nor available. When the machine crashes or the disk is corrupted, the data is lost. When the machine is down, we can’t access the data. To resolve the issue, DynamoDB replicates the data N times. We will assume N=3 in our article, which is commonly used in AWS.

如果数据仅存储在一台计算机上，则它不是很可靠也不可用。 当计算机崩溃或磁盘损坏时，数据将丢失。 机器停机时，我们无法访问数据。 为了解决此问题，DynamoDB将数据复制N次。 我们将在文章中假设N = 3，这在AWS中是常用的。

Each machine has complete knowledge of the tokens of all machines inside the cluster. For example, all machines know that A has a token value of 100.

每台机器都完全了解集群中所有机器的令牌。 例如，所有机器都知道A的令牌值为100。

When a machine receives a request to persist data, it will forward the request to other two machines that have the next two greater tokens. For instance, when machine A receives a request to store {“key”: “value”}, it will first find out which two machines have the next two greater tokens, and in our case, it is machine B and C. It then sends the request to persist the key-value pair to machine B and C.

当一台机器接收到持久化数据的请求时，它将把请求转发给其他两个具有下两个更大令牌的机器。 例如，当机器A收到存储{“ key”：“ value”}的请求时，它将首先找出哪两个机器具有下两个更大的令牌，而在我们的示例中是机器B和C。将保留键值对的请求发送到机器B和C。

Machine A considers the data persisted after it receives responses from both machine B and C. It then sends the response back to the client. However, this has an issue. Without replication, the request processing is slow only when machine A is slow. Now the processing is slow when any of the 3 machines is slow.

机器A接收到来自机器B和机器C的响应后，认为数据仍然存在。然后将响应发送回客户端。 但是，这有一个问题。 如果没有复制，则仅当计算机A缓慢时，请求处理才会缓慢。 现在，当3台计算机中的任何一台计算机运行缓慢时，处理速度就会变慢。

To resolve the issue, DynamoDB doesn’t require receiving responses from all N machines before returning to the client. It only requires W machines to write the data to the disk. W is normally set to 2 in AWS. In our case, machine A returns to the client when 2 of the following events have happened

要解决此问题，DynamoDB不需要在返回客户端之前从所有N台计算机接收响应。 它仅需要W机器将数据写入磁盘。 W在AWS中通常设置为2。 在我们的案例中，当以下两个事件发生时，机器A返回到客户端

• Write to disk inside A succeeds
  写入A内的磁盘成功
• Received response from B
  收到B的回应
• Received response from C
  收到C的回应

Note that machine A could actually receive response from B and C before it completes writing to its local disk if its disk is overloaded.

请注意，如果计算机A的磁盘过载，则它实际上可以在完成对本地磁盘的写入之前从B和C接收响应。

This approach reduces write latency, it however introduces another issue. You may not be able to read the value you just wrote into the database! Imagine the case that machine A received response from B and C and returns to the client. However the write to its local disk actually fails. Then when client wants to get the value, A would return a wrong result since its local disk doesn’t have the recently updated data.

这种方法减少了写入延迟，但是却引入了另一个问题。 您可能无法读取刚刚写入数据库的值！ 想象一下机器A从B和C接收到响应并返回给客户端的情况。 但是，写入本地磁盘实际上失败。 然后，当客户端想要获取该值时，A将返回错误的结果，因为其本地磁盘没有最新更新的数据。

DynamoDB thus further requires machine A to get R copies of data and return the latest copy to the client. R+W should be greater than N and we can guarantee the user will always see the latest data. R is normally set to 2. In our case, machine A is required to get a copy of the data from at least one of the machine B and C and return the latest value to the client. Therefore the correct value will be returned.

因此，DynamoDB进一步要求机器A获得R数据副本并将最新副本返回给客户端。 R + W应该大于N，我们可以保证用户将始终看到最新数据。 R通常设置为2。在我们的情况下，需要机器A从机器B和C中至少一个获得数据的副本，并将最新值返回给客户端。 因此，将返回正确的值。

With partitioning and replication, DynamoDB is therefore able to provide both scalable and reliable service!

通过分区和复制，DynamoDB因此能够提供可扩展和可靠的服务！

If you are interested in the architecture of AuroraDB, another featured database from AWS, you can read it from my other blog [Click here].

如果您对AuroraDB的架构感兴趣，AuroraDB是AWS的另一个特色数据库，则可以从我的其他博客中阅读[单击此处] 。