Amazon DynamoDB

Motivation

Database as a service is an example of a managed database where any hardware provisioning, scaling, or shrinking of resources with dynamic load, sharding, replication, and many database administrative tasks is performed by the system. The end users of such a managed database use queries to interact with it. AWS’s DynamoDB is an example of such a database. In this lesson, we will see how DynamoDB is designed.

Design requirements

Here are our design requirements.

Functional requirements

We require the following functional design requirements:

1. Managed service over the cloud: We will deploy our service on a managed cloud. Our users will not need to manage security patches, hardware, and distributed services. Our service will handle resource provisioning, failure management, software upgrades, and backups. Application users will interact with our service via API.

2. Multi-tenant architecture: Different customers will share resources. For example, a single customer can use multiple nodes that other customers can also use. This will ensure high utilization of resources and allow the service to pass the saved costs to the customer.

Non-functional requirements

Now, let’s list our non-functional requirements.

1. Easy horizontal scaling: Database tables should be able to scale elastically to meet the demands of our users’ applications. We’ll spread tables across multiple nodes with our multi-tenant architecture; their maximum size is not dependent on a single node’s resources.

2. Predictable performance: To design a reliable service that many consumers can adopt, we need to offer a widely accepted level of performance.

3. High availability: We will aim for an SLA of five nines (99.999) for global tables (replicated across zones) and four nines (99.99) for local tables (replicated within zones).

4. Flexible use cases: Catering to a wide market requires our service to be adaptable to an equally wide range of requirements. We will not force our users into a data model. Our service doesn’t have a fixed schema. Instead, our data can have varying types. It can also have attributes with more than one value. The data model our tables will use can be any NoSQL data model.

Now, we will discuss our design.

DynamoDB architecture

There are numerous components in the system, but we will focus on some salient ones. Our objective in this lesson is to understand different design trade-offs while meeting the needs we stated earlier.

Now, let’s explore the key design features of DynamoDB in detail.

No fixed schema

We aim to provide a service that caters to all use cases with easy horizontal scaling. We will allow our database to function without a set schema. This gives users easy access to data, and they do not need to declare a schema before using the database. It also keeps our design simple. We’ll be using a NoSQL-based database system.

We have chosen a NoSQL database because of its flexibility with highly functional APIs, easy scalability, performance at scale, and high availability.

NoSQL instead of RDBMS

In an RDBMS, data is stored in tables related to one another. NoSQL (not only SQL) ...