Redundancy for AWS Database Services – Part 2: A look at No-SQL DBaaS

SQL database became the de-facto standard for databases already decades ago. Then, data warehouses gained popularity – and now, for some years already, NoSQL databases have been transitioning from niche to mainstream solutions. While my first post on redundancy for AWS databases looked at relational SQL databases, this post focuses on No-SQL databases. In particular, I discuss redundancy for the AWS Dynamo DBaaS service (key-value and documents database) and the AWS Neptune DB service.

AWS Neptune

Graph databases, a particular type of NoSQL database, put relationships between objects in focus, which can be more efficient than SQL databases, depending on the exact use case. AWS provides such a database service. Its name: AWS Neptune. When engineers create an AWS Neptune instance, they have to choose whether to specify the VM sizing at launch or define a capacity the service should have and let AWS handle the sizing. Customers must choose a Neptune engine version and handle upgrades to a newer engine version. So, from a maintenance perspective, customers have to handle quite some tasks themselves.

AWS Neptune has two deployment models. The first is a single instance: no redundancy or failover in case of a crash or data center failure (Figure 1, left). The second deployment option is a Multi-AZ deployment (Figure 1, right). There is one primary DB instance and up to 15 read-only replicas. All writes go to the primary instance, whereas the other replicas can handle read-only traffic. The data replication is nearly real-time but not guaranteed to be real-time. Amazon states that the replication should usually take considerably less than 100 milliseconds, but it might be even higher in case of a high write volume. In short: they try to be real-time, but if this is a requirement for your use case, you cannot rely on the service. Neptune DB has no out-of-the-box geo-redundancy option, though companies can implement it with AWS services.

AWS Dynamo

DynamoDB is a truly NoSQL database-as-a-service storing and managing key-value pairs and documents. Customers do neither have to care about storage or compute capacity, nor do they have to engage in patching or update activities.

When customers create a table with documents or key-value pairs (Figure 2, left), DynamoDB ensures the replication of the data and service redundancy within a region. Customers do not have to handle outages of availability zones. However, the unavailability of an AWS region makes the service and all tables stored in this region unavailable.

Dynamo DB allows promoting a table to a global table. Then, ?a table is not only available in one region, but AWS replicates the table in one or more other regions (Figure 2, right). Applications can read and write from the nearest replica, thereby reducing latency. However, a global table does not mean Dynamo DB offers a geo-redundant service—a global table is more like having various database services in the region. Applications in the region write to their local database, plus all databases push their region-specific updates to the replicas around the globe.

This design has two implications. First, an application in the Milano region and one in the Auckland region can update the same table and data items concurrently. They would not notice this fact. One might set a data item value to 0, the other to 12. In such a case, AWS follows the “last writer wins” principle and accepts “lost updates.” Does this logic fit the application? That is up to the engineers to understand in advance—fun for everyone, who loves database transaction theory, but less fun for the rest.

Second, applications read from and write to a replica in a concrete region. If the region is down, applications must notice that and redirect their requests to another replica. So, the application has to handle regional Dynamo DB outages.

Dynamo DB and Neptune are both offering fantastic features for availability zone outages. They outclass what most companies know from the on-premise world. Geo-redundancy, however, requires engineers and architects to spend more than one extra thought.?