… a bit like Michael Jackson’s “filler” song ;)
Well, just a ramble (what’s new?) about a few odd things I have been reading.
Amazon DynamoDB - How many requests per second? !!
In 2021, there was a 66-hour Amazon Prime Day shopping event.
The event generated some staggering stats:
○ Trillions of API calls were made to the database by Amazon applications.
○ The peak load to the database reached 89 million requests per second.
○ The database provided single-digit millisecond performance while maintaining high availability.
All of this was made possible by DynamoDB.
Amazon’s DynamoDB is a NoSQL cloud database service that promises consistent performance at any scale.
History of DynamoDB
In the early years, Amazon realized that letting applications access traditional enterprise databases was an invitation to multiple scalability challenges such as managing connections, dealing with concurrent workloads, and handling schema updates.
Also, high availability was a critical property for always-online systems. Any downtime negatively impacted the company’s revenue.
There was a pressing need for a highly scalable, available, and durable key-value database for fast-changing data such as a shopping cart.
Dynamo was a response to this need.
However, there was one drawback of Dynamo. It was a single-tenant system and teams were responsible for managing their own Dynamo installations. In other words, every team that used Dynamo had to become experts on various parts of the database service, creating a barrier to adoption.
At about the same time, Amazon launched SimpleDB which reduced operational burden for the teams by providing a managed and elastic experience. The engineers within Amazon’s development team preferred using SimpleDB even though Dynamo might be more suitable for their use case.
But SimpleDB also had some limitations such as:
The tables had a small storage capacity of 10 GB.
Request throughput was low.
Unpredictable read and write latencies because all table attributes were indexed.
Also, the operational burden wasn’t eliminated. Developers still had to take care of dividing data between multiple tables to meet their application’s storage and throughput requirements.
Therefore, the engineers concluded that a better solution would be to combine the best parts of Dynamo (scalability and predictable high performance) with the best parts of SimpleDB (ease of administration, consistency, and a table-based data model).
This led to the launch of DynamoDB as a public AWS service in 2012. It was a culmination of everything they had learned from building large-scale, non-relational databases for Amazon.
Over the years, DynamoDB has added several features based on customer demand.
The below timeline illustrates this constant progress.
Operational Requirements of DynamoDB
DynamoDB has evolved over the years, much of it in response to Amazon’s experiences building highly scalable and reliable cloud computing services. A key challenge has been adding features without impacting the key operational requirements.
The below diagram shows the six fundamental operational requirements fulfilled by DynamoDB.
Let’s look at each of them in a little more detail.
Fully Managed Cloud Service
A fundamental goal of DynamoDB is to free developers from the burden of running their database system. This includes things like patching software, configuring a distributed database cluster, and taking care of hardware needs.
The applications can just talk to the DynamoDB API for creating tables. They can read and write data without worrying about where those tables are physically stored or how they’re being managed.
DynamoDB handles everything for the developer right from resource provisioning to software upgrades, data encryption, taking backups, and even failure recovery.
Multi-Tenant Architecture
DynamoDB also aims to create cost savings for the customers.
One way to achieve this is using a multi-tenant architecture where data from different customers is stored on the same physical machines. This ensures better resource utilization and lets Amazon pass on the savings to the customers.
However, you still need to provide workload isolation in a multi-tenant system.
DynamoDB takes care of it via resource reservations, tight provisioning, and monitoring usage for every customer.
Boundless Scale for Tables
Unlike SimpleDB, there are no predefined limits for how much data can be stored in a DynamoDB table.
DynamoDB is designed to scale the resources dedicated to a table from several servers to many thousands as needed. A table can grow elastically to meet the demands of the customer without any manual intervention.
Predictable Performance
DynamoDB guarantees consistent performance even when the tables grow from a few megabytes to hundreds of terabytes.
For example, if your application is running in the same AWS region as its data, you can expect to see average latency in the low single-digit millisecond range.
DynamoDB handles any level of demand through horizontal scaling by automatically partitioning and repartitioning data as and when needed.
Highly Available
DynamoDB supports high availability by replicating data across multiple data centers or availability zones.
Customers can also create global tables that are geo-replicated across selected regions and provide low latency all across the globe. DynamoDB offers an availability SLA of 99.99% for regular tables and 99.999% for global tables.
Flexible Use Cases
Lastly, DynamoDB has a strong focus on flexibility and doesn’t force developers to follow a particular data model.
There’s no fixed schema and each data item can contain any number of attributes. Tables use a key-value or document data model where developers can opt for strong or eventual consistency while reading items from the table.
Prompt Engineering is already dead?
Well, who knows! but if you are brave enough to try, Google Collab (to allow you to run heavier workloads in the cloud instead of your own laptop/PC) has a process by Anthropic:
Anthropic is the company behind Claude AI too!
Okay, until next time! As promised, I have an overview of Obsidian Note Taking App coming up soon!
Episode 72 - Flotsam and Jetsam