新手求助：AWS DynamoDB中分层文件夹文档的表结构设计方案

Hey there! Since you're new to DynamoDB and coming from a relational database background, let's walk through the best ways to model your folder-document hierarchy—especially since you need support for N-level nesting and documents that live in multiple folders.

First, let's start with the most important step for DynamoDB: defining your core access patterns. You'll want to optimize for these upfront:

• Fetch all documents and subfolders under a specific folder
• Find all folders that contain a given document
• Traverse the full folder hierarchy (e.g., from root down to a subfolder)
• Move a folder or document to another location
• Search for documents (if needed)

Recommended Single-Table Design #

DynamoDB shines with single-table design—it minimizes cross-table overhead and lets you model diverse relationships efficiently. Here's a practical schema:

Table Structure #

We'll use a table named DocumentManager with a composite primary key:

• Partition Key (PK): Formatted as ENTITY_TYPE#ID (e.g., FOLDER#f-100 for a folder, DOC#d-200 for a document)
• Sort Key (SK): Used to distinguish different types of relationships for each entity (e.g., METADATA for core entity details, FOLDER_LINK#<folder-id> for document-to-folder associations)

We'll also add two Global Secondary Indexes (GSIs) to support reverse queries:

1. FolderDocumentsIndex: GSI PK = FOLDER#<folder-id>, GSI SK = DOC#<doc-id> (for fetching all docs in a folder)
2. FolderChildrenIndex: GSI PK = PARENT_FOLDER#<parent-id>, GSI SK = FOLDER#<folder-id> (for fetching direct subfolders of a parent)

Example Data Entries #

Handling N-Level Folder Nesting #

You have two solid options here, depending on how you prioritize updates vs. query speed:

1. Path Enumeration (Fast Queries, More Update Overhead) #

Store a full-path attribute for each folder (e.g., /Work Projects/Client A). To get all subfolders under /Work Projects, you can query the main table with a filter on full-path starting with /Work Projects/.

Tradeoff: Moving a folder requires updating the full-path of every child folder. This is manageable if your folder structure doesn't change often, but can be costly for deep, frequently modified hierarchies.

2. Adjacency List (Easy Updates, Recursive Queries) #

Store a parent-folder-id for each folder instead. Use the FolderChildrenIndex to fetch all direct subfolders of a parent. To traverse the full hierarchy, you'll need to recursively query for each level (you can optimize this with BatchGetItem to reduce round trips).

Tradeoff: Querying the full hierarchy takes more steps, but moving a folder only requires updating its own parent-folder-id—no changes to children needed.

Many teams combine both: store parent-folder-id for easy updates, and maintain full-path as a computed attribute for fast prefix queries.

Supporting Documents in Multiple Folders #

Instead of storing an array of folder IDs on the document (which becomes messy to update), use association entries (the FOLDER_LINK#<folder-id> SK entries in the main table). Here's how this works:

• To add a document to a folder: Insert a new entry with PK=DOC#<doc-id> and SK=FOLDER_LINK#<folder-id>
• To remove a document from a folder: Delete that specific association entry
• To find all folders for a document: Query the main table where PK=DOC#<doc-id> and SK begins with FOLDER_LINK#
• To find all documents in a folder: Query the FolderDocumentsIndex where GSI PK=FOLDER#<folder-id>

Key Query Examples #

Let's translate common tasks into DynamoDB operations (using Python's boto3 for context):

Fetch all documents in a folder #

response = table.query(
    IndexName='FolderDocumentsIndex',
    KeyConditionExpression=Key('GSI_PK').eq('FOLDER#f-2')
)
# Returns all document IDs linked to the folder; use BatchGetItem to fetch full metadata

Get all folders containing a document #

# First get all folder links for the document
link_response = table.query(
    KeyConditionExpression=Key('PK').eq('DOC#d-1') & Key('SK').begins_with('FOLDER_LINK#')
)
folder_ids = [item['folder-id'] for item in link_response['Items']]

# Then fetch folder metadata in bulk
folder_details = table.batch_get_item(
    RequestItems={
        'DocumentManager': {
            'Keys': [{'PK': f'FOLDER#{fid}', 'SK': 'METADATA'} for fid in folder_ids]
        }
    }
)

Pros & Cons of This Approach #

Pros #

• Aligns with DynamoDB's best practices for performance and cost efficiency
• Flexible enough to handle N-level nesting and multi-folder documents
• Clear, predictable query patterns for all your core use cases

Cons #

• Path enumeration requires updating child folders when moving a parent (mitigable with adjacency list)
• You need to plan all access patterns upfront—DynamoDB isn't great for ad-hoc, complex queries

Alternative: Multi-Table Design (Not Recommended) #

If you're really attached to relational-style separation, you could split into three tables:

1. Folders: Stores folder metadata (PK: folder-id)
2. Documents: Stores document metadata (PK: doc-id)
3. DocumentFolderLinks: Stores associations (PK: doc-id, SK: folder-id)

But this defeats DynamoDB's strengths—you'll end up with multiple round trips for simple queries, and higher latency/cost. Stick to single-table design unless you have a very specific edge case.

内容的提问来源于stack exchange，提问作者Gagan Bajaj