Deno KV 与 Cloudflare Workers KV、Upstash Redis、AWS DynamoDB 和 Google Firestore 的对比
越来越多的开发者选择在边缘托管有状态的应用程序，原因有很多——更多存在点带来更高的可用性，由于物理位置更靠近用户而降低延迟，控制数据驻留以符合合规性要求等等。
我们托管的 Deno KV，现已公测，是我们的键值存储，具有读取已提交、顺序一致、多区域副本的特性，它构建于 FoundationDB 之上并内置于运行时中。您只需一行代码即可添加状态，而无需配置数据库或管理 API 密钥
const kv = await Deno.openKv();我们希望了解 Deno KV 在诸如 读/写延迟 和 定价 等维度以及诸如开发者体验等定性特征方面，与其他领先的分布式 Serverless 数据库相比表现如何
如果您希望我们评估其他 Serverless 数据库，请在 issues 中告知我们。
测量延迟的方法
我们构建了一个基准测试应用程序，用于测量五个 Serverless 数据库的实时读取和写入延迟。每个数据库都预先填充了 14,275 个键值对。每当应用程序收到来自浏览器的请求时，它都会启动五个 Serverless 函数（每个函数都对应于并尽可能与它正在测量的 Serverless 数据库位于同一位置），这些函数将执行以下操作：
- 执行一个简单的读取操作以预热实例（不测量）
- 从数据库中的 14,275 个总键值对中随机读取 10 条记录（任意 10 条记录的组合大小始终为 189KB），以尽可能避免缓存，并将其测量为
read延迟 - 修改这 10 条记录，然后并发地从数据库中删除旧的 10 条记录并将修改后的 10 条记录写入数据库，这被测量为
write延迟 - 将测量的延迟存储在主数据库中，从中计算百分位数数据并在前端显示
一致性和事务隔离级别
由于我们根据受欢迎程度选择了这些 Serverless 数据库，我们认识到并非所有读取和写入都是相同的，因为并非所有数据库都提供相同的一致性和事务隔离级别
| 数据库 | 一致性级别 | 事务隔离 |
|---|---|---|
| AWS DynamoDB | 最终一致性 | 读取已提交 |
| Upstash 区域级 | 最终一致性 | 无 |
| Google Firestore | 强一致性 | 可串行化 |
| Cloudflare KV | 最终一致性 | 无 |
| Deno KV | 强一致性 | 可串行化 |
隔离 read 和 write 延迟
为了确保我们仅测量读取和写入延迟，我们：
- 通过将所有逻辑置于与相应数据库位于同一位置的边缘函数中，最大限度地减少网络延迟（如果可能）
| 数据库 | Serverless 函数 | 区域 |
|---|---|---|
| AWS DynamoDB | AWS Lambda | 美国西部（俄勒冈）us-west-2 |
| Upstash 区域级 | AWS Lambda | 美国西部（俄勒冈）us-west-2 |
| Google Firestore | Google Cloud Function | 美国西部（洛杉矶）us-west1 |
| Cloudflare KV | Cloudflare Worker | 北美* |
| Deno KV | Deno Deploy Isolate** | 美国东部 us-east4-a |
- 通过在 Serverless 函数内测量读取和写入，排除浏览器到服务器之间的延迟
- 通过使用初始读取预热数据库连接，排除冷启动时间
- 记录读取和写入操作之前和之后的准确时间戳
考虑到所有这些因素，记录的读取和写入延迟应反映 Serverless 数据库完成其操作所需的时间。
结果
我们将在本文后面更详细地深入探讨性能，但以下是一目了然的结果。
读取延迟
写入延迟
性能和定价对比
在我们深入分析每个 Serverless 数据库之前，让我们先在性能和定价方面对它们进行比较。
性能
以下是我们应用程序收集的数据，样本大小为 10,000 个事务。请注意，Cloudflare KV 较长的缓存过期时间导致样本大小较小，为 5,712 个事务。
| 数据库 | 读取延迟，第 50 百分位数 (毫秒) | 读取延迟，第 90 百分位数 (毫秒) | 读取延迟，第 99 百分位数 (毫秒) |
|---|---|---|---|
| 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 百分位数 (毫秒) | 写入延迟，第 90 百分位数 (毫秒) | 写入延迟，第 99 百分位数 (毫秒) |
|---|---|---|---|
| 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，一个 Serverless 数据平台，通过 Upstash Redis 提供键值存储。
概览
- 原子操作: ✅
- 全局复制: ✅
- 位置: 8
- 通过 API 进行一致性控制: ❌
Upstash Redis 使用基于领导者的复制机制，只能提供最终一致性.
开发者体验
总的来说，使用 Upstash Redis 是一种“标准”的 Serverless 体验——您配置一个数据库，并通过 Redis 客户端库使用在您的环境中定义的唯一 host 和 password 变量连接到它。设置和连接 Serverless 数据库的体验既没有令人沮丧的地方，也没有特别令人愉快的地方。
AWS DynamoDB 全局表
AWS DynamoDB 全局表是亚马逊提供的完全托管的 Serverless 分布式数据库。
概览
- 原子操作: ✅
- 全局复制: ✅
- 位置: 17
- 通过 API 进行一致性控制: ✅
正如 AWS 所期望的那样，此 Serverless 数据库解决方案功能齐全，并为开发者提供了灵活配置的选项，可以细致到最小的细节。
开发者体验
处理任何 AWS 相关的事情都会遇到挫折和麻烦，这应该不足为奇。设置数据库只需点击几下并进行一些配置，没有什么特别之处。但是，当连接到 DynamoDB 时，最大的问题是遇到了过时且晦涩难懂的文档，以及使用 @aws-sdk/lib-dynamodb 并从维护者之一在 GitHub issue 回复中找到正确的路径…
在本地开发时，如果您想使用 DynamoDB 的本地实例进行测试和迭代，则需要执行另一个步骤，即下载并安装 “DynamoDB local”。很高兴知道可以使用本地版本的 DynamoDB 进行开发，但不幸的是，这是一个繁琐的多步骤设置过程。
Google Firestore
Google Firestore 是 Firebase 开发平台的一部分，是一个 Serverless 非关系型数据库。
概览
- 原子操作: ✅
- 全局复制: ✅
- 位置: 23
- 通过 API 进行一致性控制: ✅
与 AWS DynamoDB 类似，Google Firestore 功能丰富，并提供了大量的配置和灵活性，以满足广泛的开发者需求。
开发者体验
除了所有 Serverless 平台都具有的典型数据库配置步骤外，Google Firestore 比之前的解决方案稍微简单一些，因为每个项目只有一个 Firestore 数据库。这使得连接到数据库更加简单，因为您只需要 new Firestore()，而无需担心连接到“错误”的数据库。
除此之外，通过客户端库与 Firestore 交互也相对简单直接。
Cloudflare Workers KV
Cloudflare Workers KV 是一种低延迟的 Serverless 键值存储。
概览
- 原子操作: ❌
- 全局复制: ✅
- 位置: 300
- 通过 API 进行一致性控制: ❌
Cloudflare Workers KV 被设计为最终一致性，并使用全局缓存系统来为不经常更改的数据提供快速读取。它不提供原子性或一致性控制。对于这些，Cloudflare 建议使用 Durable Objects。
开发者体验
Cloudflare Workers KV 的配置和通过 Cloudflare Workers 网站进行配置非常标准。连接到 Cloudflare Workers KV 也相对简单，使用 KV 命名空间和配置文件 wrangler.toml 中的正确设置即可。
部署 Cloudflare Workers 有点棘手，因为我们需要捆绑函数才能使用 wrangler 将其部署到 Cloudflare。这在本地开发和生产环境之间进行测试和故障排除时增加了一层复杂性，因为捆绑和 sourcemapping 发生在部署时。
全局 Deno KV
Deno Deploy 上的 Deno KV 构建于 FoundationDB 之上，并内置于运行时中。
概览
- 原子操作: ✅
- 全局复制: ✅
- 位置: 3
- 通过 API 进行一致性控制: ✅
原子性是 Deno KV 的先决条件，因此它影响了我们设计 API 的方式。目前有三个区域，我们计划添加更多。
最后，您可以根据您的性能和数据完整性需求，选择您希望读取操作具有多强的一致性。
开发者体验
连接到 Deno KV 是最快和最容易的，因为它只需要一行代码。无需单独的步骤来配置数据库或管理 API 密钥。
最重要的是，本地环境和 Deno Deploy 上的生产环境是相同的，这使得测试和部署成为无缝体验。
下一步是什么？
我们基于 FoundationDB 构建的托管版本 Deno KV，不仅为持久数据提供了简单的零配置、符合 ACID 规范的 JavaScript API，而且还在其他 Serverless 数据库中提供了最佳性能。
在过去的几个月中，我们继续为 Deno KV 添加功能，例如从 Deno Deploy 外部远程连接到托管 Deno KV 实例的能力，持续备份到 S3 和 GCS，以及时间点恢复。Deno KV，以及Deno Queues、Deno Cron 和 访问 npm，意味着您可以更快地为 Web 构建，并最大限度地减少样板代码。
随着我们继续改进 Deno KV 以实现普遍可用的版本，我们欢迎您的反馈。
我们刚刚发布了 Deno KV Watch！构建实时应用程序（如通知、新闻源、多人游戏等）变得更加容易。