DynamoDB-Tabellen entwerfen
Lernen Sie Best Practices für den Entwurf effizienter DynamoDB-Tabellenschemas kennen, mit Fokus auf Partition Keys und Sort Keys für optimale Performance.
DynamoDB-Tabellen entwerfen ist eine kostenlose Serverless Backend with AWS Lambda & API Gateway-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Serverless Backend with AWS Lambda & API Gateway-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Serverless Backend with AWS Lambda & API Gateway-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Why DynamoDB Design Matters
Welcome to designing DynamoDB tables! Unlike traditional relational databases, DynamoDB is a NoSQL database that requires a different approach to schema design.
- Its serverless nature and performance at scale depend heavily on how you design your tables and choose your keys.
- A well-designed table ensures fast, consistent performance and cost efficiency.
- A poor design can lead to slow queries, high costs, and operational headaches.
The Partition Key (PK)
Every item in a DynamoDB table is uniquely identified by its primary key. The first part of any primary key is the Partition Key (sometimes called a Hash Key).
- DynamoDB uses the Partition Key's value as input to an internal hash function.
- This function determines the physical partition (storage location) where your data is stored.
- Good Partition Keys distribute data evenly across partitions, preventing 'hot spots' and ensuring scalability.
The Sort Key (SK)
The second part of a primary key, if you choose to have one, is the Sort Key (sometimes called a Range Key).
- Items with the same Partition Key are grouped together and sorted by their Sort Key value.
- This allows for efficient range queries (e.g., 'all orders from a user within a date range').
- The combination of Partition Key and Sort Key must be unique for each item in the table.
Understanding Primary Keys
A table's primary key can be either a simple primary key (only a Partition Key) or a composite primary key (a Partition Key and a Sort Key).
- Simple Primary Key: Ideal when each item needs a unique identifier, like a
userIdfor a Users table. - Composite Primary Key: Best for one-to-many relationships or when you need to query items that share a common partition key but differ by a secondary identifier, like
userIdandorderIdfor an Orders table.
Simple PK in Action
Let's consider a Users table where each user has a unique userId. We can use userId as the simple Partition Key. Here's how an item might be added:
import boto3
# This client is conceptual for illustration.
# In a real app, it would connect to your DynamoDB table.
class MockDynamoDBTable:
def __init__(self, name):
self.name = name
self.items = {}
def put_item(self, Item):
pk = Item['userId']
if pk in self.items:
print(f"Warning: Item with userId '{pk}' already exists. Overwriting.")
self.items[pk] = Item
print(f"Item added/updated in '{self.name}': {Item}")
# Simulate a DynamoDB table named 'Users'
table = MockDynamoDBTable('Users')
def add_user_item():
table.put_item(
Item={
'userId': 'user123',
'username': 'Alice',
'email': 'alice@example.com'
}
)
if __name__ == "__main__":
add_user_item()Composite PK in Action
Now, imagine an Orders table where a user can have multiple orders. We'd use userId as the Partition Key and orderId as the Sort Key. This allows us to retrieve all orders for a specific user, sorted by orderId.
import boto3
# This client is conceptual for illustration.
# In a real app, it would connect to your DynamoDB table.
class MockDynamoDBTable:
def __init__(self, name):
self.name = name
self.items = {}
def put_item(self, Item):
pk = Item['userId']
sk = Item['orderId']
if pk not in self.items:
self.items[pk] = {}
self.items[pk][sk] = Item
print(f"Item added/updated in '{self.name}': {Item}")
# Simulate a DynamoDB table named 'Orders'
table = MockDynamoDBTable('Orders') # Assume PK: userId, SK: orderId
def add_order_item():
table.put_item(
Item={
'userId': 'user123',
'orderId': 'order456',
'itemCount': 2,
'totalAmount': 50.00,
'orderDate': '2023-10-26'
}
)
if __name__ == "__main__":
add_order_item()Designing for Access Patterns
The most crucial aspect of DynamoDB design is understanding your access patterns. You should design your primary keys around how your application will query the data, not just how the data looks.
- What queries will you make? (e.g., 'Get all products by category', 'Get a specific user's latest posts').
- What data will be returned? (e.g., single item, list of items).
- Your Partition Key should typically be the attribute you query on most frequently for specific items or groups of items.
- Your Sort Key allows for flexible queries within that group (e.g., range queries, reverse order).
Key Selection Best Practices
Choosing the right keys is vital for performance:
- High Cardinality: Keys should have many unique values to prevent 'hot spots' on a single partition.
- Even Distribution: Values should be accessed roughly equally. Avoid keys where a few values are queried much more often than others.
- Query Efficiency: Design keys so that most common queries can be satisfied using
GetItem(PK only) orQuery(PK + optional SK condition). - Avoid Scans: Operations that read every item in a table (
Scan) are inefficient and costly. Your design should minimize the need for them.
Modeling One-to-Many Relationships
Composite Primary Keys are excellent for modeling one-to-many relationships, which are very common. For example, a user has many posts:
- Partition Key:
USER#<userId>(a common pattern to prefix keys for clarity). - Sort Key:
POST#<postId>. - This design allows you to fetch all posts for a user by querying only on the Partition Key, and even specific posts by adding a Sort Key condition.
This approach keeps related data together, enabling efficient retrieval.
Design Challenge
You are designing a table to store user comments on various articles. Your primary access patterns are:
- Get all comments for a specific article.
- Get all comments made by a specific user.
Which primary key design would best support getting all comments for a specific article efficiently?
Key Design Recap
Great job! In this lesson, you learned the foundational principles of designing DynamoDB tables:
- The importance of Partition Keys for data distribution.
- The utility of Sort Keys for ordering and range queries.
- How Primary Keys (simple or composite) uniquely identify items.
- The critical role of access patterns in driving your design choices.
- Best practices for selecting keys to ensure performance and cost efficiency.
Mastering these concepts is key to building scalable and performant serverless applications with DynamoDB!
Häufig gestellte Fragen
Ist die Lektion „DynamoDB-Tabellen entwerfen“ kostenlos?
Ja — der vollständige Text von „DynamoDB-Tabellen entwerfen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Serverless Backend with AWS Lambda & API Gateway-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Serverless Backend with AWS Lambda & API Gateway-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „DynamoDB-Tabellen entwerfen“?
Lernen Sie Best Practices für den Entwurf effizienter DynamoDB-Tabellenschemas kennen, mit Fokus auf Partition Keys und Sort Keys für optimale Performance. Du übst Serverless Backend with AWS Lambda & API Gateway mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Serverless Backend with AWS Lambda & API Gateway zu starten?
Keine Vorkenntnisse erforderlich. Serverless Backend with AWS Lambda & API Gateway auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „DynamoDB-Tabellen entwerfen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Serverless Backend with AWS Lambda & API Gateway-Lektion Code schreiben und ausführen?
Ja. Jede Serverless Backend with AWS Lambda & API Gateway-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Einführung in DynamoDB
- DynamoDB-Tabellen entwerfen
- Lambda- und DynamoDB-Integration
- Abfragen mit sekundären Indizes: GSIs und LSIs