DynamoDB不相关实体该选择单表设计还是多表设计？

所有公开的DynamoDB单表设计教程，核心案例基本都围绕需要关联查询的实体展开，针对完全无关联、换到SQL场景根本不需要JOIN的实体，我们锁死讨论边界，从三个核心维度展开对比：

性能维度对比 #

• 单表混存不相关实体的性能特性：
  • 优势在于可以跨实体共享表的读写吞吐配额。如果几个实体的访问峰值完全错峰（比如用户行为日志是晚高峰压力、全局配置是早高峰读取），混存能避免单张表峰值打满、另一张表空跑预留资源的情况，甚至可以摊薄单个实体的热点键风险。
  • 劣势也非常明确：DynamoDB的表级读写吞吐是全局共享的，没有办法按实体维度切分固定配额。如果混存的实体访问模式差异极大——比如一个是每秒写1万次的IoT上报日志，另一个是每天读10次的关键系统配置，当IoT写入打满整表吞吐时，低频次的配置读取会直接被连带限流，根本没法给关键操作留独立资源池。
  • 更隐蔽的问题是分区键设计冲突：无关联实体的分区键逻辑本来完全独立——比如日志类用高基数字符串（设备ID+时间戳）当分区键，配置类用固定短ID（如"global-config"）当分区键。这类设计放在同一张表里，很容易出现本来独立存储时运行正常的低基数键，被同分区的高基数写入流量挤占，直接触发单分区限流。
  • 另外所有实体共用同表的全局二级索引，为某一个实体新增的索引会分摊整表的写入吞吐——比如给日志实体加个按时间查询的GSI，每次写日志都要多算一份索引写入量，最终会导致同表所有实体的写入延迟整体上涨。
• 独立分表存储的性能特性：
  • 优势是每个表的读写配额完全独立，某一个实体的峰值流量完全不会影响其他实体的读写。不管哪个实体的流量出现抖动，都可以独立针对它做参数调优（比如给高写实体开分区热点优化、给低读实体调低预留吞吐），不会出现互相干扰的情况。
  • 劣势是如果多个实体的访问峰值在同一时间触发，需要分别给每个表预留足够的峰值吞吐，很容易出现各表预留的冗余资源在非峰值时段完全空跑的情况。

资金成本维度对比 #

• 单表混存的成本特性：
  • 优势是DynamoDB本身不对表数量收取固定费用，混存不会因为多存几个实体产生额外的元数据成本。如果用预置吞吐模式，混存可以通过错峰复用吞吐配额，减少每个实体单独预留的冗余量——比如10个错峰访问的实体，按总峰值凑够200RCU/200WCU就能覆盖，比每个实体单独预留100RCU/100WCU的总成本能低60%以上。另外混存场景下备份、灾备的操作范围只覆盖一张表，也能减少跨表运维的隐性人力成本。
  • 劣势是没有实体维度的读写配额隔离，某个实体的代码bug（比如循环重复写入、错误的批量拉取）很容易把整表的按需模式读写量打飞，产生远超预期的账单——很多用户都遇到过把边缘小实体的日志误写到核心单表里，一天就产生上千块按需费用的情况。另外为了适配不同实体的查询需求，很容易在同一张表上叠加大量全局二级索引，而这些索引的读写是单独收费的，最后往往会出现索引成本比主表读写、存储成本还高的情况。
• 独立分表存储的成本特性：
  • 优势是可以针对每个实体的实际流量模式选最划算的计费方式——比如年访问量不到1万次的边缘配置表，直接开按需模式零预留成本；高流量的核心交易表用预留实例券抵扣长期成本，不会让低流量实体平摊核心表的高预留成本。另外每个表的计费完全独立，哪个实体的流量异常，账单会直接对应到那张表，排查成本低，不容易因为局部bug拉爆整体账单。
  • 劣势是如果没有做跨表的流量错峰调度，会有大量预留资源空跑——比如10个实体的峰值各自是1000WCU，但每个峰值出现的时间差在1小时以上，给每个表预留1000WCU的总预留量，是混存模式总预留量的5倍，光预置成本就会差出数倍。另外多表场景下需要为每个表单独配置监控、告警、备份策略，也会产生额外的运维人力成本。

可维护性维度对比 #

• 单表混存的可维护性特性：
  • 优势是如果团队已经有成熟的统一数据访问层，可以把权限校验、操作埋点、审计逻辑都封装在同一段代码里，不需要为每个实体单独写一套客户端逻辑。要做全库备份、合规数据导出时，也只需要针对一张表操作，不用跨几十张表拼接数据。
  • 劣势在无关联实体场景下会被放大：
    • Schema演进的冲突成本极高：不同实体的迭代节奏完全错位——比如用户偏好配置每两周就要加新字段，系统审计日志半年都不会改结构。混存的时候，哪怕只是给其中一个小实体加个查询索引、调整个属性字段，都要评估对同表所有其他实体的影响，跨团队的评审成本会随表内实体数量直线上涨，迭代效率被严重拖慢。
    • 故障爆炸半径没有边界：单表场景下，不管是分区键设计错误触发热点、还是权限配置错误，还是某个实体的异常流量打满吞吐，所有存在这张表里的无关联实体都会同时故障。本来分表时，某一个实体出问题只会影响10%的业务可用性，混存之后一次故障就可能拉垮所有相关实体。
    • 权限边界很难划分：DynamoDB的原生权限体系是表级别的，就算开了细粒度访问控制，要给N个无关联实体配独立的访问权限，规则复杂度会随实体数量指数级上升，很容易出现权限过配，导致某个业务模块的操作误删完全不相关的其他实体的数据。
• 独立分表存储的可维护性特性：
  • 优势是每个实体的表完全独立，Schema演进时不需要考虑对其他实体的影响，改字段、加索引、调整分区键只需要对应业务团队评审即可，迭代速度快。故障爆炸半径小，某张表出问题只影响对应的业务实体，因为每个表的访问日志、监控指标都是独立的，排查定位的成本很低。另外权限边界清晰，每个业务模块只需要拿到自己对应表的权限，不用开放整库的访问权，安全风险低。
  • 劣势是表数量多了之后，元数据管理的复杂度会上升——几十张表的时候，很容易搞混哪个表对应哪个业务、哪个表开了时间点备份、哪个表的限流告警阈值是多少，稍不注意就会出现配置错漏。如果没有统一的数据访问层做封装，还会在各个业务模块里写出很多重复的DynamoDB客户端代码，产生冗余维护成本。

实际决策参考边界 #

• 更适合选单表混存的情况：几个无关联实体的访问峰值高度错峰，单个实体的流量规模都不高，团队已经有成熟的实体配额隔离、细粒度权限管控的落地经验，且所有实体的迭代节奏基本对齐，不存在核心实体快速迭代、边缘实体长期不动的节奏差。
• 更适合选独立分表的情况：实体之间的业务优先级差异极大（比如核心交易配置 vs 边缘行为日志），或者访问模式差异大（高并发写入 vs 低频关键读取）；实体迭代节奏完全错位，需要独立版本演进；实体的安全访问权限要求差异大，需要严格隔离访问边界。

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