看看几个开发团队如何在实际提高数据库性能的同时显着降低数据库成本。
来自Pixabay的特色图片
对于那些负责数据密集型应用程序的人来说，降低数据库成本对于显着降低成本来说是轻而易举的事。如果您正在管理 TB 到 PB 级的数据，每秒进行数百万次读/写操作，那么无论您是否在本地使用开源，运行高可用性数据库并保持其正常运行的总成本都是巨大的、完全托管的数据库即服务或介于两者之间的任何东西。太多的团队在他们的数据库中投入了太多的精力。但是，从好的方面来看，这意味着通过重新考虑您的数据库策略可以获得很多好处。
为了获得一些灵感，我们来看看几个开发团队如何在实际提高数据库性能的同时显着降低数据库成本。
Comcast：通过更换 962 个节点 + 60 个缓存服务器节省 60% 的成本
“我们将 P99、P999 和 P9999 的延迟降低了 95%——从而在减少资本支出和运营支出的同时获得更快捷的界面。” — Comcast 高级工程总监 Phil Zimich
Comcast 是一家全球媒体和技术公司，拥有如下项主要业务：Comcast Cable，美国最大的面向住宅用户的视频、高速互联网和电话提供商之一；NBCUniversal 和 Sky，其英国电信部门。
挑战
Comcast 的 Xfinity 服务每天为 1500 万个家庭提供超过 20 亿次 API 调用（读取/写入）和超过 2 亿个新对象。在七年的时间里，该项目从支持 30,000 台设备扩展到超过 3100 万台设备。
它首先从 Oracle 开始，然后转移到 Apache Cassandra（通过 DataStax）。当 Cassandra 的长尾延迟被证明在公司快速增长的规模下无法接受时，团队开始探索新的选择。除了降低延迟外，他们还希望降低复杂性。为了向用户掩盖Cassandra 的延迟问题，他们在数据库前面放置了 60 个缓存服务器。保持这个缓存层与数据库一致是导致管理员头疼的主要问题。
解决方案
迁移到 ScyllaDB 使 Comcast 能够完全消除外部缓存层，提供一个简单的框架，其中数据服务直接连接到数据存储。结果是降低了复杂性并提高了性能，部署模型也更加简单。
结果
由于 ScyllaDB 的架构旨在充分利用现代基础架构，允许它向上扩展和向外扩展一样多，Comcast 能够用仅 78 个 ScyllaDB 节点替换 962 个 Cassandra 节点。
他们提高了整体可用性和性能，同时完全消除了 60 台缓存服务器。结果：延迟提高了 10 倍，能够以一小部分成本处理两倍以上的请求。这意味着比 Cassandra 运营成本节省 60%，每年可节省250 万美元的基础设施成本和员工开销。
Rakuten：节点减少 75%，基础设施成本降低 2.5 倍
“Cassandra 绝对具有水平可扩展性，但它的成本很高。大约两年前，我们开始在内部意识到 Cassandra 不是我们下一阶段增长的答案。” — Rakuten 工程经理 Hitesh Shah
Rakuten 允许其 15 亿会员在超过 3,500 家商店购物时赚取现金返还。商店向乐天支付佣金以派遣会员，乐天与会员分享该佣金。
挑战
Rakuten Catalog Platform 提供机器学习 (ML) 丰富的目录数据，以改进搜索、推荐和其他功能，从而为会员和业务合作伙伴提供卓越的用户体验。他们的数据处理引擎为其全球运营规范化、验证、转换和存储产品数据。
虽然企业期望该平台能够通过卓越的最终用户体验支持极端增长，但该团队正在与 Apache Cassandra 的不稳定、大规模性能不一致和维护开销作斗争。它面临着 JVM 问题、长时间的垃圾收集 (GC) 暂停和超时——此外，它还经历了一个艰难的过程，即单个慢速节点可能会导致整个集群崩溃。
解决方案
Rakuten 用 ScyllaDB 的六个节点替换了 Cassandra 的 24 个节点。ScyllaDB 现在处于其核心技术堆栈的核心位置，其中还涉及 Spark、Redis 和 Kafka。一旦数据经过 ML-enrichment，它就会存储在 ScyllaDB 中并发送给合作伙伴和内部客户。ScyllaDB 每天处理超过 2.5 亿个项目，每个节点每秒读取查询 (QPS) 为 10k-15k，写入 QPS 为每个节点 3k-5k。
增加 Rakuten 数据库成本节约的一项 ScyllaDB 特定功能是增量压缩策略 (ICS)。ICS 允许比标准 Cassandra 压缩策略更大的磁盘效用，因此相同数量的总数据需要更少的硬件。使用传统的压缩策略，用户需要预留一半的总存储空间用于压缩。借助 ICS，Rakuten 可以将其总存储空间的 85% 或更多用于数据，从而实现更高的硬件利用率。
结果
Rakuten 现在可以将项目发布速度提高五倍，从而加快目录更改的周转速度。这对于黑色星期五等购物高峰期尤为重要。可预测的低延迟使公司能够承诺令人印象深刻的内部和外部 SLA。此外，在节点减少 4 倍之后，该公司将基础设施成本降低了 2.5 倍。
Expedia：通过替换 Redis + Cassandra 节省 35% 的成本
“我们不再需要担心‘stop-the-world’垃圾回收暂停。此外，我们能够在每个节点存储更多数据并实现每个节点的更高吞吐量，从而为公司节省大量资金。” — Singaram Ragunathan，Expedia Group 的云数据架构师
Expedia是全球领先的提供全方位服务的在线旅游品牌之一，可帮助旅行者轻松规划和预订他们的整个旅程，提供多种度假套餐、航班、酒店、度假租赁、汽车租赁、游轮、活动、景点和服务。
挑战
Expedia 的核心应用程序之一提供有关地理实体及其之间关系的信息。它聚合来自多个系统的数据，如酒店位置信息、第三方数据等。这个丰富的地理数据集使用简单的 REST API 实现不同类型的数据搜索，目标是个位数毫秒 P99 读取响应时间。
该团队使用多层方法，将 Redis 作为第一个缓存层，将 Cassandra 作为第二个持久数据存储层，但他们对 Cassandra 的技术挑战越来越感到沮丧。管理垃圾收集并确保它针对手头的工作负载进行适当调整需要大量时间、精力和专业知识。此外，突发流量和工作负载峰值缩短了 P99 响应时间，需要缓冲节点来处理峰值容量，这推高了基础设施成本。
解决方案
该团队在未修改其数据模型或应用程序驱动程序的情况下从 Cassandra 迁移到 ScyllaDB。正如 Expedia Group 的云数据架构师 Singaram Ragunathan 所说：“从 Apache Cassandra 代码库，开发人员可以毫不费力地切换到 ScyllaDB。不需要任何数据模型更改。并且 ScyllaDB 驱动程序是兼容的，并且是与 Cassandra 驱动程序依赖关系的换入替代品。通过对配置 Apache Cassandra 集群的自动化框架进行一些调整，我们能够配置 ScyllaDB 集群。”
结果
使用 Cassandra 时，P99 读取延迟以前是尖峰的，每天从 20 到 80 毫秒不等。使用 ScyllaDB，它始终在 5 毫秒左右。ScyllaDB 的吞吐量接近 Cassandra 的三倍。此外，ScyllaDB 还节省了 35% 的基础设施成本。
iFood：从 DynamoDB 转移到扩展，节省 9 倍的成本
“这里真正相关的一件事是 iFood 的增长速度。在不到两年的时间里，我们从每月 100 万个订单增加到每月 2000 万个。” — Thales Biancalana，iFood 后端开发人员
iFood 是拉丁美洲最大的食品配送公司。它最初是一家巴西初创公司，后来发展成为明显的领导者，市场份额达到 86%。在巴西成为“送餐”的代名词后，iFood 将业务扩展到哥伦比亚和墨西哥。
挑战
简短的回答：大规模在线订购，使用 PostgreSQL 和 DynamoDB。
每个在线订单代表其数据库中的大约五个事件，每月产生超过 1 亿个事件。这些事件通过 iFood 平台发送到餐厅，该平台使用简单通知服务 (SNS) 和简单队列服务 (SQS)。由于巴西的互联网连接不稳定，它依赖于基于 HTTP 的轮询服务，该服务每 30 秒为每台设备触发一次。这些民意调查中的每一个都会调用数据库查询。
在公司每月订单量达到 1000 万并经历多次 PostgreSQL 故障后，该团队决定探索其他选择。他们迁移到 NoSQL 并为 iFood 的连接轮询服务选择了 DynamoDB。他们很快发现 DynamoDB 的自动缩放对于他们的尖峰流量模式来说太慢了。iFood 的日间流量在午餐和晚餐时间自然激增。缓慢的自动缩放意味着他们无法满足每天的需求爆发，除非他们留下高的最低吞吐量，这是昂贵的）或自己管理缩放，这是他们试图通过支付完全托管服务来避免的工作。
解决方案
iFood 将其连接轮询服务转换为 ScyllaDB Cloud。从 PostgreSQL 迁移到 DynamoDB 时，该团队能够保留他们构建的相同数据模型。尽管 DynamoDB 使用基于文档的 JSON 表示法，而 ScyllaDB 使用类似 SQL 的 Cassandra 查询语言 (CQL)，但它们可以在两者之间使用相同的查询策略。
结果
iFood 的 ScyllaDB 部署轻松满足了其吞吐量要求，并使公司能够实现扩展以支持 500,000 个连接的商家，每个商家使用一台设备的中期目标。此外，迁移到 ScyllaDB 后，Connection-Polling 服务的数据库成本从 54,000 美元减少到 6,000 美元——节省了 9 倍。
总结
这些例子只是一个开始。有很多方法可以减少数据库支出：
- 使用更强大的硬件和旨在榨取其中每一盎司能量的数据库来提高您的性价比，例如 ScyllaDB 的高效分片每核架构和自定义压缩策略以实现最大存储利用率。
- 通过简化您的基础架构（消除外部缓存、减小集群大小或移动到需要较少调整和维护的数据库）来降低管理成本。
- 利用工作负载优先级排序等技术在同一集群上运行 OLTP（事务处理）和 OLAP（分析）工作负载，而不会牺牲延迟或吞吐量。
- 考虑数据库即服务选项，让您的云支出具有灵活性，而不是将您锁定在一个供应商的生态系统中。
- 转向定价更符合您的工作负载、数据集大小和预算的 DBaaS 提供商（使用此DBaaS 定价计算器比较多个供应商的价格）。
如果您想了解这些选项中的哪些选项（如果有的话）可能适合您团队的特定工作负载、用例和生态系统，ScyllaDB 的架构师将很乐意提供技术咨询。
ScyllaDB 是需要高性能和低延迟的数据密集型应用程序的数据库。它利用现代基础设施不断增长的计算能力——消除随着数据增长而扩展的障碍。改变game规则的公司使用 ScyllaDB 来应对最棘手的数据库挑战。
原文标题：Cutting Database Costs: Comcast, Rakuten, Expedia and iFood
原文作者：Cynthia Dunlop
原文链接：https://thenewstack.io/cutting-database-costs-comcast-rakuten-expedia-and-ifood/
