DynamoDB Flashcards
Describe DynamoDB
- Managed, multi-AZ NoSQL data store with Cross-Region Replication option.
- Defaults to eventual consistency reads but can request strongly consistent read via SDK parameter.
- Priced on throughput, rather than compute.
- Provision read and write capacity in anticipation of need.
- Autoscale capacity adjusts per configured min/max levels.
- On-Demand Capacity for flexible capacity at a small premium cost.
- Archieve ACID compliance with DynamoDB Transactions.
Relational vs NoSQL
Relational: Structured Data needed.
NoSQL: Manages Name-Value pairs, non-structured data
What are the structural objects in a NoSQL database?
Name: Identifier of the Name-Value pair.
Value: Content of the Name-Value pair.
Attribute: Another name for the Name-Value pair.
Item: Whole collection of Name and Values.
Table: Many item records come together to form a table.
Primary Key: An Attribute in an item that is unique and identifies the record.
Hash Attribute/Internal Hash: Maps a data value of arbitrary size to fixed size. Is used to decide which partition or underlying physical storage to store this value. Can also be called a Hash Attribute.
Composite Primary Key: An alternate identification method for Items/Records where a Partition Key and Sort Key are used.
Partition Key: A Primary Key that can have occurrences of the same Partition Key as long as the Sort Key is different. The same hashes are done to the partition key, but the records are stored in the sort order of the sort key. Useful if you want to pullback a subset of data on some Sort Key.
Sort Key: Identifies a sort order and helps in improving performance through indexing and subsetting of data.
Name the two types of indexes
Global Secondary Index: Partition key and a sort key can be different from those on the table.
Local Secondary Index: Same partition key as the table, but different sort key.
When would you use a Global Secondary Index
When you want a fast query of attributes outside the primary key without having to do a table scan (read everything sequentially).
“I’d like to query Sales Orders by Customer number rather than Sales Order Number.”
When would you use a Local Secondary Index
When you already know the partition key and want to quickly query on the other attribute.
“I have the Sales Order Number, but I’d like to retrieve only those records with a certain Material Number.”
Design Best Practices
- Partition Keys are the same, but Sort Key Values are all different (Sort Key Name is the same).
- Leverage Sparse Indexes - Indexes can exists only for certain attributes that don’t always exist in every record (smaller, more efficient indexes).
- Can use a Global Secondary Index to create table replicas. You just have to use the same Partition Key and Sort Key. You can differentiate performance by table, or you can use the GSI as a read replica. Replica is Eventually Consistent
If you need to access just a few attributes the fastest way possible, consider:
Projecting just those few attributes in a global secondary index. The Cost is minimal, and the benefit is that it has the lowest possible latency access for non-key items.
If you need to frequently access some non-key attributes, consider:
Projecting those attributes in a global secondary index. The Cost is moderate, but it aims to offset the costs of table scans, and the benefit is that it has the lowest possible latency access for non-key items.
If you need to frequently access most non-key attributes, consider:
Projecting those attributes or even the entire table in a global secondary index. The Cost is up to double of the original latency, but it provides the benefit of Maximum flexibility.
If you need to rarely query but write or update frequently, consider:
Projecting keys only for the global secondary index. The Cost is minimal, and the benefit is that writes or updates are very fast for non-partition key items.
