Skip to main content

15 reasons to try AWS DynamoDB as your NoSQL database

AWS DynamoDB is a managed NoSQL document database service. It's a proprietary NoSQL database created by AWS. Amazon uses it on its eCommerce website. Hence its performance and scalability are proven.

I have used it in a high volume data project which needs more than 7000 writes per second and generates around 50 GBs of data daily. Though it's an effort to design applications it scales really well.

In this article, you will see a few good reasons for you to evaluate AWS DynamoDB when you are planning to use MongoDB, Cassandra, or others alike.

1. AWS DynamoDB is a managed service

To keep the database running is not a small job. If the size of data is in terabytes and growing, you need a team of infrastructure engineers to carry out the following tasks:

  1. Architecture & design for a multi-region, multi-partition, and redundant high-performance database.
  2. 24 X 7 monitoring of database nodes' health.
  3. Database engine upgrade.
  4. OS upgrade.
  5. Regular disk and memory space planning, monitoring, and implementation.
  6. Computational power planning, monitoring, and implementation.
  7. Security audit & trail.
  8. On occasion Database node maintenance and replacement.

If we are using MongoDB or Cassandra and wanted to run the database with Terabytes of data we have to make sure all the above-mentioned tasks are overlooked by an Infrastructure team.

Though AWS DynamoDB keeps you free from all the above tasks as it is a managed service. You just create tables and start pouring in data.

It helps in reducing database infrastructure management costs to near zero. It is one of its biggest selling points of it.

2. Even Petabytes of data are fine

AWS DynamoDB doesn't have any limit on the size of tables, hence even Petabytes of data are handled at the same performance. All the data is kept on Solid State Drive servers.

3. Easy read and write throughput management

AWS DynamoDB is a true cloud database. It provides the following options to manage read and write throughout elasticity:

  1. Auto Scale - With the Auto Scale feature you have the ability to define the increase and decrease read and write capacity of a table, when a certain percentage or number of throughput capacity is reached, AWS automatically increases or decreases the number of partitions required to handle the new throughput. It helps in reducing the cost by keeping the number of partitions optimal as per demand.
  2. Use the cron job to trigger the change in reading and write throughput for the table using AWS CLI commands in the script.
  3. Manually change throughput from the management console.

Change in the table throughput results in the creation or deletion of partitions. AWS makes sure all these happen without any downtime.

4. Automatic data and traffic management

DynamoDB automatically manages the replication and partition of the table based on the data size. It continuously monitors the table data size and spread tables on a sufficient number of servers that are replicated to multiple availability zones in a region, when required. All these without any downtime and our knowledge.

5. On-demand backup & recovery for the table

DynamoDB will never lose your data because it replicates it in multiple zones of the system which are fault tolerant.

Keeping the backup of the table periodically can save our face when application corrupt data. In some corporate, there is a compliance need for the same. It provides a simple admin console and API based backup and recovery mechanism. Backup and recovery are very fast and complete in seconds despite the size of the table.

6. Point in time recovery

DynamoDB provides the point in time recovery features to go back at any time in the last 5 weeks (35 days) of time for a table. It is over and more to back up & recover features.

7. Multi-region global tables

AWS DynamoDB does automatic syncing of data between multiple regions for global tables. You just need to specify in which regions want it to be available. Without global tables, you were doing it on your own by executing code and copying data in multiple zones.

It is really helpful if the application needs multi-region replication for performance reasons.

8. Inbuilt in-memory caching service DAX (DynamoDB Accelerator)

Caching improves the performance dramatically and cuts the load on the database engine for reading queries.

DynamoDB Accelerator (DAX) is an optional caching layer that you set up with a few clicks. DAX is a specially built cache layer to work with DynamoDB. You can use it against ElasticCache or self-hosted Redis because of its performance along with DynamoDB.

DynamoDB typically returns the read queries under 100 milliseconds, with DAX further improved, and queries return under 10 milliseconds.

9. Encryption at rest

DynamoDB request response is HTTP based, just like many other NoSQL databases. Encryption at rest is a feature provided to enable an extra layer of security for data to avoid unauthorized access to storage. Sometimes it is required by compliance. It uses 256-bit AES encryption and encrypts table level data as well as indexes. It works seamlessly with AWS key management service for the encryption key.

10. Document and key-value item storage

DynamoDB can store JSON documents or key-value items in the table.

11. Schema-less

Like other NoSQL document databases, DynamoDB is schema-less. The key attribute is only one mandatory attribute in the item.

12. Eventual and Immediate consistency

You can create the table in two consistency modes in DynamoDB.

Eventual consistency - The cheaper option, with the query may or may not make the latest item available.

Immediate consistency - If your application wants immediate consistency with query results should always give the latest items.

13. Time to live items

This is one of the powerful features of DynamoDB which enables many use cases not possible without writing custom application code. You can get your items deleted after a certain amount of time automatically by a sweeper.

14. Streams

DynamoDB streams are another powerful feature that enables the execution of the AWS Lambda function when an item is created, updated, or deleted. Streams are similar to AWS Kinesis streams and you can use them for many use cases. For E.g. create your own data pipeline for creating aggregated records like average, sum, etc. Or sending the email when a new user record is inserted.

15. Local DynamoDB setup

For ease of development and integration test, you can use DynamoDB local distribution. It is a Java application and it can with Java Runtime Environment installed in the environment.

One last thing which I have not highlighted but is important. Being a part of AWS cloud offering, It can easily integrate with AWS Athena for big data computation needs. However, you can always integrate it with Apache Spark or other Big data computation engines.

I will suggest you try DynamoDB as your NoSQL need, let's see if it fits your need. They provide a generous free tier to start with.

References

  1. Official AWS documentation for developers

Comments

Popular posts from this blog

Working with request header in Jersey (JAX-RS) guide

In the  previous post , we talked about, how to get parameters and their values from the request query string. In this guide learn how to get request header values in Jersey (JAX-RS) based application. We had tested or used the following tools and technologies in this project: Jersey (v 2.21) Gradle Build System (v 2.9) Spring Boot (v 1.3) Java (v 1.8) Eclipse IDE This is a part of  Jersey (JAX-RS) Restful Web Services Development Guides series. Please read Jersey + Spring Boot getting started guide . Gradle Build File We are using Gradle for our build and dependency management (Using Maven rather than Gradle is a very trivial task). File: build.gradle buildscript { ext { springBootVersion = '1.3.0.RELEASE' } repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") } } apply plugin: 'java' apply plugin: 'eclipse' a

Ajax Cross Domain Resource Access Using jQuery

Some time back in our project we faced a problem while making an Ajax call using jQuery. Chrome Browser console had given some weird error message like below when we try to access one of our web pages: When we try to access the same web page in the Firefox browser, it doesn't give any error in the console but some parsing error occurred. In our case, we were accessing XML as an Ajax request resource. I was curious to check if the non-XML cross-domain resource was successfully loading or not. But finally, I realized that it is not going through. jersey-spring-boot-quick-starter-guide In our Ajax call, requesting domain was not the same as the requested URL domain. $.ajax({ url: "https://10.11.2.171:81/xxxxxx/xxxxxxx.xml" , type : "get" , success: function (response) { alert( "Load was performed." ); }, error : function (xhr, status) {

FastAPI first shot

Setup on my Mac (Macbook Pro 15 inch Retina, Mid 2014) Prerequisite Python 3.6+ (I used 3.7.x. I recently reinstalled OS after cleaning up disk, where stock Python 2.7 was available. I installed Pyenv and then used it to install 3.7.x). I already had a git repo initialized at Github for this project. I checked that out. I use this approach to keep all the source code safe or at a specific place 😀. I set the Python version in .python-version file. I also initialize the virtual environment using pyenv in venv folder. I started the virtual environment. FastAPI specific dependencies setup Now I started with basic pip commands to install dependency for the project. I saved dependencies in requirements.txt  the file. Minimal viable code to spin an API Server FastAPI is as cool as NodeJS or Go Lang (?) to demonstrate the ability to spin an API endpoint up and running in no time. I had the same feeling for the Flask too, which was also super cool. app/main.py: from typing i