AWS DynamoDB各类Key相关疑问及表主键替换方案咨询

嘿，我完全理解你被这些DynamoDB术语绕晕的感觉——当初我刚接触的时候也搞混过！下面我先把这些概念掰扯清楚，再一步步帮你解决更换主键的问题。

1. Partition Key vs Primary Key #

首先得明确：DynamoDB里的**Primary Key（主键）**有两种形式：

• 「简单主键」：就是单个的Partition Key（分区键），这时候Primary Key和Partition Key是同一个东西；
• 「复合主键」：由Partition Key + Sort Key（排序键）组合而成，这时候Partition Key只是Primary Key的一部分。

简单说：Partition Key的核心作用是决定数据存在哪个物理分区（DynamoDB会根据它的哈希值分配存储节点）；而Primary Key是整个表的唯一标识，要么只靠Partition Key，要么靠Partition+Sort的组合来确保每条数据唯一。

2. Sort Key vs Secondary Index #

• Sort Key是复合主键的一部分，属于主表的核心身份标识。它的作用是在同一个Partition Key下给数据排序，同时区分那些Partition Key相同的项（比如同一个用户的多个订单，用Order ID当Sort Key就能区分开）。
• **Secondary Index（二级索引）**是你给主表额外创建的「辅助查询入口」，我们常说的Secondary Key其实就是指二级索引的键。比如Global Secondary Index（GSI）可以有自己独立的Partition和Sort Key，Local Secondary Index（LSI）则必须和主表的Partition Key相同，只换Sort Key。

总结：Sort Key是主表自带的结构，Secondary Index是额外扩展的查询能力，完全不是一回事。

3. 添加Secondary Key（二级索引）的作用 #

• 解决「非主键查不了」的痛点：比如主表主键是Order ID，想查某个用户的所有订单，总不能全表扫描吧？建个以User ID为Partition Key的GSI，就能快速定位数据。
• 提升查询性能：预建的索引会提前整理好对应数据，比全表扫描快N倍，还能降低读取成本。
• 支持复杂查询：比如在GSI上结合Sort Key做范围查询（比如「查用户A最近30天的所有订单」），直接用索引就能搞定。
• 不碰主表结构：加二级索引不用修改主表的主键，灵活扩展查询能力的同时，不会影响原有业务。

重点提醒：DynamoDB不允许直接修改已存在表的主键结构——这是因为主键是数据的核心标识，改它相当于重构整个表的存储逻辑。所以得走「建新表+迁数据+切应用」的路线，步骤如下：

步骤1：创建新的目标表 #

创建新表时：

• 把User ID设为主键（如果需要，可以把Order ID设为Sort Key，这样同一个用户的订单不会重复，还能按订单ID排序）；
• 直接在新表上创建一个以Order ID为Partition Key的Global Secondary Index（GSI），满足以后按Order ID查询的需求。

步骤2：迁移旧表数据到新表 #

根据数据量和需求选合适的迁移方式：

• 小数据量：写个简单的脚本（比如Python+Boto3）批量迁移，示例代码如下：

import boto3

# 初始化DynamoDB资源
dynamodb = boto3.resource('dynamodb')
old_table = dynamodb.Table('你的旧表名称')
new_table = dynamodb.Table('你的新表名称')

def migrate_data():
    # 第一次扫描旧表（DynamoDB单次扫描最多返回1MB数据）
    response = old_table.scan()
    items = response['Items']
    
    # 批量写入新表
    with new_table.batch_writer() as batch:
        for item in items:
            # 确保User ID字段存在，若有缺失需提前处理
            batch.put_item(Item=item)
    
    # 处理分页数据（如果数据超过1MB，会返回LastEvaluatedKey）
    while 'LastEvaluatedKey' in response:
        response = old_table.scan(ExclusiveStartKey=response['LastEvaluatedKey'])
        items = response['Items']
        with new_table.batch_writer() as batch:
            for item in items:
                batch.put_item(Item=item)

if __name__ == '__main__':
    migrate_data()

• 中等规模数据：用AWS Data Pipeline，可视化配置迁移任务即可；
• 大规模/需数据转换：用AWS Glue（ETL工具）更合适；
• 旧表仍有实时写入：开启DynamoDB Streams配合Lambda，同步实时新增数据，避免迁移期间丢数据。

步骤3：验证数据完整性 #

迁移完成后，随机抽查部分数据对比新旧表，同时测试新表的二级索引是否能正常查询（比如用Order ID查找对应的订单），确保数据无丢失、结构无误。

步骤4：切换应用到新表 #

修改应用代码中所有读写DynamoDB的逻辑，切换到新表。建议先在测试环境验证，确认无误后再切生产。切完之后旧表建议保留1-2周，万一出问题可以快速回滚。

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