Intro
The goal of this article: shortcut-providing roadmap enabling you to understand DynamoDB faster
The business context behind DynamoDB
- 2004: The beginning of an internal dynamo project
- 2007: Publishing dynamo whitepaper
- 2012: Public launch of DynamoDB
"It all started in 2004 when Amazon was running Oracle's enterprise edition with clustering and replication. We had an advanced team of database administrators and access to top experts within Oracle. We were pushing the limits of what was a leading commercial database at the time and were unable to sustain the availability, scalability and performance needs that our growing Amazon business demanded."
"A deep dive on how we were using our existing databases revealed that they were frequently not used for their relational capabilities. About 70 percent of operations were of the key-value kind, where only a primary key was used and a single row would be returned. About 20 percent would return a set of rows, but still operate on only a single table."
"With these goals in mind, In January, 2012 we launched Amazon DynamoDB, our cloud-based NoSQL database service designed from the ground up to support extreme scale, with the security, availability, performance and manageability needed to run mission-critical workloads"
From a DynamoDB summary by Werner Vogels
Read more: DynamoDB 10 years later
Different paradigm of modelling data relationships
- Not about SQL vs noSQL - but how relationships are modeled in data
- Single table design: Shifting from modeling separate tables => modeling many access patterns to data in a single table
- Indexes used to enable more access paterns
Single table design explained by Alex DeBrie
Single table design explained by Forrest Brazeal
Deep dive on DynamoDB by Rick Houlihan
Assuming scale from the start of the project
- Opinionated - preventing from making bad scaling decisions at the beginning
- Pros: 1) Helps avoid long-term scaling problems 2) Great for serverless
- Cons: Less flexibility & harder for projects that are not going to scale
"DynamoDB's philosophy is that it won't let you write a bad query. And by 'bad query', that means a query that won't scale. Even if your data is less than 10 GB, you won't be able to do things like joins or aggregations with DynamoDB. This results in a rigid data model. On the plus side, you know exactly what you're getting with DynamoDB. Your performance won't degrade over time, even if your application scales to 1000x the original size."
From DynamoDB guide by Alex DeBrie
"The best serverless applications also tend towards using a low latency non-RDBMS data store. An example from AWS is DynamoDB. The reason being that the data solution was originally developed to maintain low latency at scale and these features make it an ideal fit with other characteristics of serverless solutions"