单集群双重视图 🃏

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家

在 DynamoDB 中，单表设计 将一对多关系存储在同一个物理块中，同时仍遵循类似关系型数据库的范式分解。在 MongoDB 中，单集合模式 将关系从单个文档中展开，但这违背了一般建议，因为它牺牲了 MongoDB 的一个关键优势——将文档保持在单个块中。在 Oracle 数据库和 MySQL 中，JSON-关系型对偶视图将 JSON 文档规范化为跨越多个块的关系型表，同样无法获得 MongoDB 所具备的数据局部性优势。我们能否将这些对偶视图转变为一种文档数据库等效形式，使经常一起访问的数据保持在一起？

这就是单簇对偶视图 🥁。

DynamoDB

NoSQL 最初采用简单的键值 API。例如，DynamoDB 可以使用完整键获取一个项目，使用部分键查询多个项目，或在不使用键的情况下扫描所有项目。在此类键值数据存储中，值是原子的，但有时你需要部分读取或写入。此时你有两种解决方案：读取或写入整个项目（如果你并不需要全部内容，这种方式效率低下），或者更改你的模式设计，将其拆分为多个项目。

后者被称为单表设计，因为它不仅将项目拆分为多个实体，还将它们存储在同一张表中，并共享一个键前缀，从而通过一次查询即可检索所有相关项目。其核心思想是：你既可以访问单个对象，又能在查询完整聚合体时受益于数据局部性。

这种设计的优势高度依赖于 DynamoDB 的具体特性：其存储内部机制（项目根据键进行分区和聚簇）以及计费模型（按表请求单元计费）。

以下是一个示例，使用传统的部门与员工的一对多模式：

一张 DynamoDB 表
部门和员工分别作为独立项目存储
两者使用相同的分区键（DEPT#<deptno>）：

aws dynamodb create-table \
  --table-name scott \
  --attribute-definitions \
    AttributeName=PK,AttributeType=S \
    AttributeName=SK,AttributeType=S \
  --key-schema \
    AttributeName=PK,KeyType=HASH \
    AttributeName=SK,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

逻辑模型中，通过共享部门编号作为相同的分区键来体现关系；而物理模型中，这些数据也确实存储在一起，因为项目正是基于该键进行分区的：

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。