把数据库的存储空间算到100TB这个量级你大概率已经不会再去纠结某个慢SQL要不要加索引了——账单上那一串数字才是每天早上最扎心的东西。我前两年给一个金融类客户做过一次成本复盘光是历史库就堆到接近90TB后来迁到PolarDB并持续扩容到100TB以上存储成本被重新压下来一大截。今天这篇就把100TB当靶子把PolarDB的存储成本从计费口径到实际测算、再到和RDS/自建MySQL的对比完整拆一遍。先说清楚这篇文章能解决什么问题如果你是一名架构师、DBA或者是公司里负责审云账单的运维负责人此刻正在纠结“100TB的数据到底放哪最划算”那这篇就是给你写的。我会把云数据库的成本结构、PolarDB的省钱原理、真实测算口径、迁移和连接实操全部过一遍尽量做到你看完能直接套用自己也能算一遍账。1. 100TB存储规模下成本问题的本质是什么1.1 为什么100TB是一个重要的分水岭很多人对数据库容量没什么体感觉得“反正云上可以无限扩多花钱就行”。但数据量一旦到100TB很多想法都得变。先说一个简单的换算100TB如果按1024进制就是102400GB。就算云盘每GB每月只收1块钱裸存储成本也要十万元级别。这个数字直接把问题从“技术选型”顶到了“财务决策”层面。老板一定会问这笔钱花得值不值有没有更便宜的办法这时候你再掏出一堆性能参数没有任何说服力得拿出账单来。再说架构层面。数据量不到50TB时一个RDS MySQL高可用实例加定期归档基本能撑住。但到了100TB单实例的容量上限、备份耗时、恢复时间会接连成为瓶颈。不少团队被逼着走上分库分表的路拆出几十个实例结果每个实例都要单独购买计算资源和存储空间还要配主从复制。存储不仅没有省反而因为多实例冗余总成本直线上升。我见过最夸张的一个案例某电商团队把订单表按月份拆了36个RDS实例每个实例1TB到3TB不等主备双节点加备份空间月初对账时DBA要同时维护36套监控和备份策略存储总成本比合并前高了一倍多。这就是存储规模逼近100TB时最典型的“管理成本吞噬资源成本”现象。而PolarDB这类云原生数据库把存储和计算彻底分开所有计算节点共享同一份存储数据存储池对外可以做得很大内部自动扩展。你要关注的不是拆多少个实例而是业务到底需要多少计算能力、多少实际存储。这个思维转变才是成本优化的起点。1.2 云数据库账单上到底有哪些成本项说到算账很多人第一反应是看“存储单价”但云数据库的真实账单是一个组合体。以PolarDB为例一个集群的月度成本通常包含这几块计算节点费用主节点RW和只读节点RO各按规格计费比如4核16GB、8核32GB不同规格价格不同。存储空间费用按集群实际占用的存储容量计费支持自动扩容单位一般是“元/GB/小时”。备份空间费用数据库备份文件占用的对象存储空间超过免费额度后单独计费。网络流量费用公网访问产生的下行流量按GB计费内网流量免费。增值功能费用SQL洞察、性能洞察、安全审计这类附加功能开启后按量计费。这里有个容易踩的坑很多人只比较存储单价忽略了计算节点和备份空间的权重。100TB的数据计算节点哪怕只用中低规格一个月也要几千到上万元备份空间如果免费额度不够轻松再多出几万元。后续我会在测算部分把这些全部算进去。还有计费模式的问题。PolarDB和大多数云数据库一样支持包年包月和按量付费。按量付费灵活适合短期测试长期稳定业务选包年包月单价通常更便宜。另外存储空间也有类似“存储包”的预付费形式买对了能再省一截我后面会详细讲。2. PolarDB凭什么把存储成本压下来2.1 存储计算分离从“自己盖仓库”到“租大仓”要理解PolarDB为什么省钱得先理解它的架构核心存储与计算分离。传统自建MySQL或者RDS那种“计算存储一体”的架构相当于你自己盖了一栋仓库仓库里必须配办公室、货架、装卸工。哪怕你只用了十分之一的空间仓库的租金和维护成本一分不少。数据量小的时候无所谓但到100TB规模这种模式的成本几乎是线性膨胀的——你扩容计算存储也连带着要加你加存储计算资源又闲置浪费。PolarDB采用的是共享分布式存储计算节点和存储节点解耦。打个比方办公室还是你的办公室但货物全部放到一个巨大的公共仓库里用了多少平就付多少租金。计算资源不够就单独加办公室存储不够就扩仓库两边互不绑架。这个架构直接影响成本结构。存储费用按实际使用量计费业务没写入那么多数据就不需要为预留空间买单。计算节点也可以独立伸缩比如白天高峰用8核凌晨低谷缩到2核成本随业务曲线走。2.2 一写多读与共享存储只读节点不再“烧钱”很多业务并不是单机就能扛住的尤其是读多写少的场景习惯性会加只读节点分担查询压力。传统MySQL主从复制架构下每加一个只读节点就要在存储上复制一份全量数据。100TB的数据加两个只读节点存储成本直接变成300TB的账。PolarDB的做法完全不同。它的主节点和只读节点共享同一份存储物理上数据只有一份。增加只读节点时不需要复制数据只需要为新增的计算节点付费。存储成本不会因为只读节点增加而翻倍。这在100TB场景里差异非常明显。比如你当前需要一个主节点加两个只读节点来扛读写压力传统架构存储开销大约是300TBPolarDB只需要100TB。单这一项存储成本就省了三分之二。当然这里有个前提需要说明PolarDB底层的数据多副本、一致性协议等机制在物理存储链路层面有自己的冗余设计这部分成本被平台承担并通过一定方式体现在单价里。但从用户账单角度看你只按一份逻辑存储付费三副本之类的物理开销不需要自己单独掏钱。这其实就是云原生数据库“把复杂留给自己把简单留给用户”的体现。2.3 存储类型、压缩与冷热分层的省钱细节除了架构层面的节省PolarDB在存储细节上也有不少可以薅的“羊毛”。首先是存储类型选择。PolarDB底层使用ESSD云盘分PL0、PL1、PL2、PL3等性能等级。PL0便宜适合数据仓库、日志等对延迟不敏感的场景PL1是均衡配置PL2和PL3性能更强但单价更高。100TB这个体量下并不是所有表都需要最高性能的存储。业务上冷热分离做得好选对存储等级单价差距可以到一倍以上。其次是数据压缩。PolarDB MySQL版对部分数据类型有压缩能力尤其是字符型、日志型数据压缩比通常可以达到2:1甚至更高。100TB原始数据压缩后可能只需要40-50TB的存储空间直接砍掉一半存储费。这个收益是实打实的而且对业务透明应用层不需要做任何改造。再者是冷热分层和归档策略。PolarDB支持将历史分区放到成本更低的存储介质或者通过DTS等工具同步到OSS归档。对于100TB规模的库通常有相当一部分是低频访问的历史数据把它们挪到低成本存储上月度成本可能下降30%以上。不过要提醒一句压缩和冷热分层都需要结合业务访问模式来评估。如果是核心交易类数据频繁更新且需要极致性能压缩反而可能影响写入速度低频历史数据做归档则要考虑查询时取回的成本。成本优化是系统工程不是简单开个开关。3. 100TB存储成本测算与方案对比3.1 计费口径与100TB月度成本估算下面进入最核心的环节算账。我不打算堆官方文档里的超长价格表因为云产品价格本来就会随时更新、分地域、分活动我更想给你一个可复用的测算框架。假设场景主节点采用8核32GB规格一个只读节点采用4核16GB规格存储容量100TB业务运行在中国内地某地域按包年包月的存储包价格大致估算。请注意以下数字是参考值真实价格以控制台为准但计算思路完全通用。计费项计算口径月度成本估算存储空间102400GB × 约0.8元/GB/月购买存储包后约8.2万元主节点计算8核32GB包年包月价约2000-3000元只读节点计算4核16GB包年包月价约1000-1500元备份空间免费额度内0元公网流量按需忽略测试流量暂计0元合计约8.5-8.7万元/月这里有几个容易被忽略的口径需要说清楚。第一100TB存储如果走按量付费单价大约是0.0014-0.002元/GB/小时折算下来一个月可能到10万-14万元和买存储包差距很大。所以长期稳定业务无脑买存储包这是最基础的省钱操作。第二备份空间的免费额度PolarDB不同版本和活动政策可能不一样有的按存储空间一定比例赠送有的送固定容量。100TB的库如果每天做全量备份备份文件可能达到几十TB一旦超出免费额度新增费用非常夸张。建议在控制台开启“备份压缩”并合理设置备份保留周期比如只保留7天而不是默认的30天。第三SQL洞察和审计功能不要盲目全开。100TB规模下慢日志和全量SQL采集会产生大量写入和存储开销如果只是临时排查问题用完就关别让它在账单里默默跑一年。3.2 与RDS MySQL、自建方案的详细对比没有对比就没有说服力。我把三种常见方案放在同一个表格里按照100TB这个规模横向比较。对比维度PolarDB MySQL版RDS MySQL高可用版自建MySQLECSESSD存储容量上限单集群可支持PB级百TB轻松单实例通常有上限100TB大概率要拆库受云盘挂载和ECS限制要规划多台机器只读扩展成本只读节点共享存储计算费用随规格走只读实例要独立存储复制全量数据从库要另外整机复制存储成本几乎翻倍存储单价存储包后大约0.8元/GB/月ESSD云盘约1元/GB/月上下ESSD云盘约1元/GB/月另加ECS费用备份成本有一定免费额度合理配置后可控制备份免费额度少超量费用常见自己写备份脚本要预留额外存储运维成本平台托管自动扩缩容运维开销低平台托管但架构限制多需要专职DBA补丁、高可用、容灾全自己管100TB月度总成本参考约8.5万元起约9.5-12万元且要拆多实例单算云资源可能10万加上人力成本更高从这个表能看出来PolarDB在100TB这个量级的优势主要体现在三个点一是只读节点不重复消耗存储二是不需要为了容量上限拆成几十个实例三是存储包机制让大容量存储的边际成本更低。自建方案看起来云盘单价差不多但你还要额外算ECS实例费用、架构师的工时、故障处理的凌晨电话费。很多公司喜欢拿“自建便宜”说事实际把人力成本和风险折算进去之后云数据库在百TB规模往往更划算。3.3 性价比结论PolarDB的优势区间在哪任何方案都有适用边界PolarDB也不是所有场景都无脑最优。根据我的实际经验它最合适的区间大概是这样数据量超过20TB且未来还会增长。读多写少或者有明显的读写分离需求。需要快速扩容不想因为容量上限做分库分表。团队DBA资源紧张希望减少日常运维事务。反过来如果你的业务数据量只有几百GB单机MySQL就能跑得很好没必要上PolarDB如果业务是一次性历史归档写完就不再读直接上OSS或者归档存储更便宜如果对极致性能有变态要求且能接受复杂运维自建加定制优化也有它的价值。所以说100TB存储成本分析这件事比的不是某一个单价的数字而是整个系统架构和运维模型在当前规模下的综合效率。PolarDB的高性价比是建立在大容量、多节点、弹性场景下的。4. 从RDS MySQL迁移到PolarDB的实操与避坑4.1 创建PolarDB MySQL版实例完整流程讲完理论上点实操。很多人好奇PolarDB和RDS MySQL从控制台到连接到底怎么操作我这里以一个全新的PolarDB MySQL版集群为例把步骤走一遍。第一步登录阿里云控制台在顶部搜索框输入“PolarDB”进入云原生数据库PolarDB管理页面。点击“创建集群”选择地域注意地域要和你的应用服务器ECS在同一个Region否则走公网流量费用会很肉疼。第二步选择引擎。这里可以看到MySQL、PostgreSQL、兼容Oracle的语法模式等选项。如果你的业务是MySQL体系直接选MySQL版兼容性最好从RDS迁移过来几乎不需要改代码。第三步配置计算规格。选择主节点规格比如8核32GB再根据需求配置只读节点。首次创建可以只建主节点后续按需增加只读节点。网络类型选择VPC提前创建好VPC和交换机。第四步设置数据库账号密码、集群名称、购买时长。这里有个小技巧如果是测试环境可以先按量付费创建验证完再转包年包月如果是生产环境直接包年包月加购买存储包价格最优。第五步创建完成后在集群详情页可以看到“主地址”和“集群地址”。主地址是指向主节点的连接地址集群地址会自动做读写分离和负载均衡把读请求分发到只读节点。业务侧建议优先使用集群地址让流量自动分流。连接方式也很简单。如果你的ECS和PolarDB在同一个VPC内在ECS上用mysql命令行直接连mysql -h your-cluster-address.mysql.polardb.rds.aliyuncs.com -u your_user -p -P 3306首次连接前记得在控制台配置白名单把应用服务器ECS的内网IP加进去。不配置白名单即使密码正确也会报错。DBA如果习惯用DMS也可以在控制台直接点“登录数据库”网页上就能跑SQL免去本地装客户端的麻烦。4.2 从RDS MySQL迁移的路线和注意事项从RDS MySQL迁移到PolarDB最常见的方式是使用数据传输服务DTS。整个过程可以做到业务不停机迁移步骤大概是在DTS控制台新建迁移任务源端选择RDS MySQL实例目标端选择PolarDB集群。迁移类型选择“结构迁移全量数据迁移增量数据迁移”这样旧库写入不停新库持续同步。预检查通过后启动任务等全量数据迁移完成增量同步延迟降为0。在业务低峰期将应用连接串切换到PolarDB集群地址。观察一段时间确认无异常后停止DTS任务释放RDS实例。这个流程我跑过多次有几点必须提醒。第一迁移前一定要先在测试环境做一次完整演练尤其是数据结构里有特殊类型、外部触发器、定时任务的情况DTS的映射规则不一定百分之百兼容。第二大表建议提前做索引优化PolarDB的存储引擎优化器逻辑和RDS略有差异迁移后跑一遍慢查询日志把缺失的联合索引建上。第三业务侧连接池的参数要适配PolarDB的集群地址后端节点数会变化连接池最大连接数不要设死。额外提一句连接指南里的常见坑很多人在本地用Navicat或MySQL Workbench连PolarDB发现连接超时。90%的原因是白名单没有加自己的公网IP。排查时先别怀疑配置看一眼控制台白名单列表通常都是这里的问题。还有PolarDB的账号权限体系和RDS不完全一样比如某些管理账号没有SUPER权限这是为了安全不是bug。4.3 成本优化落地清单与常见坑实录最后给大家一份可以直接抄作业的成本优化清单结合我自己的踩坑经验购买存储包100TB场景存储包比按量付费一个月能省几万元这是优先级最高的操作。选择合适的计算规格不要为了“性能冗余”买过高规格PolarDB可以随时升配先从小规格跑起来观察负载不够再升。只读节点按需创建每次大促或压测前加节点结束后及时删除。只读节点虽然不复制存储但计算费用是实打实的。精简备份策略缩短备份保留周期开启备份压缩把备份成本压到免费额度内。关闭不用的增值功能SQL洞察、审计日志这类功能用的时候再开用完就关。冷数据归档超过半年不访问的历史表通过DTS同步到OSS或转为PolarDB的归档存储释放高成本存储空间。我遇到过的一个典型问题客户在PolarDB控制台看到“存储空间自动扩容”默认开启就没管它。结果某个业务bug触发大量临时数据写入存储从60TB飙到110TB一个月的存储账单翻了快一倍。后来我们帮他把临时表放到独立的临时实例里给核心集群设置存储告警阈值才算控制住。这里也提醒大家自动扩容是保命功能但一定要配好告警别让它变成失控的源头。另外还有一个坑是关于地域的。存储包和集群必须在同一个地域才能抵扣有些人看某个地域存储包便宜就买了一个结果集群在另一个地域根本抵扣不了。买之前先在集群详情页确认地域再下单。最后再分享一个我个人的小技巧处理100TB这种规模的数据我习惯在每个月底固定做一次“账单体检”打开费用中心把存储、计算、备份、流量四项列出来环比看一遍任何一项涨幅超过20%都要找到具体原因。很多成本失控都是小问题积累出来的比如某个只读节点忘了释放某个备份保留周期被误改了一个月多出几千块不刻意查根本发现不了。这套方法配合PolarDB的弹性能力是目前我处理大容量数据库成本问题比较顺手的一套打法。如果你的数据量也在往100TB这个方向走希望这篇能帮你把账算明白少踩几个坑。