DynamoDB表与带Primary Key关系表对比：非超大规模场景下的优势差异

一、用带主键+可空属性的关系表模拟键值数据库是否可行？ #

如果你的业务规模很小（单表数据量低于千万级、读写QPS低于1万），且没有极低延迟的要求，这个方案完全可行，尤其如果你本身已经在使用关系型数据库技术栈，不需要额外引入新组件，反而能降低运维复杂度。

二、反对该方案的核心观点 #

• 写入性能差距明显：关系型数据库需要支持ACID特性、约束校验、SQL解析等额外逻辑，同硬件条件下，单表主键写入QPS比专业键值数据库低1~2个数量级，如果存在二级索引，写入放大效应会更加突出。
• 结构变更成本更高：即使是PostgreSQL 12+这类对无默认值可空字段新增做了优化的关系库，只要涉及新增带默认值的字段、新增二级索引操作，依然会产生锁表或者额外的资源消耗，而键值数据库不存在表结构变更的概念，新增属性无任何开销。
• 空值冗余开销更大：关系型数据库的可空字段即使未写入内容，也会占用一定的元数据存储空间，数据量上升后冗余存储占比会明显高于键值数据库，后者仅会存储实际写入的属性。
• 二级索引灵活性更差：如果后续需要新增非主键维度的查询能力，关系库需要新建二级索引，构建过程会占用主库资源，而DynamoDB这类键值数据库的全局二级索引是异步构建，完全不会影响主表写入性能。

三、非PB级存储场景下，键值数据库对比支持JSON的关系库的独有优势 #

• 读写延迟更稳定：键值数据库内核逻辑极精简，去掉了复杂的查询优化、事务校验等流程，主键查询的P99延迟通常能稳定在1ms以内，而关系库即使是主键查询，遇到锁、查询队列拥堵时延迟波动会大得多，对延迟敏感的场景（如用户会话存储、推荐特征存储）优势非常突出。
• 原生TTL自动过期能力：绝大多数键值数据库都自带数据生命周期管理能力，写入时指定TTL即可自动删除过期数据，不需要自行编写定时任务扫描大表删除旧数据，完全避免了扫表导致的数据库性能抖动问题。
• 运维成本更低：中小规模场景下，键值数据库不需要做复杂的容量规划、分库分表，比如Redis、DynamoDB按需模式开实例即可直接使用，扩容不需要做数据迁移，而PostgreSQL如果遇到性能瓶颈需要扩容，通常要搭建读写分离或者做分库分表，运维复杂度高很多。
• 资源消耗更低：同负载下键值数据库的资源占用远低于关系型数据库，比如同样支撑10万QPS的主键读写，用2核4G的Redis实例即可满足需求，换做PostgreSQL可能需要8核16G的实例，长期使用成本更低。
• 原生原子操作支持：比如计数、原子增减、内容追加这类高频操作，键值数据库直接原生支持，以Redis为例，仅需要执行INCR like:article_123即可实现原子点赞计数，不需要写复杂的SQL加锁实现，并发场景下不会出现冲突问题，性能也高得多。

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