摘要：自 2012 年推出以来，许多团队转向使用 Amazon DynamoDB 的原因很容易理解。它易于上手，尤其是在您的组织已经扎根于 AWS 生态系统的情况下。它速度相对较快且可扩展，学习曲线较低。而且由于它是完全托管的，因此它消除了传统上需要保持数据库健康运
公司有时需要更低的延迟、更低的成本（尤其是在扩展时）或能够在其AWS以外的地方运行其应用程序。
译自 Why Teams Are Ditching DynamoDB，作者 Felipe Cardeneti Mendes; Guilherme Nogueira。
自 2012 年推出以来，许多团队转向使用 Amazon DynamoDB 的原因很容易理解。它易于上手，尤其是在您的组织已经扎根于 AWS 生态系统的情况下。它速度相对较快且可扩展，学习曲线较低。而且由于它是完全托管的，因此它消除了传统上需要保持数据库健康运行的操作工作和专业知识。
但随着时间的推移，缺点就会显现出来，尤其是在工作负载扩展和业务需求不断变化的情况下。团队有时需要更低的延迟、更低的成本（尤其是在扩展时）或能够在 AWS 之外的其他地方运行其应用程序。在这些情况下，ScyllaDB（提供与 DynamoDB 兼容的 API）通常被选为替代方案。
让我们探讨一下促使两个团队离开 DynamoDB 的挑战。
全球最大的媒体流媒体服务之一的用户状态和自定义团队多年来一直在使用 DynamoDB。当他们重新构建两个现有用例时，他们想知道是否该更换数据库了。这两个用例是：
暂停/恢复：如果用户正在观看节目并暂停，他们可以在任何设备、任何位置继续观看。观看状态：使用相同的数据，确定用户是否已观看该节目。这是一个简单的架构图：
每 30 秒，客户端都会发送带有节目更新播放头位置的心跳，然后将这些事件发送到数据库。边缘管道加载与用户位于同一区域的事件，而权威 (Auth) 管道组合公司服务的五个区域的所有事件。最后，必须获取数据并将其送回客户端以支持播放。请注意，团队希望保留 Auth 和 Edge 区域之间的分离，因此他们并没有寻找它们之间任何特定于数据库的复制。
满足这些条件后，团队还希望降低总体成本。
他们的后端工程师解释说：“我们现有的基础设施将数据分散在 DynamoDB 和 Elasticache 的各个集群中，因此我们真正想要的是一个简单的东西，可以将这些集群组合成一个成本低得多的系统。”
具体来说，他们需要一个具有以下功能的数据库：
多区域支持，因为该服务在五个主要地理区域都很流行。每秒处理超过 170K 次写入的能力。更新没有严格的服务级别协议 (SLA)，但系统需要根据事件时间戳执行条件更新。每秒处理超过 78K 次读取的能力，P99 延迟为 10 到 20 毫秒。用例只涉及简单的点查询；索引、分区和复杂的查询模式并不是主要关注点。约 10TB 的数据，并有增长空间。为什么从 DynamoDB 迁移？据他们的后端工程师说：“DynamoDB 可以完美地支持我们的技术要求。但是，鉴于我们的数据大小和高（写入密集型）吞吐量，继续使用 DynamoDB 就相当于把钱扔进火里。”
根据他们对写入性能和成本的要求，他们决定探索 ScyllaDB。为了进行概念验证，他们使用六个 AWS i4i 4xlarge 节点设置了一个 ScyllaDB Cloud 测试集群，并预加载了 30 亿条记录。他们运行了每秒 170K 次写入和 78K 次读取的组合负载。结果如何？“我们以零错误命中组合负载。我们的 P99 读取延迟 为 9 毫秒，写入延迟小于 1 毫秒。”
这些低延迟以及显着的成本节约（超过 50%）说服他们放弃 DynamoDB。除了更低的延迟和更低的成本外，团队还欣赏 ScyllaDB 的以下方面：
ScyllaDB 的性能导向设计（例如，基于 Seastar 框架构建，使用 C++，支持 NUMA，提供分片感知驱动程序）有助于团队减少维护时间和成本。增量压缩策略有助于他们显着减少写入放大。灵活的一致性级别和复制因子有助于他们支持单独的 Auth 和 Edge 管道。例如，Auth 使用仲裁一致性，而 Edge 由于数据重复和高吞吐量而使用“1”的一致性级别。他们的后端工程师总结道：“选择数据库很难。你需要考虑的不仅是功能，还有成本。无服务器并非万能药，尤其是在数据库领域。
“在我们的案例中，由于高吞吐量和低延迟的要求，DynamoDB无服务器并不是一个很好的选择。此外，不要低估硬件的作用。更好地利用硬件是降低成本同时提高性能的关键。”
Digital Turbine是移动广告技术领域的巨头，年收入达5亿美元，在其DynamoDB实施中面临着越来越大的挑战。虽然迁移的主要动机是在收购后标准化到Google Cloud Platform，但现有的DynamoDB解决方案一直都在造成大规模的性能和成本问题。
Digital Turbine平台架构副总裁Joseph Shorter解释说：“老实说，随着规模的扩大，成本可能会有点高。”
“我们发现了一些性能问题。我们进行了大量的读取操作——与DynamoDB的所有交互中，90%都是读取操作。通过所有这些操作，我们发现性能瓶颈要求我们比我们想要的规模更大，这增加了成本。”
Digital Turbine需要迁移尽可能快且低风险，这意味着应用程序重构要最小化。Shorter表示，主要关注点是：“如何在不彻底重构平台的情况下进行迁移，同时保持至少相同的性能和价值——并避免崩溃的情况？因为如果失败了，它会让我们的整个公司瘫痪。”
在评估了几个选项后，Digital Turbine迁移到ScyllaDB并立即取得了改进。迁移不到一个冲刺就完成了，结果超出了预期。
Shorter指出：“20%的成本差异——无论你谈论的是什么，这都是一个很大的数字。”“当你考虑我们进一步扩展的计划时，它就变得更加重要了。”
除了节省成本之外，他们发现自己“几乎没有使用ScyllaDB集群”，这表明即使在没有成比例的成本增加的情况下，也有更大的增长空间。
如果你的团队正在考虑从DynamoDB迁移，ScyllaDB可能是一个值得探索的选项。注册免费技术咨询以了解更多关于你的用例、SLA、技术要求以及你希望优化的内容。我们会告诉你ScyllaDB是否适合你，如果是，迁移可能涉及哪些应用程序更改、数据建模、基础设施等等。
来源：悟空学院
