为什么DynamoDB不直接使用普通JSON作为其数据结构？

这个问题属于典型的产品设计路径依赖类的历史问题，核心原因可以归纳为3点：

• 立项阶段的优先级选择
  DynamoDB的研发启动于2010年左右，核心设计目标是支撑亚马逊电商内部超大规模、超低延迟的键值存储需求，性能和存储成本是当时团队的第一优先级。原生JSON是弱类型格式，如果直接作为交互格式，底层引擎需要额外消耗计算资源做类型推断、歧义处理，还要存储额外的元信息才能保证查询、索引逻辑的正确性，不符合当时极致性能优化的要求。而带显式类型标记的自定义格式（即我们现在看到的S/N/B等类型标识结构），可以让底层引擎跳过类型解析步骤直接处理数据，性能损耗远低于原生JSON方案。
• 底层架构的路径依赖
  DynamoDB的核心设计完全参考了亚马逊2007年对外发布的《Dynamo: Amazon's Highly Available Key-value Store》论文，内部存储层从设计之初就采用了显式类型标记的存储结构，这套结构已经在亚马逊内部跑了多年，稳定性经过了超大规模场景的验证。如果要在对外接口层适配原生JSON，需要重构整个类型校验、索引构建、条件查询的上层逻辑，在产品刚上线的阶段完全没有必要，优先级远低于扩容、稳定性优化这类核心需求。
• 多语言兼容性的现实限制
  2010年前后不同编程语言的JSON解析生态成熟度很低，不同语言的JSON库对64位大整数、二进制数据、特殊空值的处理逻辑差异极大，很容易出现不同语言SDK读写同一条数据得到不同结果的问题。而采用显式类型标记的格式，所有语言的SDK都不需要做类型推断，完全按照标记处理数据，可以100%保证多语言场景下的数据一致性，避免了很多边缘场景的故障。

后续推出的DocumentClient本质就是在SDK层做了一层透明的转换逻辑，把用户传入的原生JSON自动映射为DynamoDB底层的带类型标记格式，不需要用户手动编写类型转换代码，底层存储的核心逻辑其实没有发生变化。

内容的提问来源于stack exchange，提问作者Kat Lim Ruiz