NoSQL vs SQL
NoSQL (short for “not only SQL”) refers to non-relational databases that support flexible schemas and a variety of data models. SQL databases (relational) work best with well-defined schemas and normalized relations. NoSQL systems excel when you need horizontal scalability, low-latency reads/writes, and to store semi-structured or unstructured data at large scale.
NoSQL types
NoSQL databases come in multiple types, each optimized for particular access patterns and workloads:
DynamoDB overview
Amazon DynamoDB is a fully managed NoSQL database service on AWS. It is primarily a key-value store with first-class support for document-like, nested attributes. Key capabilities include:- Fully managed, serverless operation with seamless autoscaling.
- Multi-AZ replication for durability and high availability.
- Low-latency single-digit millisecond and sub-millisecond read performance.
- Integration with DynamoDB Streams for item-level change events.
- Optional DynamoDB Accelerator (DAX) for an in-memory read cache to support ultra-low-latency read-heavy workloads.
DAX improves read latency but does not support DynamoDB transactional APIs (TransactWriteItems / TransactGetItems) and does not provide strongly consistent reads. Use DAX only for eventual-consistency read caching scenarios.
Transactions and ACID
Although DynamoDB is a NoSQL store, it provides transactional APIs (TransactWriteItems and TransactGetItems) that give ACID semantics within a single AWS Region. Transactions ensure:- Atomicity — Either all operations in the transaction succeed or none do.
- Consistency — Conditional checks and constraints are enforced; invalid operations cause transaction failure.
- Isolation — Partial changes are not visible before transaction commit.
- Durability — Committed changes persist and survive failures due to multi-AZ replication.
Basic DynamoDB elements
Understand these core concepts before modeling your data:
Example item (employees table):
Composite keys
Composite primary keys (partition key + sort key) let you model one-to-many relationships and time-ordered data. Use the partition key for distribution and the sort key for range queries, sorting, and efficient retrieval of related items.Global tables and multi-region replication
DynamoDB global tables enable multi-region replication, allowing you to deploy table replicas in multiple AWS Regions for lower-latency reads and multi-region resilience. Global tables replicate writes asynchronously between regions—replication is typically fast (often within seconds), but it is eventually consistent.Global tables are multi-region and replicate asynchronously. Do not assume immediate, cross-region strong consistency—design your application to tolerate brief replication lag or consider conflict resolution strategies for concurrent regional writes.
Backups and point-in-time recovery (PITR)
DynamoDB supports on-demand backups and point-in-time recovery (PITR) for continuous protection within a region. For disaster recovery (DR) and long-term retention, use AWS Backup to create cross-region and cross-account backups.
Single-region architecture (limitations)
A common simple architecture uses API Gateway -> Lambda -> DynamoDB in a single region. While cost-effective and straightforward, this pattern creates a single-region point of failure: if the region becomes unavailable, the entire application can be unavailable.
Multi-region and active-active architectures
To improve availability, reduce latency for global users, and avoid regional single points of failure, replicate data across multiple regions. Common approaches:- Global tables: automatic cross-region replication (eventual consistency).
- Active-active: run full application stacks in multiple regions and route traffic (Route 53, geolocation-based routing, or latency-based routing). Use global tables or other replication mechanisms for the data tier.
- Active-passive failover: a primary region accepts writes while secondary read-only regions remain on standby for failover.
Design recommendations for HA and global scale
- Choose your primary access pattern first; model DynamoDB keys (partition + sort keys) to satisfy that pattern.
- Prefer single-table designs for many access patterns to reduce cross-partition queries, but balance complexity and maintainability.
- Use transactions for strong ACID requirements within a region; avoid relying on cross-region transactional guarantees.
- When using global tables, design for eventual consistency and conflict resolution for concurrent writes from multiple regions.
- Complement global tables with cross-region backups (AWS Backup) and automated failover plans for robust DR.
Key takeaways
- DynamoDB is a highly scalable, fully managed NoSQL database ideal for key-value and document patterns.
- Use transactional APIs when you need ACID guarantees within a region; DynamoDB’s durability benefits from multi-AZ replication.
- Global tables provide automatic cross-region replication for low-latency local reads but are eventually consistent—plan for replication lag.
- Combine global tables, cross-region backups, and multi-region deployment patterns (active-active or active-passive) to meet availability and resilience requirements.
Links and references
- Amazon DynamoDB documentation: https://docs.aws.amazon.com/dynamodb/
- DynamoDB transactions: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html
- Global tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.html
- DynamoDB Accelerator (DAX): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html
- AWS Backup: https://docs.aws.amazon.com/backup/