数据库资源成本优化方案

方案概述

随着近几年整个大环境经济下行压力增大，越来越多客户感受到了从过去的飞速发展进入到存量时代，处于降本增效的状态，从“粗放式”转变为“精细化”运营。有些企业也在推经营责任制，让各个业务在云上的成本能够做到看得清、管得住、省得了。数据库产品是企业应用系统不可或缺的基础设施，也是成本消耗的头部产品，成本优化势在必行。

本文会围绕数据库产品计费模式、用法&用量对数据库资源进行合理使用及治理，减少资源浪费、优化资源成本。

方案优势

识别优化机会

本方案结合阿里集团在成本优化领域的最佳实践，沉淀了一套相对完整的且具备可落地的实战经验。对于每个优化场景都提供一套详细的建议，明确具体的衡量指标，能够帮助客户找到当前是否存在优化机会点。

成本深度优化

本方案不只是停留在简单的计费方式的优化，更重要的是结合云数据库本身的技术特性，从技术架构层面提供方案指导，如慢SQL优化、数据倾斜如何避免等。对于企业的DBA、架构师非常适用。

客户场景

云上数据库类资源成本优化

场景描述

由于对云上数据库资源管理粗放、不合理的使用方法、对资源计费缺乏足够了解等原因，企业在云上数据库资源使用上存在浪费以及不适合自身实际的情况，用户会发现云上数据库资源成本偏高，甚至由于成本原因不再使用高成本的数据库类云产品，此时企业亟需对云上数据库资源进行治理与优化。

适用客户

• 对云上数据库成本敏感、有优化诉求的企业客户。

• 期望以更贴合自身实际、更优成本使用云上数据库产品的企业客户。

方案架构

整体的优化思路和技术方案如下：按需申请，提升资源利用率，任何优化用量后，需降配/缩容后成本才会下降：

• 空闲资源释放：识别无流量资源静默下线；

• 低利用率资源降配：计算资源（CPU、MEM）降配、存储空间缩容、存储云盘等级降配等；

• 通过应用技术架构优化进行优化：慢SQL优化、避免热数据倾斜、降低磁盘读写吞吐量、表碎片整理、设置数据生命周期、冷热数据分离存储等；

以上都是针对产品的使用优化，还可以根据自身业务需求，选择高性价比、更贴合业务场景的可替代产品。

空闲资源释放

场景一：识别无流量资源静默下线

业务场景：业务应用和资源没有强绑定关系，业务应用下线但依赖的数据库资源没有下线。

技术方案：

1. 识别无流量实例：通过对实例进行业务连接探测，将无业务连接的实例记录下来，作为疑似空闲实例；

2. 找到准确的数据负责人；

3. 负责人二次确认无依赖；

4. 静默下线；

最佳实践：

• 识别无流量实例：连续30天无流量的实例被认定为无流量实例（在此时间段内发现有业务账号连接，则认为仍有业务流量，统计值归0）。

  • 对于云数据库Redis判断是否空闲实例的条件：

    • 最大内存使用率 < 1% && 最大QPS使用率 < 1%

    • 活跃会话数 = 0

    • 实例创建时间 > 30天（排除掉近一个月内新创建的实例）

    • 实例key总数=0（可选，如果等于0说明没有数据；如果不等于0，但使用率极低，也需要根据业务使用情况评估是否可下线。通过云监控/登录到云控制台看性能监控查看）

  • 对于云数据库Lindorm/HBASE判断是否空闲实例的条件：

    • 近一周读请求为0 && 近一周写请求为0

• 找到准确的数据负责人：按照历史关联应用的负责人、实例创建人、实例变更人、数据库申请填写的负责人顺序依次查找。

• 确认无依赖：确认没有定时任务依赖；确认无代码依赖；

• 静默下线：静默7天-30天，禁读写观察，没问题后进行数据库下线操作。

低利用率资源降配

场景一：计算资源（CPU、MEM）降配

业务场景：业务方成本意识不足，评估资源需求时未考虑未来资源利用率；新业务上线一次性申请大规格实例开发测试，持续数月才上线；上线后预估访问量与实际不符，长期低利用率在运行；

技术方案：

1. 最小化规格申请：新业务上线申请最小规格开发测试，准备就绪后再逐步扩容规格，扩容规格按照一定使用率要求选择；

2. 低利用率业务分多次降配：计算资源包括CPU和内存，降配后计算资源的利用率提升并非线性增长，建议分批多次降配，降配后间隔24h观察利用率变化，再决定是否需要继续降配。数据库实例计算规格降配一般底层伴随着实例的迁移，变配过程中会对业务有影响，建议业务低峰期操作。

最佳实践：

• RDS（MySQL 三节点企业版）：主要关注CPU使用率、内存使用率和buffer pool命中率，对于缓存命中率100%，但内存使用率低的场景来说，内存空间存在浪费。一般建议CPU平均使用率提升到40%，内存平均使用率提升到80%。

• Redis（内存数据库）：内存是该产品核心计费项，提升内存利用率可以有效降本，保守可按照内存平均利用率提升到40%降配。降配方式可直接降低内存规格或者减少分片数，减少分片数不仅内存空间会减少，cpu、最大连接数等指标也会相应降低，选择降配规格时需要注意，避免出现其他指标出现瓶颈。

  • Redis使用率低判断条件参考：

    • 平均内存使用率 <= 30% && 最大内存使用率 < = 35%

    • 平均cpu使用率 <= 20% && 最大cpu使用率 <= 25%

  • 对于云数据库Lindorm/HBASE判断是否使用率偏低

    • core节点数量>8（多可用区部署，每个可用区至少4个节点）

    • CPU近一周峰值利用率 < 40%

    • 存储水位 < 70%（若存储水位较高，也可通过先扩容存储，再缩节点的方式达成降本目的）

    • 缩减节点数

      • 考虑到业务数据模型与存取方式的多样性以及对读写RT要求的不同，数据库侧无法简单根据TPS或QPS提供精确的资源规格。为了平衡降本需求与数据库稳定性两个需求，计算目标节点时以单位时间（一周）内实例CPU利用率的峰值为计算项，设置一个安全的目标值（40%），假设实例节点变化前后请求平均分布在每个节点，且CPU利用率的变化率与请求量变化率相同的条件下计算出目标节点数。在缩减节点时推荐采用分批处理的方式，并在稳定期观察读写RT在业务可接受范围内后再继续执行下一批次。

  • 对于云数据库HBASE里面的core节点降配规格：

    • core节点数<=8（多可用区部署，每个可用区至少4个节点）

    • CPU近一周峰值利用率 < 20%

场景二：存储空间缩容

业务场景：往往因为担心写满存储导致锁盘业务中断，在申请存储空间会预留较多buffer；新业务上线一次性申请到位，长时间持续低使用率状态；也有业务做过数据清理和碎片整理，但是没有及时缩容，导致长期存储空间利用率低，造成成本浪费。

技术方案：

数据库云产品存储基本都是按照申请量收费，所以必须要将存储空间缩容才会降本。主要关注存储空间利用率和存储量增速两个指标，根据不同产品锁盘的阈值，建议保守预留20% buffer，同时需关注数据增速，避免扩容不及时导致锁盘，影响业务稳定性。部分产品支持存储自动扩容，可根据存储量增速设置自动扩容阈值和上限。

最佳实践：

RDS：

• 缩容后将关闭自动扩容能力，需要先订阅存储空间告警（建议阈值设置85%，具体取决于数据量增速而定），触发告警后及时手工完成扩容；

• 通过表碎片整理、数据清理、冷热数据分离等优化手段，降低无用数据存储；

• 通过缩容提升存储空间使用率。

Lindorm存储缩容判断条件：

• 最近一周峰值存储水位 < 65%

• 当前存储规格非最小值。hbase 单个core节点最小容量为400G，例如实例中包含4个节点，则实例最小总存储为1600G。

场景三：存储云盘等级降配

业务场景：新业务申请存储时，对云盘等级的各项指标没有概念，一般会用默认推荐值，实际可以使用更低配置的云盘等级。

技术方案：如果是内部系统、平台型产品，对数据库读写访问少，且数据量不大的场景，可以直接申请固定的低等级云盘，比如PL0云盘。如果是对外业务有很大增长空间，建议申请云盘等级可根据用量切换成serverless_essd搭配额外吞吐量来按需申请。

最佳实践：

RDS（MySQL 三节点企业版）：选择云盘等级，主要关注磁盘读写吞吐量、读写时延、IOPS指标，一个数据库实例三个节点（leader、follower、logger），每个节点都包含数据盘和日志盘，这些盘的指标都需要评估，建议每项指标按照预留10%-20%的buffer选择云盘等级。

应用技术架构优化

场景一：慢SQL优化

业务场景：存在慢SQL占用计算资源，导致需要申请高规格来支撑，造成成本浪费。

技术方案：慢SQL优化核心思想是通过扫描最少的数据块，拿到想要的结果。减少扫描范围通常有如以下集中方法：索引优化、SQL书写优化、业务逻辑优化。

• 索引优化：决定索引是否使用合理，主要看扫描行数和返回行数的比例，越接近1:1，索引越高效。

  • 主键索引必须有，最好是无业务意义自增主键。使用MySQL AUTO_INCREMENT无业务意义自增主键可以减少主键值被修改的可能性，也避免了为维护主键有序性而导致的行移动、甚至是数据块分裂等影响数据库性能的操作。

  • 选择正确的列创建索引。要在选择率高的列上创建索引，选择率的计算方法是：count(distinct column)/count(*) ，数值越接近1，选择率越高。

  • 索引不是越多越好。会有写放大问题；多个索引可被使用时，索引会进入possible_key，然后优化器会对每一个possible_key进行采样并计算数据分布情况，进而最终确认使用哪个真实的索引（key）去执行SQL。

  • 合理利用索引的有序性来避免排序。

• SQL书写优化：

  • 避免使用select *。避免不必要的字段占用返回时的网络带宽和减少执行时的逻辑读。

  • 子查询优化。MySQL从5.7开始优化器对子查询进行了优化，会自动转换为join再执行，而对于5.7以下版本的MySQL建议把子查询改成join的方式。

  • 分页优化。分页查询在前几页执行速度比较快，但越往后就越慢。一般分页查询时，通过创建 覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。

• 业务逻辑优化：

  • 从业务逻辑减少数据查询量，当数据量少时，精确显示；当数据量过大，用户对真实数据不敏感时，可通过模糊方式显示。

场景二：避免热数据倾斜

业务场景：分库分表键选择不合理，导致数据集中在某几个分片上，比如按省份分区，人口数量多或者业务频繁的省份数据倾斜严重，会出现节点处理数据时资源不足，单节点CPU过高或者出现OOM，任务长尾等，拖慢整体的查询效率。

技术方案：

• 可以先通过对比各个数据节点上数据存储量确定是否存在严重的数据倾斜情况，云产品可以通过数据建模诊断查看倾斜严重的表和分区；也可以通过select count(*) from table group by partition的方式查看分区的数据量差距；

• 重新选择合适的分区字段建表；

• 进行数据全量和增量迁移；

• 新旧表切换，使用新的表承载业务。

最佳实践：

ADB（云原生数据仓库AnalyticDB MySQL版）：ADB可以直接在云控制台上数据建模中查看表的倾斜情况，目前ADB不支持直接修改分区键，修改分区键需要按新的分区键重新建表后insert into select 重新导入数据。直接执行insert into select语句会导致超时，可以按分区，采用 submit job insert overwrite into 这种提交任务的方式进行数据迁移。新的分区键是否可以避免数据倾斜可以提前通过select count group by的方式确认。同时需要注意，分区键的选择要优先在业务最常用的查询字段中选择。

场景三：降低磁盘读写吞吐量

业务场景：buffer pool命中率低，产生大量物理读；集中进行历史数据清理或碎片整理；集中拉取全量数据；

技术方案：磁盘吞吐是衡量使用云盘等级的重要指标，降低磁盘吞吐后，可通过降低云盘等级来降本（即先通过技术手段降低磁盘吞吐，达到更低等级进而选购一个更低等级的云盘），主要有如下场景：

最佳实践：

RDS（MySQL 三节点企业版）：数据库云盘PL0的价格相对于PL1可以便宜54.55%，通过直接降配和降吞吐将云盘降低到PL0规格，可以将存储成本节省约50%以上。

场景四：表碎片整理

业务场景： 碎片产生的原因包括记录被Delete，且原空间无法复用；记录被Update（通常出现在变长字段中），原空间无法复用；记录插入导致页分裂，页的填充率降低。

技术方案：如果表空间碎片率大，一方面浪费存储空间，另一方面会导致查询扫描IO成本提升，效率降低，所以建议表空间大且碎片率高的及时回收碎片。

最佳实践：

RDS（MySQL 三节点企业版）：建议单表大于6G，并且碎片率大于30%做碎片整理，如果表过大，需要考虑碎片整理长时间不可用的影响，建议放在业务低峰期进行。不建议经常做碎片整理，一般只需要每周或者每月整理一次即可。

场景五：设置数据生命周期

业务场景：存储类产品的数据会持续增长，数据库中存储的很多数据会逐渐由热数据变成冷数据，由冷数据变成过期数据，比如：操作日志类的数据可能只需要审计近半年或者一年；KV数据库中的key有缓存失效的时间；数仓BI分析类的数据，只需要分析近一年或者三年的数据才有意义等等。

技术方案：随着时间推移，存储量如果不清理会持续增长，但实际上业务并非所有历史数据都需要查询或者分析，建议设置数据生命周期，规定数据可保存的时间，超过时效的数据进行数据清理。

最佳实践：

• ADB（云原生数据仓库AnalyticDB MySQL版）：使用二级分区可以设置lifecycle保留N个二级分区，二级分区做了倒排序，超过N后，最早的数据将会自动过期清理。

• 云数据库Redis版：作为高速缓存，一定要对具有时效性的key设置过期时间，通过redis自身的过期key清理策略来降低过期key对内存的占用，避免定期手动清理。如果不设置，这些key会一直占用内存，随着时间推移内存占用会越来越大，直到把内存占满；不要将所有数据全部存到redis中，redis内存成本昂贵，建议只将高频热数据存储到Redis中，低频访问数据放到MySQL等磁盘存储中。

场景六：冷热数据分离存储

业务场景：业务场景中会有数据高频访问周期，例如顾客大多数场景访问的是半年内的订单信息，只有少数场景下需要访问超过半年的历史订单，更少有场景会访问超过两年的订单数据。

技术方案：应该将性能更好，效率更高的资源优先用在热数据和温数据的存储和使用上，而对于偶尔访问一次的冷数据可以使用低成本的存储产品提供服务。对于不支持自动冷热分离的产品，还需要引入数据同步工具将冷数据迁移到低成本的存储产品上。

最佳实践：

1. 云原生数据仓库AnalyticDB MySQL版：ADS的弹性模式天然支持了冷热数据分离，只需要在创建表时设置storage_policy即可制定该表存储热数据还是冷数据，也可以自动设置一张表中指定数量的分区数为热数据，其余为冷数据。热数据是直接存储在ADB上的，冷数据则是存储在OSS上，成本更低，同时首次访问冷数据有数据加载时间，冷数据会被加载到本地访问，需要业务评估访问时间是否可以接受。

2. PolarDB通过OSS外表访问实现冷热分离：PolarDB MySQL推出了基于OSS引擎的外表查询功能，可直接查询存储在OSS引擎的CSV格式数据。用户将查询频率较低的冷数据导出到OSS引擎上，由于OSS存储价格十分便宜，通过PolarDB提供的外表查询能力访问，极大的降低数据存储成本。

   

   通过PolarDB提供的OSSOUTFILE功能，将本地的数据文件导出为CSV文件，并存储在OSS引擎上。建议使用OSSOUTFILE功能占用的总内存不要超过节点内存的5%，否则可能会影响到线上其他业务。

计费方式优化

RDS计费方式优化

RDS实例的基础计费由计算资源费用和存储资源费用组成。如下表所示：

通用型节省计划

RDS通用型节省计划是一种针对RDS按量付费项的折扣权益计划。具备包年包月实例价格低廉的特性，同时又可享受按量付费实例的随时购买、随时升级、随时释放的灵活。可同时抵扣按量付费实例的费用和其他各类按量付费的计费项，对比按量付费可节省15%~60%的费用。

推荐场景

• 场景一：购买的按量付费实例，每小时的实例规格、数据存储、备份存储、独享代理、SQL审计、秒级监控的费用都比较固定，您可以根据每小时的平均原始费用计算出保底金额（保底金额=原始费用*折扣率），按照该保底金额、期望享受的折扣和使用时长来购买通用型节省计划，可以有效降低成本。

• 场景二：产品选型时，需对多种实例规格进行POC测试，测试成本较高。您可以购买不同规格的按量付费实例进行测试。产生的所有费用都可以从通用型节省计划中抵扣。

RDS资源包

RDS资源包分为计算包及存储包两种。可抵扣RDS产品下的各数据库类型。抵扣对象如下表所示：

PolarDB计费方式优化

PolarDB资源包

PolarDB提供了两种资源包：计算包和存储包，来降低集群的计算节点费用和存储费用，增加集群使用灵活性。

云内存数据库Redis计费方式优化

计费项

计费方式

实例规格费用支持按量付费、包年包月的计费方式。按量付费实例推荐搭配资源包，降低成本。

资源包

选择“按量付费+资源包”的计费方式，可以同时享受按量付费的灵活与近似包年包月的低价。

Lindorm计费方式优化

Lindorm支持包年包月和按量付费两种计费方式，其计费项主要包括存储类型、存储空间以及计算引擎类型及对应节点数量及规格。

存储类型目前提供了三种主要的存储类型：容量型存储、标准型存储、性能型存储。其适应场景如下：

产品说明及名词

产品说明

安全性

成本优化安全性

请详细阅读本文方案架构、注意事项、操作步骤等内容，了解成本优化对数据存储、使用方法及计费方面的影响，充分了解影响面及风险后再确定是否要执行优化。

注意事项

变配操作尽量在业务低峰进行

数据库实例计算规格降配一般底层伴随着实例的迁移，变配过程中会对业务有影响，建议业务低峰期操作。

资源下线要谨慎

一定要通过静默下线的方式，禁读写观察7~30天，确保对业务无影响了才能下线数据库。

实施步骤

实施准备

• 已拥有阿里云账号，了解相关资源成本费用现状。

• 已阅读方案架构及注意事项章节，了解操作影响面及可能的风险。

• 已开通云监控，并接入相关实例监控。

实施时长

在实施准备工作完成的情况下，本方案实施预计时长：60分钟。

操作步骤

根据方案架构中的介绍，结合企业实际情况选择进行下述优化项进行具体操作。

RDS成本优化

计费方式优化

RDS节省计划，针对按量付费可降低15%~60%的费用，操作步骤见官网手册。

计算包是RDS推出的一种预付费资源包，可以抵扣RDS MySQL、RDS PostgreSQL、RDS SQL Server、RDS MariaDB实例的按量付费计算资源。操作步骤见官网手册。

存储包是RDS推出的一种预付费资源包，可以抵扣RDS MySQL、RDS PostgreSQL、RDS SQL Server、RDS MariaDB的实例存储空间、备份空间（实例备份、长期备份、异地备份）和SQL审计使用量，抵扣部分不再计费，仅超出部分按小时计费。操作步骤见官网手册。

Redis成本优化

计费方式优化

选择“按量付费+资源包”的计费方式，可以同时享受按量付费的灵活与近似包年包月的低价，操作步骤见官网手册。

包年包月转按量付费，操作步骤见官网手册。

按量付费转包年包月，操作步骤见官网手册。

Lindorm成本优化

包年包月转按量付费，操作步骤见官网手册。

按量付费转包年包月，操作步骤见官网手册。

相关内容

• Lindorm计费项

• RDS计费项

• Redis计费项