Deno KV 对比 Cloudflare Workers KV、Upstash Redis、AWS DynamoDB 和 Google Firestore
越来越多的开发者选择在边缘托管有状态应用程序，原因多种多样——更高的可用性（更多存在点）、更低的延迟（物理上更接近用户）、数据驻留控制以符合合规性等。
我们托管的 Deno KV，现已开放测试版，是一个支持读已提交、顺序一致性、多区域副本的键值存储，它基于 FoundationDB 构建并直接集成到运行时中。你只需一行代码即可添加状态，无需配置数据库或管理 API 密钥。
const kv = await Deno.openKv();我们希望了解 Deno KV 在读/写延迟和定价等维度，以及开发者体验等定性特征方面，与其它领先的分布式无服务器数据库相比表现如何。
如果你希望我们评估其他无服务器数据库，请在 issues 中告诉我们。
延迟测量方法
我们构建了一个基准测试应用程序，以测量这五种无服务器数据库的实时读写延迟。每个数据库都预置了 14,275 个键值对。每当应用程序收到来自浏览器的请求时，它会启动五个无服务器函数（每个函数尽可能与所测量的无服务器数据库对应并位于同一位置），这些函数将进行以下操作：
- 执行一个简单的读取操作以预热实例（不计入测量）
- 从数据库的 14,275 个键值对中随机读取 10 条记录（任意 10 条记录组合的大小始终为 189KB），以尽可能避免缓存，并将其测量为
读取延迟 - 修改这 10 条记录，然后同时从数据库中删除旧的 10 条记录并写入修改后的 10 条记录，这被测量为
写入延迟 - 将测量的延迟存储在主数据库中，并从中计算并显示前端的百分位数据
一致性和事务隔离级别
由于我们是根据流行度选择这些无服务器数据库的，我们认识到并非所有读写操作都具有同等性，因为并非所有数据库都提供相同的一致性和事务隔离级别。
| 数据库 | 一致性级别 | 事务隔离 |
|---|---|---|
| AWS DynamoDB | 最终一致性 | 读已提交 |
| Upstash 区域 | 最终一致性 | 无 |
| Google Firestore | 强一致性 | 可串行化 |
| Cloudflare KV | 最终一致性 | 无 |
| Deno KV | 强一致性 | 可串行化 |
隔离读取和写入延迟
为了确保我们只测量读写延迟，我们采取了以下措施：
- 通过将所有逻辑放在与相应数据库（如果可能）共置的边缘函数中，最大限度地减少了网络延迟
| 数据库 | 无服务器函数 | 区域 |
|---|---|---|
| AWS DynamoDB | AWS Lambda | us-west-2 |
| Upstash 区域 | AWS Lambda | us-west-2 |
| Google Firestore | Google Cloud 函数 | us-west1 |
| Cloudflare KV | Cloudflare Worker | NA* |
| Deno KV | Deno Deploy 隔离环境** | us-east4-a |
- 通过测量无服务器函数内部的读写操作，排除了浏览器到服务器之间的延迟
- 通过初始读取操作预热数据库连接，排除了冷启动时间
- 在读写操作之前和之后记录时间戳
综合以上考虑，所记录的读写延迟应反映无服务器数据库完成其操作所需的时间。
结果
我们将在本文后面详细探讨性能，但这里先快速浏览一下结果。
读取延迟
写入延迟
性能和定价比较
在我们深入分析每个无服务器数据库之前，让我们先从性能和定价方面进行比较。
性能
以下是我们应用程序收集的数据，样本量为 10,000 笔事务。请注意，Cloudflare KV 较长的缓存过期时间导致其样本量较小，为 5,712 笔事务。
| 数据库 | 读取延迟，第 50 百分位数 (ms) | 读取延迟，第 90 百分位数 (ms) | 读取延迟，第 99 百分位数 (ms) |
|---|---|---|---|
| AWS DynamoDB | 298 | 480 | 700 |
| Upstash 区域 | 19 | 35 | 139 |
| Google Firestore | 200 | 299 | 699 |
| Cloudflare KV* | 341 | 426 | 742 |
| Deno KV | 22 | 50 | 90 |
Upstash Redis 表现最佳，Deno KV 紧随其后，DynamoDB 和 Firestore 则表现滞后。Cloudflare KV 表现最差，因为它采用了大量缓存和最终一致性模型，不适合测量频繁读写引起的传播变化。事实上，其文档明确指出，由于缓存超时，更改可能需要长达 60 秒才能可见。
| 数据库 | 写入延迟，第 50 百分位数 (ms) | 写入延迟，第 90 百分位数 (ms) | 写入延迟，第 99 百分位数 (ms) |
|---|---|---|---|
| AWS DynamoDB | 199 | 377 | 560 |
| Upstash 区域 | 86 | 120 | 279 |
| Google Firestore | 275 | 475 | 826 |
| Cloudflare KV | 538 | 612 | 866 |
| Deno KV | 62 | 96 | 166 |
Deno KV 在写入延迟方面表现领先，Upstash Redis 紧随其后，接着是 AWS DynamoDB、Google Firestore 和 Cloudflare KV。
定价
| 数据库 | 读取（百万次） | 写入（百万次） | 存储（GiB/月） | 网络（GiB） |
|---|---|---|---|---|
| AWS DynamoDB | $0.25 (4KB 单位) | $1.25 (1KB 单位) | $0.25 | - |
| Upstash 区域 | $2 | $2 | $0.25 | $0.03 |
| Upstash 全球* | $4 | $4 x N | $0.25 x N | $0.10 |
| Google Firestore** | $0.3 | $0.9 | $0.15 | - |
| Cloudflare KV | $0.5 | $5 | $0.5 | $0 |
| Deno KV | $1 (4KB 单位) | $2.5 (1KB 单位) | $0.5 | - |
在读写方面，AWS DynamoDB 和 Google Firestore 最具竞争力，而 Upstash 则最昂贵（尤其是全球版本）。Cloudflare 的读取价格相对有竞争力，但其写入价格最昂贵，每百万次写入为 5 美元。Deno KV 居中，每百万次读取 1 美元，每百万次写入 2.5 美元。
在存储方面，Google Firestore 最便宜，每月每 GiB 0.18 美元。而 Cloudflare 和 Deno 则较高，每月每 GiB 0.5 美元。
Upstash Redis
Upstash 是一个无服务器数据平台，通过 Upstash Redis 提供键值存储。
概览
- 原子操作: ✅
- 全球复制: ✅
- 区域数量: 8
- 通过 API 控制一致性: ❌
Upstash Redis 使用基于领导者的复制机制，只能提供最终一致性。.
开发者体验
总的来说，使用 Upstash Redis 是一种“标准”的无服务器体验——你配置一个数据库，并通过 Redis 客户端库连接到它，其中独特的host和password变量在你的环境中定义。设置和连接无服务器数据库的体验既没有令人沮丧之处，也没有特别令人欣喜之处。
AWS DynamoDB Global Tables
AWS DynamoDB Global Tables 是亚马逊提供的一款完全托管的无服务器分布式数据库。
概览
- 原子操作: ✅
- 全球复制: ✅
- 区域数量: 17
- 通过 API 控制一致性: ✅
正如 AWS 所预期的那样，这款无服务器数据库解决方案功能齐全，为开发者提供了细致入微的配置灵活性。
开发者体验
毋庸置疑，处理任何 AWS 相关事务都会遇到挫折和麻烦。设置数据库只需几次点击和一些配置，没有什么特别之处。然而，在连接 DynamoDB 时，最大的问题是遇到过时且晦涩的 @aws-sdk/lib-dynamodb 文档，并且需要通过维护者之一在 GitHub issue 中的回复才能找到正确的路径……
在本地开发时，如果你想使用 DynamoDB 的本地实例进行测试和迭代，你还需要额外一步，即下载并安装“DynamoDB local”。虽然可以针对本地版本的 DynamoDB 进行开发是件好事，但遗憾的是，其设置过程繁琐且步骤众多。
Google Firestore
Google Firestore 作为 Firebase 开发平台的一部分，是一个无服务器的非关系型数据库。
概览
- 原子操作: ✅
- 全球复制: ✅
- 区域数量: 23
- 通过 API 控制一致性: ✅
与 AWS DynamoDB 类似，Google Firestore 功能丰富，提供大量配置和灵活性，可满足广泛的开发者需求。
开发者体验
除了所有无服务器平台都具备的典型数据库配置步骤外，Google Firestore 比之前的解决方案更简单一些，因为它每个项目只对应一个 Firestore 数据库。这使得连接数据库更简单，因为你只需使用 new Firestore()，无需担心连接到“错误”的数据库。
除此之外，通过客户端库与 Firestore 进行交互也相对简单。
Cloudflare Workers KV
Cloudflare Workers KV 是一种低延迟的无服务器键值存储。
概览
- 原子操作: ❌
- 全球复制: ✅
- 区域数量: 300
- 通过 API 控制一致性: ❌
Cloudflare Workers KV 被设计为最终一致性，并使用全球缓存系统来提供对不常变化数据的快速读取。它不提供原子性或一致性控制。对于这些需求，Cloudflare 推荐使用Durable Objects。
开发者体验
通过 Cloudflare Workers 网站配置和设置 Cloudflare Workers KV 非常标准。使用 KV 命名空间和 wrangler.toml 配置文件中的正确设置，连接到 Cloudflare Workers KV 也相对简单。
部署 Cloudflare Workers 有些棘手，因为我们需要捆绑函数才能使用 wrangler 将其部署到 Cloudflare。由于捆绑和源映射发生在部署时，这增加了本地开发环境和生产环境之间测试和故障排除的复杂性。
全球 Deno KV
Deno Deploy 上的 Deno KV 基于 FoundationDB 构建，并直接集成到运行时中。
概览
- 原子操作: ✅
- 全球复制: ✅
- 区域数量: 3
- 通过 API 控制一致性: ✅
原子性是 Deno KV 的一个先决条件，因此它影响了我们 API 的设计方式。目前有三个区域，我们计划增加更多。
最后，你可以根据你的性能和数据完整性需求，选择读取的一致性级别。
开发者体验
连接 Deno KV 是最快、最简单的，只需一行代码。没有单独的步骤来配置或设置数据库，也无需管理 API 密钥。
最重要的是，Deno Deploy 上的本地环境和生产环境是相同的，这使得测试和部署体验非常顺畅。
接下来是什么？
我们基于 FoundationDB 构建的托管版 Deno KV 不仅提供了简单、零配置、符合 ACID 标准的 JavaScript API 用于持久化数据，而且在其他无服务器数据库中也提供了最佳性能。
在过去的几个月中，我们持续为 Deno KV 添加功能，例如远程连接到托管 Deno KV 实例的能力、持续备份到 S3 和 GCS，以及时间点恢复。Deno KV，以及Deno Queues、Deno Cron 和对 npm 的访问，意味着你可以更快地构建 Web 应用，且只需最少量的样板代码。
随着我们不断改进 Deno KV 以推出正式版本，我们欢迎您的反馈。
我们刚刚发布了Deno KV Watch！构建通知、新闻源、多人游戏等实时应用程序变得更加容易。