如何在DynamoDB中为用户ID设别名？两种方案该选哪个？

现有DynamoDB用户表结构如下：

Web应用的用户个人页目前通过UUID形式的URL（如http://example.com/aee97067-b363-495c-9531-f1da15812eee）访问，现希望支持用户创建可读别名（如http://example.com/johndoe），需设计合适的DynamoDB表结构，目前有两个候选方案：

方案1：用别名替换PK中的UUID #

将原表的PK和SK替换为别名，结构如下：

顾虑：修改作为静态ID的UUID可能影响日志及其他关联数据的引用。

方案2：为别名创建全局二级索引（GSI） #

保留原UUID作为PK/SK，新增GSI字段存储别名，结构如下：

顾虑：写入数据前需通过别名查询真实ID，担心影响效率。

优先选择方案2，理由如下：

1. 避免数据关联断裂：UUID作为用户的核心静态ID，已经在日志、其他关联表或系统中存在引用，替换为别名会导致历史数据无法关联到当前用户，后续排查问题、数据溯源都会出现障碍，这是架构设计中需要避免的核心问题。

2. 效率问题可优化：关于GSI查询的效率顾虑，可通过以下方式缓解：

   • 别名唯一性校验前置：在用户创建别名时，通过GSI的GSI1PK做单点查询确认别名未被占用，这类查询成本极低，耗时可忽略。
   • 缓存优化：将别名与UUID的映射关系缓存到内存缓存中，后续通过别名访问个人页时直接从缓存获取UUID，无需每次查询GSI，大幅提升访问效率。
   • GSI配置优化：将GSI的ProjectionType设置为KEYS_ONLY，只投影主键和GSI键，减少存储成本和写入开销。

3. 扩展性更强：如果后续需要支持用户修改别名，方案2只需更新GSI的GSI1PK字段即可，无需修改核心的PK/SK，不会影响已有数据关联；而方案1修改PK会涉及全表数据更新（包括关联表），操作风险极高。

4. 兼容原有访问方式：方案2可同时支持UUID和别名两种访问方式，实现平滑过渡；方案1替换PK后，原有UUID形式的URL会失效，需要额外做301重定向或兼容处理，增加开发成本。

如果担心GSI的写入开销，也可以考虑第三种优化方案：新增一张单独的别名映射表，结构为PK: alias#johndoe，SK: user#aee97067-b363-495c-9531-f1da15812eee，存储别名到UUID的映射。查询别名时直接访问这张表，主表不受影响，写入时只需在映射表新增一条数据，开销更低，同时保留主表的UUID核心ID，适合用户量较大、对主表写入性能要求极高的场景。

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