Learn the fundamentals of DynamoDB, including database concepts, partition and sort keys, and data types.
A database is an organized collection of data, stored and accessed electronically from a computer system. Databases are essential for storing and retrieving data reliably and efficiently. They serve critical roles in applications by:
In DynamoDB, data is organized into tables, items (similar to rows in relational databases), and attributes (similar to columns). Each item in a DynamoDB table can be uniquely identified by its primary key.
Consider a practical example: if you organized 30 pairs of shoes in your closet, you would create a system where each shoe has attributes like color, style, and occasion. Similarly, databases organize data with attributes that allow for easy retrieval based on specific criteria.
// Example of data representation in a DynamoDB table
Table: ShoeOrganizer
{
"shoe_id": "SN01", // Partition key
"cubby_location": 1,
"color": "grey",
"style": "sneaker",
"occasion": "athletic"
}
Distributed database systems like DynamoDB offer additional benefits:
Primary keys in DynamoDB uniquely identify each item in a table. DynamoDB supports two types of primary keys:
The partition key determines the partition where your data is stored. It's used by DynamoDB's internal hash function to distribute data across partitions for scalability. For example, in a shoe table, "shoe_id" might be a good partition key.
The sort key allows you to organize items with the same partition key. This is especially useful for related items that need to be retrieved together.
// Example of a table with composite primary key
Table: MusicLibrary
{
"artist": "Black Eyed Peas", // Partition key
"song_title": "I Gotta Feeling", // Sort key
"genre": "pop",
"year": 2009
}
{
"artist": "Black Eyed Peas", // Same partition key
"song_title": "Pump It", // Different sort key
"genre": "pop",
"year": 2005
}
With a composite key, multiple items can share the same partition key (artist), but each must have a unique sort key (song_title) within that partition. This design is ideal when:
DynamoDB supports several data types for attributes, broadly categorized as scalar types and sets:
String
type.Integer
, Long
, Double
, etc.boolean
or Boolean
types.Set<String>
.Set<Number>
types.
// Example of different DynamoDB data types
{
"MemberId": "M123", // String type (S)
"Active": true, // Boolean type (BOOL)
"Age": 28, // Number type (N)
"LastName": "Smith", // String type (S)
"Committees": ["Finance", "Marketing"], // String Set type (SS)
"YearsActive": [2018, 2019, 2020] // Number Set type (NS)
}
When working with Java applications and DynamoDB:
String
should be stored as DynamoDB String (S)int
, Integer
, long
, double
, etc.) should be stored as DynamoDB Number (N)boolean
/Boolean
should be stored as DynamoDB Boolean (BOOL)Set<String>
should be stored as DynamoDB String Set (SS)Set<Integer>
, Set<Double>
, etc. should be stored as DynamoDB Number Set (NS)Understanding these mappings is crucial when designing your data model and implementing Java classes that interact with DynamoDB.
DynamoDB supports the standard database CRUD operations (Create, Read, Update, Delete):
When designing DynamoDB tables, consider these best practices:
Remember that DynamoDB is a NoSQL database designed for high-scale, performance-intensive applications. Its design principles differ from traditional relational databases like MySQL or PostgreSQL.