DynamoDB单表存储用户及订单等交易数据的可行性与设计方案

在DynamoDB单张表中同时存储用户数据、关联订单/发票类交易数据是完全成熟的生产可行方案，完全可以适配你之前用PostgreSQL承载的这类业务需求。

• 最开始设想的用对象、数组嵌套结构把订单、发票数据直接塞到用户记录下的方案不算最优：DynamoDB单条项目有400KB的硬上限，嵌套存储不仅容易撞大小限制，后续更新单条订单/发票时需要读写整条用户记录，也没法单独对交易数据做分页、条件筛选，只适合关联数据量极小、几乎不会单独变更的边缘场景。
• 你参考AWS官方文档采用的「分区键+排序键划分项目集合」的设计，就是DynamoDB单表设计的标准最佳实践：
  • 常规落地方式是将用户ID作为统一分区键，通过排序键的前缀标识数据所属类型：比如用USER#profile作为排序键存储用户基础信息，ORDER#<订单ID>存储对应订单记录，INVOICE#<发票ID>存储对应发票记录
  • 这套结构下，你既可以通过指定分区键的单次查询，拉取到某个用户下的全量基础信息、历史订单、发票数据，也可以通过排序键的范围匹配，单独筛选某一类数据、指定ID/时间区间的交易记录，全程不需要做跨表关联，查询性能稳定保持在毫秒级。

落地时可以提前梳理跨用户维度的查询需求（比如按订单状态筛选全平台待发货订单、按开票时间统计月度发票额），给对应字段配置全局二级索引（GSI）即可，不需要调整单表的核心存储结构。

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