DynamoDB Flashcards
(2 cards)
What is DynamoDB?
DynamoDB is a no sql database which is fully managed. It’s highly available with replication across multiple AZ
It scales to massive workloads, millions of requests per second, trillions of rows, hundreds of TB of storage
Key Features:
• NoSQL Database: Supports key-value and document data models.
• Managed Service: No need to manage hardware, setup, or maintenance.
• High Performance: Offers single-digit millisecond latency at any scale.
• Scalable: Automatically scales throughput capacity and storage.
• Durable and Highly Available: Data is replicated across multiple Availability Zones (AZs).
• Serverless: No server provisioning required. Integrated with AWS Lambda for event-driven apps.
• Security: Fine-grained access control using IAM, encryption at rest, and in transit.
⸻
Core Components:
• Tables: Collection of items (similar to rows).
• Items: Individual records (can have different attributes).
• Attributes: Key-value pairs in each item.
• Primary Key: Uniquely identifies each item (can be just a partition key or partition + sort key).
• Indexes:
• Global Secondary Index (GSI): Query flexibility using alternate keys.
• Local Secondary Index (LSI): Same partition key, different sort key.
What are primary keys in DynamoDB and how to choose them ?
- DynamoDB is made of tables
- Each table has a primary key (must be decided at creation time)
- Each table has an infinite number of items (called rows)
- Each item has attributes (can be added over time, could be null)
- Maximum size of an item is 400 KB
- Data types supported are -
Scalar (String, Number, Binary, Boolean, Null)
Document Type (List, Map)
Set Types (String Set, Binary Set, Number Set)
Types of Primary Keys in DynamoDB
1. Simple Primary Key (Partition Key only)
• Format: { partition_key }
• All items must have a unique partition key.
• Good for lookups where each key maps to one item.
2. Composite Primary Key (Partition Key + Sort Key)
• Format: { partition_key, sort_key }
• Partition key groups items; sort key allows range queries within the group.
• Enables storing multiple related items under the same partition key.
⸻
How to Choose a Good Partition Key
1. Uniform Distribution
• Choose a partition key that spreads data evenly across partitions.
• Avoid hot partitions (where one key gets most of the traffic).
2. Access Pattern Awareness
• Design keys based on how your app reads/writes data.
• Ask: “What are the most common queries?” and build keys to support them efficiently.
3. High Cardinality
• Pick a key with many unique values to ensure even distribution.
• E.g., user_id, order_id, device_id are usually good choices.
⸻
When to Use Sort Key
• You need range queries (e.g., fetch orders by date for a customer).
• You want to group related items under a single partition key.
• Example: partition_key = user_id, sort_key = timestamp
⸻
Design Tips
• Avoid hot keys: If one key (e.g., “India”) is accessed too frequently, performance will suffer.
• Consider synthetic keys: If natural keys don’t scale well, concatenate values like user_id#date to ensure uniqueness and distribution.
• Model for read patterns: Think in terms of what exact queries your application needs to run.