Deno KV 与 Cloudflare Workers KV、Upstash Redis、AWS DynamoDB 和 Google Firestore 的比较

越来越多的开发者选择在边缘托管有状态应用程序，原因有很多——更高的可用性，更多接入点，由于靠近用户而产生的更低延迟，为了合规性而控制数据驻留，等等。

我们托管的 Deno KV，现已开放测试，是我们的键值存储，具有读提交、顺序一致、多区域副本，它基于 FoundationDB 构建，并直接集成到运行时。您可以添加状态，而无需配置数据库或在只有一行代码的情况下处理 API 密钥。

const kv = await Deno.openKv();

我们想看看 Deno KV 与其他领先的分布式无服务器数据库在 读/写延迟 和 定价 等方面如何比较，以及开发者体验等定性特征。

• Upstash Redis
• AWS Dynamo DB 全球表
• Google Firestore
• Cloudflare Workers KV
• 全球 Deno KV

如果您希望我们评估其他无服务器数据库，请在问题中告诉我们。

测量延迟的方法

我们构建了 一个基准测试应用程序 来测量五个无服务器数据库的实时读写延迟。每个数据库都填充了 14,275 个键值对。只要应用程序从浏览器接收到请求，它就会启动五个无服务器函数（每个函数对应并尽可能与它正在测量的无服务器数据库位于同一个位置），这些函数将

• 执行一个简单的读操作以预热实例（未测量）。
• 从数据库中读取 14,275 个键值对中的随机 10 条记录（任意 10 条记录的组合大小始终为 189KB）以尽可能避免缓存，并将其测量为read延迟。
• 更改 10 条记录，然后同时从数据库中删除旧的 10 条记录，并写入更改后的 10 条记录，这将被测量为write延迟。
• 将测量的延迟存储在主数据库中，从中计算和显示百分位数据。

一致性和事务隔离级别

由于我们根据流行度选择了这些无服务器数据库，我们认识到并非所有读写都是相等的，因为并非所有数据库都提供相同的一致性和事务隔离级别。

隔离read和write延迟

为了确保我们只测量读写延迟，我们

• 通过将所有逻辑放在与相应数据库位于同一个位置的边缘函数中（如果可能）来最大限度地减少网络延迟。

• 通过在无服务器函数内测量读写来排除浏览器到服务器之间的延迟。
• 通过使用初始读操作预热数据库连接来排除冷启动时间。
• 在读写之前和之后记录时间戳。

考虑到所有这些因素，记录的读写延迟应反映无服务器数据库完成其操作所需的时间。

结果

我们将在本文后面更详细地介绍性能，但以下是结果一览。

查看应用程序或查看源代码。

比较性能和定价

在我们深入分析每个无服务器数据库之前，让我们比较一下它们的性能和定价。

性能

以下是我们应用程序从 10,000 个事务中收集的数据。请注意，Cloudflare KV 的更长的缓存过期时间导致了 5,712 个事务的较小样本量。

Upstash Redis 表现最佳，Deno KV 位居第二，DynamoDB 和 Firestore 则落后。Cloudflare KV 表现最差，因为它的缓存很重，并且采用了最终一致性模型，不太适合测量频繁读写时传播的更改。事实上，他们的文档明确指出，由于缓存超时，更改可能需要长达 60 秒才能可见。

Deno KV 在写入延迟方面领先，Upstash Redis 位居第二，然后是 AWS DynamoDB、Google Firestore 和 Cloudflare KV。

定价

在读写方面，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 全球表

AWS DynamoDB 全球表 是亚马逊提供的完全托管的无服务器分布式数据库。

概述

• 原子操作：✅
• 全局复制：✅
• 位置：17
• 通过 API 控制一致性：✅

正如预期的那样，来自 AWS 的这个无服务器数据库解决方案功能齐全，并为开发者提供了灵活的配置方式，可以将配置细化到最小的细节。

开发者体验

处理任何 AWS 相关内容都会遇到挫折和头疼，这一点应该不足为奇。设置数据库只需要点击几下鼠标并进行一些配置，没什么特别的。但是，在连接到 DynamoDB 时，最大的问题是遇到了 @aws-sdk/lib-dynamodb 的陈旧和晦涩的文档，并试图从维护人员的 GitHub 问题回复 中找到正确的路径…

在本地开发时，如果你想使用本地实例的 DynamoDB 进行测试和迭代，你需要再做一步，就是下载并安装 “DynamoDB 本地版”。了解到可以针对本地版本的 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 建议使用 持久对象。

开发者体验

Cloudflare Workers KV 的配置和设置通过 Cloudflare Workers 网站进行，非常标准。连接到 Cloudflare Workers KV 也相对简单，使用 KV 命名空间和配置文件 wrangler.toml 中的正确设置。

部署 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 Deploy 外部连接到托管的 Deno KV 实例、持续备份到 S3 和 GCS 以及 时间点恢复。Deno KV 与 Deno Queues、Deno Cron 和 对 npm 的访问 相结合，意味着你可以使用最少的样板代码更快地为网络构建应用程序。

随着我们继续改进 Deno KV 并努力使其正式发布，我们欢迎您的反馈。

我们刚刚发布了 Deno KV Watch！构建实时应用程序（如通知、新闻提要、多人游戏等）变得更加容易。