ExtendDB：在你自己的数据库上运行 DynamoDB API

假设有一套医院记录系统必须留在大楼内部 —— 患者数据绝不能离开本地网络，每一项依赖都要经审计员 签字放行，而开发笔记本电脑完全没有互联网。团队已经针对 DynamoDB API 编写了应用并且很喜欢它： 个位数毫秒的键查找、一个干净的项模型、没有需要照看的 schema 迁移。但托管的 DynamoDB 是一个云 服务，而“把数据发送到 AWS”在这里是无法接受的。

ExtendDB 正是为这个空缺而生。它说的是 DynamoDB 的传输协议，但把数据 存储在一个你自己运行的数据库里。

ExtendDB 是什么

ExtendDB 是一个来自 AWS 的开源适配器 —— 由 AWS DynamoDB 工程师编写，并 在 AWS Database 博客上发布 —— 它用 Rust 实现了 DynamoDB JSON 传输协议。由于它响应与托管服务相同的 HTTP API，你现有的 AWS SDK 和 AWS CLI 都能原封不动地工作。唯一移动的是 endpoint URL —— 无需重写代码、无需新的 客户端库。

有意思的部分在于那个 API 背后是什么。ExtendDB 拥有可插拔的存储后端：PostgreSQL 是其参考 实现，而 Cassandra 被列为另一个可能的后端。新后端无需修改核心即可实现，因此 DynamoDB 兼容层 和存储层各自独立演进。

于是一个请求像这样流动：

它支持什么 —— 以及不支持什么

据入门文档和那篇公告所述，ExtendDB（v0.1）覆盖了大多数应用实际会调用 的操作：

• 表 —— Create、Delete、Describe、List、Update。
• 项 —— Put、Get、Delete、Update（包括 SET / REMOVE / ADD / DELETE 更新动作）。
• Query 和 Scan —— 键条件、筛选表达式、投影、分页和二级索引。
• 批量 —— BatchGetItem 和 BatchWriteItem。
• 事务 —— TransactGetItems 和 TransactWriteItems。
• Streams、TTL、Import/Export 和 Tags。

它有意不实现的，是那组 DynamoDB 专有的托管特性 —— 最显著的是 Global Tables 和 跨区域复制。那些是托管服务全球基础设施的属性，而非 API 表面的属性，所以它们不会延续到一个 你自己托管的适配器上。

对比 DynamoDB Local

你也许已经用 DynamoDB Local 做离线开发。那是一个单独的 JAR（或 amazon/dynamodb-local Docker 镜像），意在单机上的单元测试。ExtendDB 的目标比那个单进程工具 更宽广：本地开发、本地部署、边缘和气隙环境，以及那些你想要 DynamoDB API 但数据驻留在你所 掌控的基础设施中的混合 / 多云场景。

对比托管的 DynamoDB

这是 AWS 明确划下的界线，而且它很重要：

ExtendDB 不是 DynamoDB。它是一个兼容实现，而非托管服务的替代品。其性能特征、伸缩行为和运维 属性都有所不同。

具体来说，当你运行 ExtendDB 时：

• 数据库的可用性和备份由你负责。 没有托管的多可用区持久性或时间点恢复在为你打理 —— 那要靠 你和你的 PostgreSQL 运维。
• endpoint 上强制使用 TLS。
• 凭证是类 IAM 的，但与 AWS IAM 分离 —— ExtendDB 有它自己的凭证模型；它不针对你的 AWS 账户 做身份认证。

它是 v0.1，以 Apache 2.0 授权。把它当作早期软件：对上面那些环境很棒，但不是面向生产 规模托管 DynamoDB 的即插即用替换。

安装

ExtendDB 运行在 Linux 和 macOS 上，需要 Rust 1.85+ 和 PostgreSQL 14+。流程是两条命令：

extenddb init
extenddb serve

init 在你的 PostgreSQL 数据库中预置 schema；serve 启动传输协议服务器，它监听一个像 https://127.0.0.1:8000 这样的 endpoint（需要 TLS，因此是 https）。

像你对待任何自定义 endpoint 那样把 AWS SDK 指向它 —— 只有 URL 和凭证会变：

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

客户端配置之后的一切 —— PutItem、Query、TransactWriteItems —— 都与你针对托管 DynamoDB 编写的代码完全相同。一个单表项布局的工作方式与在云端时一模一样：

在 DynoTable 中操作

由于 ExtendDB 说的是 DynamoDB 传输协议，你不需要为它单独准备一个管理工具 —— 像你连接 DynamoDB Local 那样，把 DynoTable 指向 ExtendDB 的 endpoint：创建一个带 ExtendDB 端口和一次性凭证的离线（本地）配置文件，DynoTable 就会浏览、查询和编辑这些项 —— 只不过现在它们由你自己磁盘上的 PostgreSQL 支撑，而不是一个 JAR 的内存存储。

这就是传输协议兼容性的回报：SQL Workbench、可视化查询构建器和项编辑 全都能原封不动地针对 ExtendDB 工作，于是你无需编写 scan 脚本就能在你的自托管数据上获得一个 真正的 GUI。

有一个需要预先规划的注意点：ExtendDB 的 endpoint 是仅 HTTPS的，而 DynoTable 的离线配置文件 （像大多数 DynamoDB-Local 配置一样）面向的是一个环回 host:port。如果你的客户端或工具链需要 一个明文环回监听器，请在 ExtendDB 前面终结 TLS（或运行一个本地反向代理）并把 GUI 指向它 —— 无论哪种方式，线路上的协议仍然是 DynamoDB JSON。

坑

• 不要把 v0.1 当作生产级 DynamoDB。 伸缩、延迟和持久性是你 PostgreSQL 的，而非 AWS 的。在你 依赖它之前，请针对你的工作负载做基准测试。
• 没有 Global Tables / 跨区域复制。 如果你的设计依赖多区域多活，ExtendDB 不是那条路 —— 那是 托管服务的特性。
• 自己备份底层数据库。 没有托管的 PITR；一个被删除的 PostgreSQL 卷就没了。像对任何其他 PostgreSQL 一样接上 pg_dump / WAL 归档。
• 凭证是 ExtendDB 自己的，而非 AWS IAM。 别指望用 IAM 策略、角色或条件键来管控访问 —— 那套 授权模型不会延续过来。

后续步骤

• 先建模你的访问模式 —— 无论后端是 DynamoDB 还是 PostgreSQL-via-ExtendDB，同样的 单表设计纪律都适用。
• 用 DynamoDB 表达式构建器构建并检查你的读写，然后用 DynamoDB-JSON 转换器在纯 JSON 与传输格式之间转换测试数据。
• 当你准备好上手一个真实的 ExtendDB 实例时，连接 DynoTable，像浏览任何其他表一样 浏览它。