降本增效成架构师必备技能：酷家乐如何实现全年数据库成本零增长

作者 | 贾驰千、余智平酷家乐中间件团队研发工程师

随着云数据库数量以及成本的迅速增加，数据库成本管理和优化成为了企业所关注的方向。酷家乐针对云数据库做了一系列的深度成本优化动作，收益颇丰。本文为详细介绍~ 供你参考。

一、背景摘要

近年来，随着上云的普遍化，降本成为了备受关注的热门话题。越来越多的企业开始重视云资源的成本优化，FinOps更是横空出世，得到了众多企业的拥抱。

作为全球领先的云设计软件平台和 SaaS 服务提供商，（群核科技）酷家乐的产品都构建在公有云之上，截止目前，我们使用了上百个云数据库实例（全托管模式），涵盖了不同的类型（SQL 和 NoSQL）。面对数量以及成本的逐年迅速增加，数据库成本管理和优化成为了我们的一个关注方向。

众所周知，K8S已经成为了服务成本优化领域的一大技术利器，然而在数据库领域，由于涉及到状态，K8S并不能如此“得心应手”，不易如法炮制。本文从数据（架构）角度，结合酷家乐2022年数据库成本优化工作的实践，通过讨论主要场景与落地案例，总结和归纳针对云数据库的深度成本优化的手段和方法。这些方案具有较强的通用性以及落地性，适用于不同种类的数据库，包括SQL和NoSQL等。

另外，云数据库成本优化，需要架构师基于业务特性，通过业务架构优化、数据架构优化、先进软硬件技术等不同手段，达成端到端的整体优化（保证服务质量不明显降低的前提下），从而实现长期可持续的降本增效。

二、经典案例和优化手段介绍

2.1 优化存储架构，减少数据副本

2.1.1 降低副本数或冗余量

场景：

多副本容灾架构

为了保证数据的可靠性，现代的数据库架构一般都设有多副本机制。副本数大于等于 2。

手段：

针对多副本（大于 2）的数据库架构，在满足业务可用性的前提下，通过降低副本数的方式，最终减少机器数量。

案例 1：

以HBase为例，数据本身存储在HDFS上，HDFS通过三副本机制保证数据的可靠性。为了保证HBase的RTO，我们核心在线业务都配备了双集群主备架构，这样导致了一份数据会存在六个副本，造成了较大的空间冗余（浪费）。

例如我们的其中一个核心业务单副本140T数据，六副本840T，磁盘使用率不断上涨，造成巨大成本压力。我们通过调整副本数量为四副本（从原来的6副本），有效降低了280T数据的磁盘使用空间

HBase 主备集群减少副本数

案例 2：

针对数据有历史存档或者数据可再生的业务场景，可以采用业务降级等方式，减少集群的副本数量或者灾备节点数。

某业务结合数据有历史存档的特点，HBase 单集群出现故障时，降级到历史存档数据，最终释放了一个 HBase 灾备集群，节约 50% 成本。HBase 降级历史数据减少副本数某业务在HBase上存储的是显示层数据，可以根据其他存储数据库上的元数据重新生成。因此，结合数据可再生的特点，在HBase单集群出现故障时，可以降级为通过请求元数据重新生成（RT会升高），最终释放了一个HBase灾备集群，节约50%成本。

HBase 可再生数据减少副本数

2.1.2 利用索引表（ Index Table ）减少冗余

场景：

分库分表架构

在分库分表架构场景中，为了方便查询数据，可能会把一份数据按照不同维度(分片键)进行完整的冗余存储，如果保存一份主数据，不同维度的只保存片键映射关系，那么冗余存储就可以减少，节省一定的存储成本。

手段

保存一份主数据，不同维度的只保存索引映射关系（Index Table pattern）。

注意，会增加一次查询操作，存在批量查询的业务此方式慎用。

案例：

某业务采用分库分表架构，按2个分片键（designid、projectid）拆分，各自存储了全量数据，造成存储资源浪费。而两个分片键存在映射关系，且projectid查询较少，因此通过增加一张projectid-designid索引表进行优化。对projectid的查询通过索引表转化为designid的查询，虽然比原来多一次查询索引表操作，但是释放了一半的存储容量，下线了一半的维度库实例，实现了50%的成本优化。

Mysql 索引表减少全量冗余

2.2 优化数据架构，实施冷热分离或分层存储

场景：

数据总量过大或者数据增速过快

很多场景中，越早期的数据被翻牌的概率会越低，根据业务特性和访问频次，可以把数据分为热数据和冷数据等（或者冷温热），通过优化数据存储技术，降低不必要的冷数据查询响应，把大量冷数据转移到更低成本的存储介质，达到成本的较大优化。

手段：

实现数据冷热分离

有部分云数据库在服务端已支持，比如腾讯云 MongoDB，AWS ElasticCache，阿里云 HBase 等
对于服务端不支持的，可以通过客户端（业务端）来实现

冷热分离设计

关键逻辑：

1. 写热存储，同时写业务冷热路由数据表

2. 迁移任务根据 业务冷热规则（一般为生产时间或修改时间）进行查询，将符合条件的冷数据写入冷存储，并且从热存储中删除

3. 对账任务根据迁移任务的归档记录，进行定时校验，确保数据不丢失。

4. 客户端查询时，根据业务冷热路由规则进行路由查询。

需要注意：上述方案暂不考虑冷数据升热

案例：

详细见：降本 30%，酷家乐海量数据冷热分离设计与实践

2.3 提升压缩比，减少存储量

场景：

单数据对象大，可压缩空间高

手段：

客户端压缩：选择合适的压缩算法，在入库前压缩存入，出库后解压缩使用。常用的算法有：gzip、zstd、snappy、deflate、lz4 等

优点：压缩格式可随业务数据特性灵活调整，网络带宽友好
缺点：会增加业务复杂度，需要业务端实现压缩与解压缩

服务端压缩：选择支持压缩存储的引擎或者数据库产品，NoSQL 数据库 MongoDB 默认使用 Snappy 压缩

优点：对使用方透明无感知
缺点：压缩格式相对固定

案例：

某业务使用Redis做缓存，总存储量非常大，原始存储估计需要 32G+ 规格。分析评估其数据的特后征，通过压测对比了不同算法的压缩比、压缩耗时等指标。

压测环境:

Platform:CentOS 7

JDK:1.8

CPU:4C(Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz)

Compress Times：2000times

最终通过 gzip 压缩后再存入 Redis，节约了 80% 的空间，使用小规格的 Redis 内存满足了大量数据的缓存需求。

提升数据压缩比

2.4 拥抱云原生，提升利用率

场景：

计算资源过剩，存储资源紧张或业务请求量动态变化场景

传统（云）数据库架构存算比固定，面存储资源不足时通常通过加规格来解决，这样导致计算资源严重过剩，利用率低，通过云原生数据库的弹性伸缩能力、存算分离架构，能够最大化资源利用率，有效降低成本。

手段：

选用云原生（Serverless）数据库。比如 AWS Aurora、腾讯云 TDSQL-C、阿里云 PolarDB

案例：

因为公司微服务做的相对彻底，所以数据库实例会比较多，这其中有不少 1C 的实例，且负载依然比较低，数据库中间件团队正在联合业务将低规格的实例从MySQL迁移到MySQL Serverless 架构版本，把原来静态使用资源的方式，逐步演进到动态使用资源的方式。迁移完成后，预计可实现约 30% 成本节省。

三、总结

以上归纳出的场景案例及相应的优化手段，绝大部分都已经在酷家乐的不同业务场景中进行了实践和落地，在数据库（全品类）降本实践中收益颇丰，在公司业务持续高速增长的同时，有效的控制了数据库（全品类）成本，几乎实现了零增长。

在降本增效成为一个常态的今天，希望可以帮助到更多的企业或者组织实现或达成云数据库降本的目标。

活动推荐

2023 年 3 月 17-18 日，ArchSummit 全球架构师峰会将落地北京海航万豪酒店。来自百度、京东、华为、腾讯、斗鱼、中国信通院等企业与学术界的技术专家，将就数字化业务架构、低代码实践、国产化替代方案、分布式架构等主题展开分享讨论。

目前已上线数字化场景下的业务架构、低代码实践与应用、国产软件优化迭代之路、多数据中心的分布式架构实践、软件质量保障、技术 - 产品 - 业务、高并发架构实现、架构师成长与团队搭建落地实践、大数据和人工智能融合、大规模微服务架构演进、可观测技术落地、云原生大数据实践等多个专题，点击阅读原文去官网查看大会日程。

会期临近，门票即将售罄，购票或咨询其他问题请联系票务同学：15600537884（微信同电话）

百度文心一言发布倒计时十天，我们和背后的工程化团队聊了聊

Meta版ChatGPT惨遭“开源”？最新大模型LLaMA被泄露，已在GitHub收获7k+星

平台工程不适合中国企业？这个观点值得反驳！

继续阅读

阅读原文