Modelowanie danych w DynamoDB

DynamoDB is a NoSQL database, meaning it doesn't use traditional tables, rows, and joins like SQL. Data modeling here is all about how you'll access your data, not just how you store it.

• Schema-less: No fixed schema, but structure is key for performance.
• Access Patterns First: Design your tables around the queries you'll make.
• Performance & Cost: Good modeling leads to fast queries and lower costs.

Every item in DynamoDB needs a Primary Key. This key uniquely identifies each item and determines how data is stored and retrieved. It can be:

• A Partition Key (also called a Hash Key).
• A composite Partition Key and Sort Key (also called a Range Key).

The Partition Key (PK) determines the physical partition (storage location) where your data resides.

• Uniqueness: If only a PK is used, it must be unique for every item.
• Distribution: A good PK distributes data evenly across partitions, preventing 'hot partitions' which can slow down performance.
• Direct Access: You can only query an item directly if you know its Partition Key.

When you use both a Partition Key and a Sort Key (SK), items with the same Partition Key are grouped together and sorted by the Sort Key.

• Unique Combination: The combination of PK and SK must be unique.
• Range Queries: Enables efficient range queries (e.g., get all orders from a specific date range for a user).
• Flexible Sorting: Allows different sorting within the same partition.

Unlike relational databases where you design tables and then figure out queries, with DynamoDB, you should list all your application's data access patterns first.

• Identify Queries: What data do you need? How will you retrieve it?
• Examples: "Get user profile by userId", "List all products by category", "Find all comments for a postId".

Your table design (PK, SK, indexes) should directly support these patterns.

A common and powerful DynamoDB pattern is Single-Table Design. This means storing multiple, different entity types (e.g., Users, Orders, Products) in a single table.

• Benefits: Reduces operational overhead, enables efficient "many-to-many" relationships, and can be more cost-effective.
• How: Uses generic attribute names like PK and SK, and prefixes (e.g., USER#<id>, ORDER#<id>) to distinguish entity types.

What if you need to query data using an attribute that isn't part of your primary key? That's where Global Secondary Indexes (GSIs) come in.

• New Keys: A GSI has its own Partition Key and optional Sort Key, which can be any attributes from the base table.
• Independent: It's a completely separate table that DynamoDB maintains, allowing different access patterns.
• Eventually Consistent: GSIs are eventually consistent, meaning changes might take a short time to propagate.

Local Secondary Indexes (LSIs) allow you to query data with a different sort key within the same partition key as your base table.

• Same PK, Different SK: LSIs share the same Partition Key as the base table but have a different Sort Key.
• Strongly Consistent: Unlike GSIs, LSIs support strongly consistent reads.
• Limited: Must be defined at table creation and you can have up to 5 per table.

Let's model a simple scenario: users and their posts. We want to:

• Access Pattern 1: Get a user's profile.
• Access Pattern 2: Get all posts by a user, sorted by date.

Using a single table design:

• PK: USER#<userId>
• SK: #METADATA# (for user profile), POST#<postId> (for posts)

This allows fetching a user's profile and their posts with a single query on the USER#<userId> partition.

We've covered the essentials of DynamoDB data modeling:

• Understanding how Partition Keys and Sort Keys define your data structure.
• Designing around your access patterns, not just data relationships.
• The power of Single-Table Design for efficiency.
• Using Global Secondary Indexes (GSIs) for diverse queries.
• Utilizing Local Secondary Indexes (LSIs) for alternate sorting within a partition.

Effective data modeling is crucial for optimal performance and cost in DynamoDB!