DynamoDB

DynamoDB is a fully managed, serverless NoSQL database service provided by Amazon Web Services (AWS). It provides fast and predictable performance with seamless scalability. DynamoDB is a key-value and document database that uses SSD storage and is spread across three geographically distinct data centers. It is highly available, with replication across multiple availability zones. DynamoDB is a great choice for applications that need very low latency access to data, the ability to scale storage and throughput up or down as needed, and high availability and durability of data.

Let’s understand some aspects of the DynamoDB design that are useful as system design practitioners. Some of our design principles of a generic key-value store are directly applicable to DynamoDB.

No fixed schema

DynamoDB aims to have no fixed schema in its design. This allows DynamoDB to support a multitude of applications and use cases. To meet the diverse needs of a broad customer base, a database design must be versatile, scalable, and high-performing, which is fulfilled by a NoSQL database.

Unlike RDBMS, which requires a predetermined schema to build indexes, NoSQL databases offer flexibility by deferring schema decisions to read time. This enables easy API integration and accommodates various use cases.

The benefits of NoSQL

• Flexibility: NoSQL databases can store unstructured or semi-structured data, allowing data from multiple tables in a normalized RDBMS to reside in a single document. This ease of use simplifies API coding and enhances functionality.
• Scalability: NoSQL databases store data in documents rather than tables, simplifying scaling processes. Unlike RDBMS, which is tightly linked to its storage hardware, NoSQL can easily distribute its databases across large clusters, providing a more straightforward scaling mechanism.
• Performance: The data models used in NoSQL databases are engineered for optimal performance, which is especially important for large-scale operations.
• Availability: NoSQL databases ensure high availability by enabling seamless node replacement and easier partitioning. This feature also minimizes downtime during node failures by rerouting requests to replica shards.

In the NoSQL setup, data is organized into tables built atop a key-value store. Tables may contain zero or more items identified by primary keys. Each item consists of one or more attributes, considered as basic data types such as strings or numbers.

API functions

The following are some of the API functions:

• PutItem: Adds or replaces an item based on the input key
• UpdateItem: Modifies an existing item or creates a new one if it doesn’t exist
• DeleteItem: Removes an item identified by its primary key
• GetItem: Retrieves an item’s attributes based on its primary key

Partitioning data in DynamoDB

In DynamoDB, data is partitioned horizontally across multiple storage servers. To recap, there are two ways to partition data – vertically or horizontally. For vertical partitioning, there is a need to know the schema beforehand. Since DynamoDB has no schema, and since we need to support a large number of rows, horizontal partitioning is the preferred option. Each table will be split into partitions, with each partition backed by SSD storage.

Figure 5.6 shows the vertical and horizontal partitioning of data.

Figure 5.6: Vertical and horizontal data partitioning in DynamoDB

Primary key types

To locate an item in a partition, for a lookup or update, there are two schemas – a partition key, and a partition key with a sort key (also called a composite key):

• A partition Key: Determines an item’s storage location through a hash function.
• A composite key: Consists of a partition key and a sort key. The hash function output, coupled with the sort key, identifies the item’s storage location.

Figure 5.7 shows an example of the partition key, sort key, and composite keys in DynamoDB. The hash is applied to the partition key, which along with the sort key, determines the location of the key on the backend storage node.

Figure 5.7: Partition keys, sort keys, and composite keys in DynamoDB

Secondary indexes

DynamoDB's design accommodates alternative querying keys, in addition to primary keys, providing more query options.

Throughput optimizations in DynamoDB

In the context of database management, specifically in DynamoDB, the optimization of throughput allocation is of utmost importance. Throughput, in this case, refers to the rate at which a system can fulfill read or write requests. Efficiently partitioning the tables and managing throughput can lead to increased performance and reduced downtime.

In the next section, we will briefly cover read and write capacity units in DynamoDB and ways in which bursting and adaptive capacity management are used to increase throughput.

Throughput allocation

DynamoDB allows you to set a provisioned throughput, the upper limit of read capacity units and write capacity units (RCUs and WCUs) that a system will allocate for your tables. Initial partitioning spreads this allocated throughput equally across all partitions, assuming each key within those partitions will be accessed uniformly. However, this is often not the case in real-world applications, leading to inefficiencies such as underutilized or overloaded partitions.

RCUs and WCUs are metrics that gauge a system’s ability to complete read and write requests, respectively. These units are crucial when discussing throughput optimization. For example, if a table has a provisioned throughput of 20,000 RCUs and 5,000 WCUs, it implies that the system can, at maximum capacity, read 20,000 items and write 5,000 items per second for an item of a given arbitrary size.

In DynamoDB, you may need to add or remove partitions based on data storage or throughput needs. When you alter the number of partitions, the provisioned throughput will need to be redistributed among the existing partitions. For instance, if a table initially had 10 partitions, each with 2,000 RCUs and 500 WCUs, and you add 10 more, the throughput of each partition would be halved to accommodate the new partitions.

Let’s now understand how bursting can help with throughput management, with unevenly distributed reads and writes in a DynamoDB table.

Bursting – short-term overprovisioning

In real-world scenarios, applications or users can disproportionately access certain keys, causing uneven distribution of requests across partitions. Bursting is a strategy to temporarily tap into any unused throughput from neighboring partitions to manage these short-term spikes in demand.

When allowing for bursting, it’s essential to ensure workload isolation so that the extra throughput of one partition does not interfere with the regular operations of its neighboring partitions. This ensures that short-term gains in one partition do not compromise the overall system’s performance. Figure 5.8 shows the advantage of supporting bursting in DynamoDB, which allows it to serve more requests.

Figure 5.8: Comparing the reads/sec served without bursting and with bursting support in DynamoDB

A token bucket system

A token bucket system can be implemented at the node level to manage the bursting mechanism. Two buckets are maintained – the allocated throughput bucket and the available burst throughput bucket. If the regular bucket is empty (i.e., its provisioned throughput is exhausted), the system checks for available tokens in the burst bucket. If tokens are there, the partition is allowed to burst, temporarily exceeding its provisioned limits.

Bursting is beneficial for short-term uneven workload distribution, but if we need a more long-term approach to throughput management, DynamoDB design also supports adaptive capacity management, which we will cover next.

Adaptive capacity – long-term adjustments

While bursting handles short-term spikes in demand, adaptive capacity aims to reallocate throughput based on long-term usage patterns. This means that if certain partitions are consistently underutilized while others are overwhelmed, DynamoDB will gradually redistribute throughput to accommodate these patterns.

How it works

Under the hood, DynamoDB uses algorithms that study usage patterns over time, identifying hot partitions (partitions that are consistently accessed more frequently) and cold partitions (those less frequently accessed). A system then reallocates RCUs and WCUs accordingly. This ensures that your read and write operations are more evenly distributed, reducing the likelihood of throttling on busy partitions.

Adaptive capacity is effective but not instantaneous. It may take some time for a system to learn the access patterns and reallocate resources. Also, there is an upper limit to how much a single partition’s throughput can be increased.

In the next section, we will learn about global admission control.

Global admission control – cross-partition management

Global admission control is a technique used to manage throughput across all partitions. While adaptive capacity focuses on individual partitions, global admission control takes a more holistic approach, managing resources at the table level.

One approach is to set a global limit on the number of operations per second, distributing this limit among partitions based on their load. This ensures that no single partition overwhelms a system, providing a more balanced throughput distribution.

Splitting for consumption – proactive partition management

If you anticipate a drastic change in the load pattern, you might decide to manually split or merge partitions to prepare for it. This is called “splitting for consumption.”

For splitting, you could use key range partitioning or hash partitioning, depending on your data distribution and access patterns. The aim is to redistribute data such that each partition gets an equal share of the load, thereby maximizing throughput efficiency.

In conclusion, optimizing throughput allocation in a partitioned DynamoDB database involves multiple layers of strategies, each with its unique advantages and limitations. By understanding and judiciously applying these methods, you can significantly enhance the performance, reliability, and efficiency of your database operations.

In the next section, we will cover how DynamoDB is designed for high availability for reads and writes.

High availability in DynamoDB

High availability is a cornerstone of any large-scale database architecture, and DynamoDB is no exception. In this section, we will explore the various aspects that contribute to the high availability of reads and writes in DynamoDB. Let’s first discuss the high availability of write requests in DynamoDB.

Write availability

DynamoDB’s architecture adopts a partitioned model where tables are divided into partitions, and each partition is further replicated. These replicas of the same partition are termed a replication group. Leadership among these replicas is determined via a multi-Paxos-based leader election process. We covered the basics of leader election and multi-Paxos in Chapter 3. The leader replica manages all write requests by first logging them into a write-ahead log and then indexing them into memory. The leader replica later disseminates this write-ahead log and tree index to other replicas within the replication group.

The key to write availability is ensuring that a sufficient number of healthy replicas are available to form a write quorum. One robust strategy to maintain this availability is for the leader replica to promptly recruit another member into the replication group if it detects that a replica has become unresponsive or faulty.

For instance, let’s consider four replication groups. Nodes from group 3 may also be a part of group 2. If a node in replication group 4 becomes faulty but two-thirds of the nodes are still operational, it may appear that a quorum can still be formed. However, if the leader replica itself fails, achieving a quorum becomes impossible. This highlights the critical role of a healthy leader, as it’s responsible for both processing writes and coordinating the election of a new leader if there are replica failures.

Now, let’s discuss eventually consistent reads in DynamoDB.

Read availability

Read availability in DynamoDB is gauged by its ability to consistently return the most recent write upon a read request. DynamoDB’s replication system offers eventual read consistency, with instant consistent reads provided solely by the leader replica. Therefore, it is crucial to ensure the leader replica’s health for consistent read availability.

In DynamoDB, much hinges on the leader replica’s reliability. If a leader fails, a new leader cannot take over until the previous leader’s lease expires. To preemptively address this, the system should have rapid and accurate failure detection mechanisms. This is complicated by “gray failures,” which are not straightforward to identify. A reliable way to counter gray failures is to establish communication protocols among replicas to confirm the leader replica’s status before initiating a leader election.

By adopting these practices and philosophies, you can ensure that your DynamoDB database remains highly available, scalable, and efficient, thereby meeting the needs of your ever-evolving application landscape.

In conclusion, DynamoDB is a robust, serverless NoSQL database offered by AWS, designed for high performance, scalability, and availability. Its flexible, schema-less architecture accommodates a wide range of applications and workflows. The database efficiently manages throughput via mechanisms such as partitioning, bursting, and adaptive capacity. It also ensures high availability through replication groups and leader election processes for write and read operations. Overall, DynamoDB’s multilayered strategies for throughput optimization and high availability make it a reliable, efficient choice for any large-scale, low-latency application.