DynamoDB单表架构下存储静态配置数据的最佳实践咨询

场景最佳实践与落地方案 #

针对你当前基于DynamoDB单表架构的业务场景，行业内优先推荐选择方案2：将静态配置数据与业务数据存储在同一DynamoDB表中，所谓的结构杂乱问题完全可以通过标准化的主键命名规则规避，整体收益远高于其他两个方案。

具体实现方式 #

你可以给所有全局静态配置统一使用固定PK前缀，和现有业务数据的主键规则做天然隔离，参考设计如下：

• 所有静态配置项的PK统一设置为 CONFIG#GLOBAL
• SK按「配置类型+唯一标识」的规则命名，不同类别的配置完全区分

示例：国家数据存储结构

PK: CONFIG#GLOBAL
SK: COUNTRY#1
Name: Germany
Code: de
DialCode: 49

PK: CONFIG#GLOBAL
SK: COUNTRY#2
Name: Turkey
Code: tr
DialCode: 90

其他类型静态配置可以按同样规则延伸：

• 提示文案类：SK = PROMPT#LOGIN_SUCCESS
• 常量类：SK = CONSTANT#MAX_UPLOAD_SIZE

方案优势 #

• 运维成本最低：不需要额外维护多张DynamoDB表或新的数据库服务，权限、监控、备份规则都可以和现有业务表复用
• 访问逻辑统一：应用不需要适配多套数据库客户端，查询逻辑和现有业务数据的DynamoDB操作完全一致
• 性能表现更好：静态数据体量极小，不会占用单表吞吐量配额，需要批量拉取某类配置时，直接对PK=CONFIG#GLOBAL做SK前缀查询即可，延迟远低于关系型数据库查询
• 可以搭配缓存进一步优化：因为静态数据变更频率极低，你可以在应用层加本地缓存或分布式缓存，仅缓存失效时查询DynamoDB，进一步降低访问成本

其他方案适用场景 #

• 仅当你的静态配置需要跨多个完全隔离的业务域共享、且不同业务域的表权限管控要求非常严格时，可以选择方案1，单独创建一张全局静态配置DynamoDB表，所有业务域统一只读访问即可
• 方案3完全不推荐：已经全栈基于DynamoDB架构的前提下，为极小体量的静态配置额外引入PostgreSQL这类关系型数据库，会平白增加多数据源运维、多客户端适配的成本，得不偿失。

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