无服务器数据库即服务能实现什么 - 以及它们为何重要

我们可能会从技术优势入手：灵活扩展、更轻松地管理集群和节点，以及卸载复杂的资源分析。但我们知道，我们可以通过说 无服务器数据库即服务可防止超支 来吸引您的注意力。

选择合适的云数据库已经成为一个日益复杂的挑战。为了优化性能和成本，开发人员必须筛选各种实例类型，确定最佳内核数量，并考虑各种定价选项。

无服务器数据库即服务 (SDBaaS) 的出现为这些复杂问题提供了有希望的解决方案。SDBaaS 承诺简化管理、适应性扩展和经济高效的运营。特别是，它可以对实时用例产生积极的影响。

什么是无服务器数据库即服务 (SDBaaS)？

SDBaaS 指的是基于云的数据库服务，开发人员无需管理集群或节点。相反，开发人员可以通过简单的点击或 API 调用创建数据库。创建完成后，会收到用于数据库访问的端点（即表示为 URL 的 IP:Port），此后，数据库会根据应用程序的负载进行自我调整（吞吐量和内存/存储方面）——无需任何管理输入。

SDBaaS 提供商负责确保其基础设施的适当性。这与基于实例的 DBaaS 不同，在基于实例的 DBaaS 中，开发人员必须从几十甚至数百个选项列表中选择实例类型来创建集群以托管其数据集。

SDBaaS 定价通常由两个因素决定：数据集的大小和数据库操作的成本。一些供应商对读操作和写操作分别收费。

提供各种计费选项

基于配额的：根据您设置的数据量和操作速率收取费用。支持此方法的 SDBaaS 供应商通常提供 API 用于更改此设置，以便开发人员可以将其嵌入到他们的应用程序中。
基于用量的：根据实际使用的内存和执行的操作收取费用，通常以小时为单位计算。
有限用量：此选项将之前选项与有限用量定价相结合，以防止账单失控。通常可以使用简单的 API 调用更改限制。

什么时候使用 SDBaaS 比较合理？

许多因素会影响使用 SDBaaS 的决定，但以下是最重要的因素。

为您的工作负载选择合适的实例类型很困难。在基于实例的 DBaaS 中，开发人员必须从几十甚至数百个云实例中进行选择，而不知道服务的工作原理。一些基于实例的 DBaaS 供应商在其定价页面上没有透露可以在其服务实例中存储的数据集大小远小于他们实际提供的。结果是，开发人员选择了错误的实例，比他们计划的更早地进行扩展（或横向扩展），并且支付了比他们应该支付的更多的费用。下次，该开发人员可能会选择更大的实例来托管数据库，以确保万无一失，众所周知，过度配置的成本要高得多。

大多数开发人员不知道数据库工作负载实际需要多少内核，有人可能会说他们不应该需要知道。这是一个复杂的计算，大多数开发人员即使有数据库方面的经验也无法解决。无论该服务是基于开源项目，还是您以前在本地运行商业软件，在许多情况下，您会发现 DBaaS 供应商创建了该软件的分支。同样，这会导致花费更多的钱，并且比计划的更早地进行扩展（或横向扩展）。

使用基于实例服务的开发人员负责扩展并决定何时使用新实例。在某些情况下，他们被迫更改应用程序与数据库的交互方式，例如，从非集群模式迁移到集群模式数据库。选择托管云服务，但被迫在没有工具或知识的情况下操作它似乎很荒谬。

SDBaaS 确保灵活扩展（以应对起伏），无需管理任何东西，并且可以防止您向 DBaaS 供应商支付巨额费用。

适用于实时用例的 SDBaaS

构建实时应用程序不仅仅是基础设施成本。您还必须确保您选择的数据库能够以保证最终用户响应的延迟处理负载。

一般来说，在数据库中花费的每一毫秒，对于最终用户来说都是这个数字的 100 倍。

典型的实时应用程序必须在 100 毫秒内响应，最好更短，以满足每个用户请求，这意味着数据库应在不到 1 毫秒的时间内处理任何查询（读或写）。您的应用程序与该指标相比如何？

实时用例可以从无服务器 Redis 中获益匪浅

Redis 企业云从一开始就构建在无服务器架构之上，允许开发人员动态配置其数据（数据集大小加复制，如果需要）和吞吐量（每秒操作）限制，并且仅根据他们设置的内容收费。使用综合算法，我们为集群选择合适的实例类型，并将 Redis 分片分布开来，以便可以在平均不到 1 毫秒的时间内处理任何工作负载。

Redis 依赖于 DRAM，DRAM 比 SSD 贵得多。但是，SDBaaS 的大部分成本取决于执行的操作数量，而不是存储的数据量。这一点在实时场景中尤其重要，在实时场景中，一个数据库可以管理每秒数千甚至数百万个请求。由于 Redis 专为高速性能而设计，因此单个内核可以处理比其他数据库中数十甚至数百个内核更多的操作。这使得在 Redis 中执行的每个操作都具有极高的成本效益。

这并非学术练习。我们对读和更新性能进行了基准测试，方法是使用两个流行的 SDBaaS 解决方案（Amazon DynamoDB 和 Redis 企业云）运行具有固定数据集大小（50GB，加上复制）和多个吞吐量级别（以每秒操作衡量）的常用工作负载。我们发现了以下结果

读性能

serverless database read performance graph — 无服务器 DBaaS 读性能

更新性能

serverless database update performance graph — 无服务器 DBaaS 更新性能

无论我们测试哪种工作负载，Redis 企业云都能保持 0.5-0.6 毫秒的端到端延迟。

相比之下，即使每秒只有几个请求（未显示），DynamoDB 的性能也不超过 2.7 毫秒（对于读）和 4.4 毫秒（对于更新）。在每秒 18,000 个操作时，DynamoDB 的延迟增加到 6 毫秒（对于读操作）和接近 8 毫秒（对于更新操作），分别是 Redis 企业云的 12 倍和 16 倍。

最后，对于此工作负载，我们发现 DynamoDB 无法使用每个表的默认吞吐量配额扩展到每秒 18,783 个操作以上。