视频
13 年后 – Redis 需要新的架构吗？
了解更多
Redis 8 来了 — 并且它是开源的
了解更多
我们可以先谈技术优势：灵活的扩展、更容易管理集群和节点，以及卸载复杂的资源分析。但我们知道，通过说 无服务器数据库即服务可以防止过度支出 ，我们可以吸引您的注意。
选择合适的云数据库已成为一个日益复杂的挑战。为了优化性能和成本，开发人员必须筛选各种实例类型，确定最佳的核心数量，并考虑多种定价选项。
无服务器数据库即服务 (SDBaaS) 的出现为解决这些复杂性提供了一个有希望的方案。SDBaaS 承诺简化的管理、灵活的扩展和成本效益高的操作。特别是，它可以在实时用例中产生积极的结果。
SDBaaS 指的是基于云的数据库服务，它消除了开发人员管理集群或节点的需要。 相反，开发人员只需简单点击或调用 API 即可创建数据库。创建后，会收到一个用于访问数据库的端点（即表示为 URL 的 IP:Port），此后，数据库会自行调整（吞吐量和内存/存储方面），以适应应用程序的负载——无需任何管理输入。
SDBaaS 提供商负责确保其基础设施是合适的。这与基于实例的 DBaaS 不同，在基于实例的 DBaaS 中，开发人员必须从几十甚至数百个选项列表中选择一个实例类型来创建集群以托管他们的数据集。
SDBaaS 定价通常由两个因素决定：数据集的大小和数据库操作的成本。一些供应商对读写操作分开收费。
有多种计费选项
许多因素会影响使用 SDBaaS 的决定，但以下是最关键的几个。
为您的工作负载选择合适的实例类型很困难。在基于实例的 DBaaS 中，开发人员必须在数十甚至数百个云实例中进行选择，而无需了解服务的工作原理。一些基于实例的 DBaaS 供应商在其定价页面上未能披露其服务实例中可存储的数据集大小远小于他们实际提供的容量。 结果是，开发人员选择了错误的实例，比计划更早地纵向扩展（或横向扩展），并支付了超出应付的费用。下次，为了安全起见，该开发人员可能会选择更大的实例来托管数据库，而众所周知，过度配置的成本要高得多。
大多数开发人员不知道数据库工作负载实际需要多少核心，可以说他们也不应该需要知道。这个计算非常复杂，即使开发人员之前有过数据库经验，也几乎没有可能解决。无论服务是基于开源项目还是您过去在本地运行商业软件，在许多情况下，您会发现 DBaaS 供应商创建了该软件的分支。同样，这会导致花费更多资金并比计划更早地进行 纵向扩展 （或横向扩展）。
使用基于实例服务的开发人员负责扩展并决定何时使用新实例。在某些情况下，他们被迫改变应用程序与数据库的工作方式，例如，从非集群模式迁移到集群模式数据库时。选择托管云服务却被迫在没有工具或知识的情况下操作它似乎很荒谬。
SDBaaS 确保灵活的扩展（应对峰谷变化），消除了任何管理需求，并防止您向 DBaaS 供应商支付巨额费用。
构建实时应用程序不仅仅是基础设施成本的问题。您还必须确保所选的数据库能够以保证最终用户响应速度的延迟来处理负载。
根据经验法则，在数据库中花费的每一毫秒，对于最终用户来说就是一百倍的时间。
典型的 实时应用程序必须在 100 毫秒内（最好更短）响应每个用户请求，这意味着数据库应该在一毫秒内处理任何查询（读或写）。您的应用程序符合这个指标吗？
Redis Enterprise Cloud 从一开始就构建在无服务器架构之上，允许开发人员动态配置他们的数据（数据集大小加上所需的副本）和吞吐量（每秒操作数）限制，并仅按他们设置的量计费。使用一个全面的算法，我们为集群选择合适的实例类型，并分布 Redis 分片，以便任何工作负载都能以平均低于一毫秒的速度处理。
Redis 依赖 DRAM，它比 SSD 贵得多。然而，SDBaaS 的大部分成本取决于执行的操作数量，而不是存储的数据量。 这一点在实时场景中尤为重要，其中一个数据库可以每秒处理数千甚至数百万个请求。由于 Redis 专为高速性能而设计，单个核心可以处理比其他数据库中几十甚至几百个核心更多的操作。这使得在 Redis 中执行的每个操作都具有极高的成本效益。
这不是一个学术练习。我们通过在两种流行的 SDBaaS 解决方案：Amazon DynamoDB 和 Redis Enterprise Cloud 上运行具有固定数据集大小 50GB（加上复制）和多个吞吐量级别（按每秒操作数衡量）的常见工作负载，对 读取 和 更新 性能进行了基准测试。我们发现了以下结果
读取 性能
更新 性能
无论我们测试了哪种工作负载，Redis Enterprise Cloud 都保持了 0.5-0.6 毫秒的端到端延迟。
相比之下，DynamoDB 的性能不快于 2.7 毫秒（对于 读取 ）和 4.4 毫秒（对于 更新 ），即使每秒只有少量请求（未显示）。在每秒 18,000 次操作时，DynamoDB 对 读取 操作的延迟增加到 6 毫秒，对 更新 操作的延迟接近 8 毫秒，分别比 Redis Enterprise Cloud 慢 12 倍和 16 倍。
最后，对于此工作负载，我们发现使用 每表默认吞吐量配额 ，DynamoDB 无法扩展到每秒 18,783 次操作以上。
我们的下一步是创建一个成本/性能图表，比较不同每秒请求级别下每种 SDBaaS 解决方案的成本，以及 Redis Enterprise Cloud 相对于 DynamoDB 的性能优势（读取 和 更新 的平均结果）。
结果不言自明
当达到每秒 1,000 次请求时，Redis Enterprise Cloud 已经比 DynamoDB 便宜 15%（并且快 6.44 倍）。在每秒 18,000 次请求时，Redis Enterprise Cloud 的成本不到 DynamoDB 的 2%，并且速度快一个数量级以上。
显然，我们 Redis 坚信 SDBaaS Redis 是实时应用程序的理想选择。它易于管理、灵活、可扩展且成本效益极高。操作成本远比数据存储成本更重要，并且 Redis 中的每次操作都非常便宜。此外，它确保了最终用户的实时体验，因为任何数据库操作都可以在不到 1 毫秒 内执行。
如果您愿意，可以自己进行测试，看看我们的性能数据是否与您的匹配。
免费获取无服务器 Redis （如果您还没有的话）。
