What Is DynamoDB?

In recent years, however, a need has emerged for databases with extremely high performance and without the strict schema enforced by relational databases. The solution became what is called NoSQL databases optimized for performance and without a need for a defined schema.

In this article, we’ll deep dive into one of the most common NoSQL databases: Amazon DynamoDB. More specifically, we’ll discuss:

What is DynamoDB?

DynamoDB is a highly performant NoSQL database technology developed by Amazon. A NoSQL database is a type of database that isn’t defined through tables and relations as a relational database. Instead, data is stored behind a unique key and doesn’t necessarily need to adhere to a specific schema. For example, if you want to store user data in your application, you could store each user with their ID as the key and all user data as a JSON document. The data can then be retrieved with low latency by a simple lookup of the user’s ID.

Using Amazon DynamoDB, you can store data for mobile apps, gaming, ad technology, and other types of applications that require a highly performant data layer.

8 Benefits of DynamoDB

There are numerous benefits to using DynamoDB as your application’s data storage. While many benefits are centered around performance, DynamoDB also has useful features such as fine-grained access control, DynamoDB streams, and a schemaless design.

1. Scalability

Scaling databases is typically hard work for infrastructure engineers, who have to manage many different instances and make sure they’re in sync with each other. With Amazon DynamoDB, though, you get on-demand auto-scaling out of the box.

This enables your system to scale from a few to millions of users without any human intervention or operational headaches. From a business perspective, this could mean you don’t have to have dedicated infrastructure engineers who monitor and scale your infrastructure manually. If you need to control the capacity for your table beforehand, it’s also possible to configure a provisioned throughput. Using provisioned throughput means you can control the exact number of reading or write capacity units available for the table to use at a given point in time.

2. No servers to manage

Running a traditional relational data store typically means managing servers – taking backups, scaling up, scaling down, making sure they do not run out of disk space, etc. With DynamoDB, AWS takes care of all this for you. The only thing you need to worry about is reading and writing data to your DynamoDB table. As a business, this means developers can focus on what matters to your customers instead of spending time with these repetitive tasks.

3. Good for enterprise requests

The performance and scaling capacity of DynamoDB makes it a good choice for businesses with a large amount of data being requested at a high rate. This—in combination with advanced features, such as granular access control, event streams, serverless design, and durability—makes it a good choice for enterprise businesses.

4. Performance

Amazon DynamoDB is built for providing single-digit millisecond performance at virtually any scale. It’s also possible to enable data replication across different geographic regions to ensure the high availability of your application. To further improve response times, you can enable a caching layer called DynamoDB Accelerator. High performance means a better experience for end-users and faster data processing.

5. Access control

Using the built-in policy system AWS IAM, you can enable fine-grained access control to the data inside Amazon DynamoDB as well as the infrastructure itself. You can also set up CloudWatch monitoring that helps detect security breaches and track metrics. This feature is crucial for protecting and securing your data.

6. Event streams

To listen to updates to a DynamoDB table, simply enable event streams on your table. This enables your application to index data in a search index, create backups, send an email when a new row is created, ingest your data into a data warehouse, such as AWS Redshift, and much more.

7. Time-to-live (TTL)

If you don’t want to store your data permanently, you can set a time-to-live for each item in your DynamoDB database. Since one of the cost factors for DynamoDB is the total size of your stored data, this feature can help you save money.

8. Schemaless storage

As mentioned, DynamoDB is a document database that doesn’t enforce a schema. This enables you to store data with different schemas inside the same table. The schemaless design enables rapid and simplified application development.

Common use cases for DynamoDB

There are many different use cases for Amazon DynamoDB, including:

Serverless web apps

As mentioned, using Amazon DynamoDB means you don’t have to manage servers to host your database. This is a perfect fit with the serverless paradigm, where you want to scale your infrastructure automatically and keep costs at a minimum. A typical example of using DynamoDB as part of a serverless web app is for startups that want to keep costs down initially and build for future scalability.

Mobile back ends

Mobile backends typically require flexible scaling, as the number of concurrent users varies over time. This means your data layer also needs to be able to handle many concurrent transactions and reads. The performance and scalability of Amazon DynamoDB can help a mobile app handle these spikes without issues. For a business, this means you don’t have to worry about your applications going down even with increased usage.

Microservices

When you split your applications up into different small services, Amazon DynamoDB can be a good choice. Smaller services mean simpler data models that can be easily stored in DynamoDB.

Another benefit for microservices is the fact that a small service might not need an expensive and advanced relational database. Instead, a more inexpensive and simple DynamoDB table can be used.

Building your application with a microservice architecture means you can keep components simple for your engineers to grasp, and it also enables you to reuse the microservices across different applications.

4 industry use cases for DynamoDB

The benefits of Amazon DynamoDB can be suitable in a range of different industries. Here are four industries where DynamoDB can be used to deliver business value.

Ad tech

Ad technology is all about collecting user data to serve the best ads to different users. User data is usually generated at a high frequency in the form of clicks, interactions, and visited links. Storing this data requires a highly performant data layer, which DynamoDB can provide.

Gaming

Gaming has some of the most challenging requirements for real-time data processing. Imagine storing the leaderboard and player data for a game with thousands of concurrent users. This can be achieved with the single millisecond latency of DynamoDB.

Retail

Online stores can vary massively in usage during events like Black Friday. To store data like shopping carts, inventory tracking, fulfillment, and even product metadata, there’s a need for a scalable data layer. With the automatic scaling that DynamoDB provides, an online store of any size can benefit from using it.

Banking and finance

In banking and finance, transactions must be carried out consistently. To support this, DynamoDB offers a transaction feature to make sure that if anything goes wrong, the transaction can be rolled back safely.

Furthermore, event streams can be used to stream transactional data into external systems that can analyze the data and detect potentially fraudulent transactions.

DynamoDB data types

The properties of an object in Amazon DynamoDB are stored as different data types. Different data types help when performing queries for a value greater than a specific number or a value that starts with a specific string. The data types are:

• String: A string value, e.g., “hello”
• Boolean: A value true or false
• Byte: Binary data
• Date: A date in the ISO-8601 format that can be used for time comparisons
• Calendar: A date in the ISO-8601 format, such as 2021-W38
• Long: A 32-bit number ranging from -2,147,483,648 to 2,147,483,647
• Integer: An integer value, e.g., 48
• Double: A 64-bit decimal value
• Float: A 32-bit decimal value
• BigDecimal: A decimal value exceeding the limit for a primitive float or double value
• BigInteger: An integer value exceeding the limit for a primitive integer value

DynamoDB tables

The entity that holds your data inside DynamoDB is a table. This is similar to a table in a relational database, with the difference being there are no defined columns.

Instead, you can define keys in the form of a hash key (also known as a partition key) and a range key. The hash key is a uniquely identifiable property in your data that you can use to query your table. In a relational database, you’d probably use the hash key as a primary key. For example, if you have a table containing user data, such as the one below, you could use the userId column as the key.

If you want to do more advanced querying, such as looking for strings that start with a specific substring, you can use a range key: the range key and the hash key combined need to be unique. In a user table, you could specify the email address to be a range key. Then, you can query for users whose emails start with “jane@,” for example.

DynamoDB schema

As mentioned, DynamoDB is essentially schemaless. Instead, you use the hash and range keys to enforce the shape of your data to make it queryable. The data type of your keys needs to be defined beforehand using the data types listed in the DynamoDB data types section.

If we use the user table again as an example, the userId would be defined as a hash key with the string data type. If we also want to query for the email, we would define the email as a string data type but as a range key.

How much does DynamoDB cost?

DynamoDB pricing is based on usage, which helps it to stay cost-effective. Some high-level cost factors include:

• Read and write requests: There’s a cost tied to each reading and writing that you perform on your DynamoDB table.
• Data storage: Cost is calculated by the total size of the data stored in your table.
• Backup size: If you activate backups for your table, there’s a cost for the total size of your backed-up data.
• Global tables: If you enable global tables, so your data is replicated across multiple regions to ensure high availability, there’s a cost for each write request to your replica tables.
• Exports to other Amazon services: DynamoDB is integrated with many services, and each time data is moved between them is tied to a cost.

You can get up-to-date cost information in the official documentation.

DynamoDB vs. MongoDB

MongoDB is another popular NoSQL database service. Here are some differences between DynamoDB and MongoDB.

• Fully managed: While MongoDB is an open-source database you can host anywhere, DynamoDB can only be used running on Amazon Web Services (AWS). This means you have access to all other AWS services offered in the platform in addition to DynamoDB. While hosting your servers can be a pain?, it also helps you not to become locked in with using AWS.
• Security: DynamoDB provides granular security out of the box. Meanwhile, you need to implement your security layer using MongoDB.
• Aggregation: While MongoDB has built-in functionality for performing aggregations and advanced queries, DynamoDB needs external services to achieve the same functionality.
• Scalability: MongoDB connections are established using a socket, while DynamoDB requests are made through an HTTP API. This can make MongoDB tricky to scale, while DynamoDB is highly scalable out of the box.

Cassandra vs. DynamoDB

Apache Cassandra is an open-source database developed by the Apache Foundation and provides many of the benefits seen with DynamoDB. However, there are some differences between the two technologies, including:

• Several tables: The maximum number of DynamoDB tables that can be created in an AWS region is 256. Cassandra doesn’t have a hard limit.
• Schema: DynamoDB doesn’t require a defined schema. Only the key attributes need to be defined before you can store your data. Cassandra requires a defined schema for your data.
• Item size limit: DynamoDB has a maximum item size limit of 400KB. On the other hand, Cassandra has a more generous limit of 2GB. The practical limit, however, is a few megabytes.
• Pricing: While DynamoDB is a fully managed solution that’s priced based on usage, Cassandra can be self-hosted, and the cost equals the cost of the infrastructure backing your Cassandra instance.

How to query DynamoDB

In this section, we’ll go through how to query DynamoDB. While a relational database typically uses a query language, such as SQL, DynamoDB uses a client library provided by AWS. These examples are written in JavaScript, but DynamoDB has support for many different programming languages.

In the example tutorial, we’ve created a table called “Users in the AWS Management Console” with a string hash key named “userId” that we will query. However, the code that we show you here can easily be modified to query tables with a different data structure.

Step 1: Create a DynamoDB client

To start querying DynamoDB, we need to create a DynamoDB client instance that we’ll later use to communicate with the database:

const dynamodb = new AWS.DynamoDB();

Step 2: Execute the query

Now, we’re ready to use the client to fetch a user with the id “2j6hx”:

const dynamodb = new AWS.DynamoDB();

const params = {
 Key: {
  "userId": {
    S: "2j6hx"
   }
 },
 TableName: "Users"
};

dynamodb.getItem(params, function(err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else     console.log(data);           // print the data
});

Example(s) of a DynamoDB query

There are many ways to query a DynamoDB table. In this section, we’ll go through five different queries. All queries need a DynamoDB client, as mentioned in the previous example.

Equals

The query for users whose email equals “jane@example.com”:

const params = {
   KeyConditionExpression: "#email = :email",
   ExpressionAttributeNames:{
     "#email": "email"
   },
   ExpressionAttributeValues: {
     ":email": "jane@example.com"
   }
  TableName: "Users"
 };

 dynamodb.query(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // print the data
 });

Begins with

The query for users whose email begins with “jane@”:

const params = {
   KeyConditionExpression: "#email begins_with :email",
   ExpressionAttributeNames:{
     "#email": "email"
   },
   ExpressionAttributeValues: {
     ":email": "jane@"
   }
  TableName: "Users"
 };

 dynamodb.query(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // print the data
 });

Greater than

The query for users whose login count is greater than 5:

const params = {
   KeyConditionExpression: "#loginCount > :loginCount",
   ExpressionAttributeNames:{
     "#loginCount": "loginCount"
   },
   ExpressionAttributeValues: {
     ":loginCount": 5
   }
  TableName: "Users"
 };

 dynamodb.query(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // print the data
 });

Less than

The query for users whose login count is less than 5:

const params = {
   KeyConditionExpression: "#loginCount < :loginCount",
   ExpressionAttributeNames:{
     "#loginCount": "loginCount"
   },
   ExpressionAttributeValues: {
     ":loginCount": 5
   }
  TableName: "Users"
 };

dynamodb.query(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // print the data
 });

Not equal

The query for users whose login count is not equal to 0:

const params = {
   KeyConditionExpression: "#loginCount <> :loginCount",
   ExpressionAttributeNames:{
     "#loginCount": "loginCount"
   },
   ExpressionAttributeValues: {
     ":loginCount": 0
   }
  TableName: "Users"
 };

 dynamodb.query(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // print the data
 });

DynamoDB FAQs

Here are answers to a few of the most common questions about DynamoDB.

Is DynamoDB serverless?

Yes, DynamoDB is considered a serverless database since you don’t have to manage the underlying infrastructure backing the database.

Is DynamoDB NoSQL?

Yes, DynamoDB is a NoSQL database. Meaning the data isn’t modeled relationally with a predefined schema. Instead, each item in DynamoDB can potentially have a unique schema. Data in DynamoDB is queried using user-defined keys instead of SQL as in a typical relational database.

How is data stored in Amazon DynamoDB?

Data in DynamoDB is stored as documents in a key-value manner. Data can be queried using user-defined keys.

Ready to use DynamoDB?

DynamoDB is a very powerful data layer that can be used in various industries and for a range of different use cases. It offers a scalable, performant, and secure database with a flexible cost model.