存储多种文档类型的最佳Amazon DynamoDB架构选型咨询

Great question—this is a super common scenario when getting started with DynamoDB, and the right call depends mostly on your access patterns and scalability needs. Let’s break down each of your options and talk about what’s standard in the DynamoDB ecosystem:

Option 1: Partition Key = type, Sort Key = UUID #

This is the most widely recommended single-table design pattern for this use case, and it aligns perfectly with DynamoDB’s core design principles. Here’s why it works so well:

• Organized grouping: All documents of the same type (e.g., all users, all events) live in the same partition, making it trivial to query or scan all items of a specific type with a simple Query operation (targeting the type partition key).
• Built-in uniqueness: The UUID sort key guarantees no duplicate entries within each document type, which solves your unique ID requirement cleanly.
• Future flexibility: You can easily add Global Secondary Indexes (GSIs) later to support other access patterns—like querying all events linked to a specific user ID, if that becomes a need.
• Scalability safeguards: While you might worry about "hot partitions" if one type grows extremely large, DynamoDB automatically splits partitions when they hit storage or throughput limits. As long as your read/write traffic is spread across items (which random UUIDs ensure), this shouldn’t be a major issue for most applications.

Option 2: Partition Key = UUID, Sort Key = type #

This approach is generally not recommended for most scenarios. Here’s the core problem:

• Random UUIDs as partition keys spread every single item across different partitions. That means querying all items of a specific type would require a full table scan—an operation that’s slow, inefficient, and gets worse as your dataset grows.
• The sort key (type) adds no practical value here. You can’t use it to group or filter items efficiently when the partition key is random, so you’re wasting the composite primary key’s capabilities.

Option 3: Separate Tables for Each Document Type #

This is a valid choice if your use case has specific constraints, but it’s less common than the single-table approach. When to consider it:

• Isolation requirements: If you need strict logical or security isolation between document types (e.g., compliance rules that mandate separate storage for user data vs. event data), separate tables make sense.
• Divergent access patterns: If each type has completely different query needs (e.g., user data needs multiple GSIs for complex lookups, while news data only needs basic primary key queries), managing separate tables can simplify schema design.
• Downsides: You’ll incur higher operational overhead (managing permissions, backups, and monitoring for multiple tables), and cross-type queries (e.g., fetching a user and their related events) will require multiple API calls, adding latency compared to a single-table query.

Final Recommendation #

Start with Option 1 (single table with type as partition key and UUID as sort key) unless you have a clear, unavoidable need for separate tables (like strict isolation or wildly divergent access patterns). This approach is flexible, efficient, and aligns with DynamoDB’s best practices for scalable, cost-effective data storage.

内容的提问来源于stack exchange，提问作者Arsenii Fomin