Serverless Backend with AWS Lambda & API Gateway · 강의

DynamoDB 테이블 설계

최적의 성능을 위해 파티션 키와 정렬 키에 중점을 두고 효율적인 DynamoDB 테이블 스키마를 설계하는 모범 사례를 학습합니다.

DynamoDB 테이블 설계은(는) CoddyKit의 무료 Serverless Backend with AWS Lambda & API Gateway 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Serverless Backend with AWS Lambda & API Gateway 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Serverless Backend with AWS Lambda & API Gateway 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

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 userId for 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 userId and orderId for 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) or Query (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!

자주 묻는 질문

“DynamoDB 테이블 설계” 강의는 무료인가요?

네 — “DynamoDB 테이블 설계” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Serverless Backend with AWS Lambda & API Gateway 강의 전체를 잠금 해제할 수 있습니다. Serverless Backend with AWS Lambda & API Gateway 강의에는 총 4개의 강의가 포함되어 있습니다.

“DynamoDB 테이블 설계”에서 뭘 배우나요?

최적의 성능을 위해 파티션 키와 정렬 키에 중점을 두고 효율적인 DynamoDB 테이블 스키마를 설계하는 모범 사례를 학습합니다. 브라우저에서 직접 실행하는 실습 코드로 Serverless Backend with AWS Lambda & API Gateway을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Serverless Backend with AWS Lambda & API Gateway을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Serverless Backend with AWS Lambda & API Gateway은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“DynamoDB 테이블 설계” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Serverless Backend with AWS Lambda & API Gateway 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Serverless Backend with AWS Lambda & API Gateway 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Serverless Backend with AWS Lambda & API Gateway(으)로 돌아가기