PolarDB 的存算分离架构最让我佩服的地方不是它把 100TB 超大规模数据装进了一个集群而是它让这些数据的日常管理变得不再惊心动魄。做数据库这些年我有个很深的体会数据量每上一个数量级数据库的脾气就会大变。1TB 的时候你还能用传统手段对付它到了 10TB备份窗口、DDL 锁表、主从延迟这些麻烦开始轮番登场等到 100TB 这个量级以前那些理所当然的操作几乎全都行不通了。这篇文章拆解三个超大规模客户的实际场景聊聊 100TB 数据在 PolarDB 上是怎么被管理起来的以及存算分离到底解决了传统架构的哪些根本问题。正在被数据量增长逼到头大的 DBA、架构师或者处在分布式改造选型纠结期的团队应该都能从这里找到参考。1. 100TB 对数据库到底意味着什么单机架构的容量天花板1.1 当数据量跨过百 TB常规操作全部失效先说一个反直觉的事实很多人以为 100TB 和 10TB 只是差了 10 倍数据量撑死是容量大一点、查询慢一点。但真实情况是当数据库跨过 100TB 这条线很多操作的性质就变了。拿备份来说。10TB 的库用物理备份跑几个小时的备份窗口还能接受。到了 100TB传统逻辑备份基本上就是不可能完成的任务——不是能不能备份的问题而是备份时间窗口、备份文件存储成本、恢复时长全部失控。你想象一下凌晨 2 点开始备份到早上 9 点业务高峰期还没跑完这还怎么玩恢复就更可怕100TB 的数据靠从一个备份文件里慢慢搬回来可能要蹲在机房几天几夜。再看 DDL。100TB 的大表上加一个索引如果用传统的 copy 算法除了要等它慢慢跑还要处理锁表导致业务停摆的问题。我曾经见过一个真实事故某团队在 80TB 的核心表上执行一条ALTER TABLE加字段直接把业务卡了两个小时这就是没理解大表 DDL 的成本和表大小成正比这个铁律。数据量越大一条常规 SQL 的杀伤力就越强这是所有大库 DBA 的共识。还有主从同步。传统一主一从架构里binlog的同步和回放在 10TB 时可能只有秒级延迟可控。到了 100TB一个大事务就能让从库延迟几十分钟从库读出来的数据完全是过去时业务方拿着旧数据做决策不出事是运气出事是必然。如果你经历过从库延迟报警响了一整夜的滋味应该能理解我在说什么。1.2 扩容的恶性循环数据量越大迁移越痛苦传统单机数据库解决容量问题只有一个思路换更大的机器或者做分库分表。换机器听着简单但 100TB 的数据要从老机器迁到新机器全量拷贝的时间、校验的时间、切换窗口每一项都足够让运维团队掉一层皮。更要命的是物理机上插满硬盘、打满 RAID 之后再想往上扩就只能换机器而换机器的成本不是线性的是跨越式的从 20TB 到 50TB 是一台机器的事从 50TB 到 100TB 可能就要换整个硬件平台。分库分表听着更技术但代价是业务改造。所有 SQL 要带分片键跨分片的 join 要拆到应用层做分布式事务变成巨大的坑扩容时还要重新计算分片规则、迁移数据。我们把话说得直白一点分库分表是业务上不得不痛之后的选择而不是数据量上来之后的首选方案。很多团队在 5TB、10TB 的时候就被迫做了分库分表结果到了 100TB分片数不够了又得做二次拆分——这就像一间房子装修到一半发现地基小了往哪儿补都别扭。我见过太多团队业务代码里充满了分片路由逻辑后来想回归单库重构成本高到让人绝望。1.3 成本失控100TB 商业数据库的授权费有多离谱还有一个绕不开的问题是钱。如果用的是商业数据库尤其是 Oracle 这类按 CPU 授权收费的产品100TB 数据量的授权费用可能比服务器硬件贵出好几倍。很多企业每年在数据库授权上花的钱够买一个小型机阵列了。这也是为什么最近几年云原生数据库的浪潮里大量金融、政企客户把目光投向 PolarDB 的 Oracle 兼容版本——不是单纯想换个牌子而是授权费已经成了运营成本里一块看得见的巨石。把这些痛点摆在一起你会发现一个共同点它们的根源都是计算和存储被绑死在一台机器上。只要换掉这个前提很多问题就能迎刃而解。这就是存算分离架构登上舞台的真正原因。2. 存算分离的底层逻辑PolarDB 凭什么能接住 100TB2.1 把计算和存储拆开各自独立扩展PolarDB 的存算分离说白了就是一句话计算节点管算存储节点管存两者通过高速网络连接谁需要扩容就扩谁互相不绑架。传统数据库里计算和存储是绑在一台机器上的。CPU、内存、磁盘、网卡都在一台物理机里你想扩存储就得连计算一起换你想加计算能力就得连存储一起买资源利用率低扩容成本高。PolarDB 把存储层抽出来做成了分布式共享存储计算节点是无状态的只负责执行 SQL存储节点是分布式的负责所有数据的实际存放和冗余保障。这样带来的直接好处是存储扩容的时候不需要动计算节点业务连接完全不受影响加只读节点的时候不需要拷贝数据新节点起来就能直接读数据——因为它和主节点共享的就是同一份存储。打个比方你就明白了。传统架构像是你自己开了一家饭店厨房和餐厅必须开在一起客人多了扩餐厅就得扩厨房。存算分离是你把食材仓库单独租出去了餐厅要扩容只需要在旁边再开一间不需要重新建厨房食材仓库本来就是共享的。数据量越大这种各自独立扩展的优势就越明显。2.2 redo log 下推日志即数据的关键设计PolarDB 存算分离里有一个非常关键的设计叫日志即数据Log as Data它解决的是存算分离之后读节点怎么跟写节点保持一致的问题。传统 MySQL 主从复制的过程是主库产生binlog通过网络传给从库从库把binlog解析成 SQL 重新执行一遍relay log回放从库才能追上主库。这有个问题回放是重复执行一遍操作在大事务、高峰期会产生明显的同步延迟。PolarDB 的机制不太一样计算节点写到存储层的不是数据页而是redo log由存储层自己负责把redo log回放成数据页。只读节点不需要像传统从库那样重新执行一遍 SQL它直接从共享存储读已经回放好的数据页。这样有几个直接好处一是主节点和只读节点之间不再有传输 binlog 回放 SQL的链路延迟大幅降低二是写节点只写一份redo log就可以同时服务所有读节点写入路径更短三是在存储层做回放天然规避了传统复制里大事务导致的延迟爆炸问题。用大白话讲传统模式是主库做完一次饭再把菜谱送到每家分店分店照着菜谱重新做一遍PolarDB 是中央厨房做完饭直接配送到所有分店分店拆开就能卖。后者当然又快又省事。2.3 一写多读扩展只读能力只需要几分钟在 PolarDB 的共享存储架构下一个集群可以有 1 个读写节点和最多 15 个只读节点。增加只读节点不需要拷数据因为数据本来就共享新节点启动后从存储层读取元数据、跟主节点对齐位点几分钟就能开始对外服务。这个能力对 100TB 级别的库来说太重要了。大促、报表季、月度结算这类场景往往是平时读压力不大特定时段读需求激增。传统架构下你要么常年养着一堆从库浪费钱要么在高峰期临时搭建从库来不及且风险高。PolarDB 的做法是平时只留 12 个只读节点大促前 1 个小时加 35 个只读节点峰值过了再缩回去。计算资源按需付费弹性拉满。对于 100TB 的库这种弹性的价值怎么强调都不过分——因为数据量越大你越不可能在物理机上预留大量冗余计算资源等在那里。2.4 多副本存储100TB 数据的可靠性底座100TB 的数据存储可靠性是底线。PolarDB 底层存储采用多副本机制常见部署形态是三副本数据块写在多个存储节点上任何一个节点宕机系统自动从其他副本拉取数据继续服务。而且是强一致的多副本写入机制不是传统的异步复制这样就不存在主库挂了、备库数据不全的经典尴尬。存储节点的故障切换对计算节点是透明的计算节点甚至可能都感知不到底层某个存储节点下线了。这跟我们过去在物理机上提心吊胆地等 RAID 重建完全不是一个体验。3. 三个客户案例100TB 数据规模下的真实战场说明一下下面三个案例的信息我做了脱敏处理行业背景和数据规模是同类型场景的归纳你可以把它们当成三个典型的客户画像来看。这也符合业界惯例大客户案例通常只披露行业和大致规模。3.1 案例一区域银行核心系统从 Oracle RAC 迁到 PolarDB-O某区域性银行的业务系统原本跑在 Oracle RAC 上数据量一路涨到接近 100TB。核心交易流水、客户信息、信贷记录全在一个库里。传统架构下的问题非常典型首先是授权费按 CPU 授权的模式让扩容变得极其昂贵每次业务部门提需求基础设施团队的第一反应都是先算算授权费涨多少其次是容量瓶颈Oracle RAC 节点扩容涉及存储阵列升级、集群配置变更一次完整的扩容周期要以月为单位计算还有备份窗口100TB 的库在没有快照能力的老平台上做备份经常一跑就是一整天把凌晨的维护窗口全部吃掉。他们最终选择了 PolarDB 的 Oracle 兼容版本。迁移过程中最核心的挑战是存储过程、触发器等 PL/SQL 对象的兼容性他们的做法是先用兼容性评估工具做一轮全面扫描把风险点梳理出来再按模块分批迁移。大量常用的存储过程几乎不需要改动就能直接跑极少数用到 Oracle 特有包的地方做了手工适配。迁移之后最直观的变化体现在三个地方备份从小时级变成了分钟级PolarDB 基于存储快照的备份能力让 100TB 库的备份窗口从整夜缩短到几分钟。报表查询不再挤占核心库资源原来报表跑在 Oracle RAC 上高峰期总是和核心交易抢资源。现在单独挂两个只读节点报表、监管报送、数据抽取全部走只读节点核心交易稳如磐石。扩容成本和周期大幅下降增加只读节点是分钟级的操作存储扩容不需要动计算节点授权费这个大头直接消失。3.2 案例二头部电商平台的订单中心从分库分表回归单集群第二个案例是一家头部电商平台。他们的订单中心在业务快速扩张期做过一次彻底的分库分表改造把订单表按用户维度拆成了 64 个分片跑在几十台自建 MySQL 上数据总量接近 100TB。分库分表带来的问题经历过的人都懂跨分片的查询全部废掉运营想按商品维度统计一笔数据要在应用层把 64 个分片的数据捞出来再聚合一条原本很普通的 SQL 变成了一个分布式计算任务。大促期间某个分片的订单量畸高热门商品集中在一个用户分区那个分片就成了整个系统的短板单分片打满其他分片空转。他们后来把订单中心逐步迁到 PolarDB for MySQL 的单集群上。思路是先把新写入的订单切过去再通过数据同步工具把历史分片数据回收到单集群最后把分库分表中间件从链路上摘掉。这个过程他们走了将近半年先双写、再灰度、再全切每一步都有回滚方案。效果也很明显业务代码大幅度简化——分片键、路由逻辑、分布式聚合全部删除跨分片 join 重新变得理所当然。大促弹性变成按小时——大促前加只读节点高峰过后缩回去按量付费。运维复杂度骤降——以前几十台 MySQL 要管监控、管主从、管分片迁移现在一个集群的管控面集中了很多。有个细节我记得很清楚切换后他们的运营团队做了一件以前想都不敢想的事——直接在线上库跑一个跨全量订单数据的统计查询。这在分库分表时代是绝对不可能的但在 PolarDB 单集群上虽然查询本身要花一些时间但它能够稳定跑完并返回结果这在业务侧看来是质变。3.3 案例三车联网平台持续写入的海量轨迹数据第三个案例是一家车联网公司他们的业务特征是所有车辆每 10 秒上报一次位置和状态数据。这个数据模型有几个特点写入是持续的、海量的几乎不存在明显波峰波谷数据总量很快就突破 100TB同时需要按车辆 ID 和时间维度做历史轨迹查询。他们之前用的是自建 MySQL 集群配合中间件做数据分片写入侧拆了几十个分片勉强顶住。但到了某个规模之后问题开始集中爆发历史数据膨胀太快磁盘成本压不住轨迹查询要跨几十个分片响应时间经常突破 10 秒而且每次做按时间维度的归档清理都涉及大量分片的数据搬迁。改成 PolarDB 之后他们的架构做了三件事把轨迹数据按车辆 ID 时间做了分区表设计分区粒度是天。查询轨迹时查询条件带上车辆 ID 和时间范围直接走分区裁剪扫描的数据量从几百 GB 降到几 GB。利用 PolarDB 在线扩存储的能力存储空间的增长不需要停机也不需要预分配。对超过 3 个月的历史明细数据做分层归档明细保留在 PolarDB更早的数据转存到低成本对象存储。冷数据查询走归档通道热数据查询走 PolarDB成本和性能取得平衡。他们的 DBA 跟我说过一句话我印象很深以前我们是追着数据量跑现在数据量追着我们跑但我们不怕了。因为容量上限从物理机的天花板变成了分布式存储池的天花板而且往上扩的每一步都不是伤筋动骨的大工程。3.4 三个案例里的共同结论把三个案例放在一起看100TB 数据管理有几件事是共通的。第一存算分离解决的核心问题是扩展的自由。存储不够扩存储计算不够加节点互不干扰。这个能力在数据量超过 100TB 之后不是加分项而是必需品。第二不同行业的核心诉求不同金融客户看重兼容性和成本电商客户看重弹性和架构简化车联网客户看重容量、写入能力和数据生命周期管理。PolarDB 的三个引擎MySQL 版、PostgreSQL 版、Oracle 兼容版正好对应了不同的存量生态。第三没有哪个项目的成功是换数据库这一个动作完成的。迁移规划、分区设计、只读节点分流、冷热分层归档这些基本功一个都不能少。接下来这部分我就把案例背后的通用操盘经验展开讲。4. 案例背后沉淀出来的通用实操经验4.1 迁移到 PolarDB 的推荐路径全量、增量、校验、灰度如果你手里已经有一个 100TB 量级的库要迁到 PolarDB我的建议是不要想着一夜之间切过去而是走四步走第一步全量迁移。用数据同步工具先把全量数据搬过去这个过程通常会持续几个小时到几天取决于数据量和网络带宽。PolarDB 生态里这一步可以借助数据传输服务来做它支持公网、专线等多种网络环境。第二步增量同步。全量迁移完成后启动增量同步把源库的写入变化实时同步到 PolarDB 目标库。增量同步的延迟要盯好通常稳定在秒级以下才算正常。第三步数据校验。这一步最容易被忽略但恰恰是最重要的。100TB 的数据如果校验不充分切换后发现问题再回滚成本是灾难性的。建议对账的方式是行数校验 抽样字段校验 关键业务表全量校验三层叠加。第四步灰度切换。把读流量先切一部分到 PolarDB观察性能和正确性再逐步扩大。写流量最后切换而且要预留回滚通道在切换后的前 12 周内保留源库只读作为应急回退的保险。4.2 100TB 场景下的扩容姿势在线、按需、不打断在 PolarDB 上扩容这个动作被拆成了两个字扩存储和扩节点。扩存储当集群存储用量接近水位线直接在控制台调整存储上限就可以了。因为存储是底层的分布式共享存储池扩容量不需要搬迁数据业务无感知。你唯一要做的就是关注费用——存储是按量计费的扩上去的容量会立刻产生成本所以存储上限不是设得越高越好而是要有节奏地升。扩节点加只读节点是应对读压力最直接的动作。但要注意只读节点加完之后不是立刻就能承接全部流量它有一个与主节点对齐位点的过程虽然很快通常几十秒到几分钟但大促容量规划时还是要留出这个时间余量别卡着点加。还有一件事值得做给集群设置容量告警水位。比如 70% 和 85% 两道告警线。70% 提醒你开始规划扩容85% 提醒你必须尽快处理别等到 95% 才手忙脚乱。这个习惯在 100TB 量级下尤其重要因为数据增长速度比你想象中快得多。4.3 备份、恢复与大表治理PolarDB 基于存储快照的备份能力是 100TB 场景的大杀器。之前说过传统物理备份跑一天是常态PolarDB 的秒级快照可以让备份窗口彻底消失。但有几个细节要清楚第一快照不等于不用做恢复演练。我见过不少团队备份开得很勤但从来没真正演练过恢复。真到了要恢复的时候才发现对恢复流程不熟、对数据丢失容忍度没有概念。建议至少每季度做一次完整的恢复演练把从快照恢复到新集群做成一个脚本化、可持续的操作。第二按时间点恢复依赖日志的持续归档。如果你的业务对恢复时间点有比较苛刻的要求要确认日志归档的保留周期和完整性别等技术团队真出了事才发现日志断了好几天。第三大表治理是 100TB 数据量下躲不开的课题。强烈建议在数据模型设计阶段就做好分区规划。比如按照时间做日/月分区辅以分区裁剪查询性能和数据管理归档、删除都会受益。一个可以落地的做法是超过 100GB 的表必须有分区策略超过 1TB 的表必须评估冷热分层方案。4.4 慢查询治理百 TB 规模下的索引纪律100TB 数据量下一条没有走索引的查询会直接把数据库资源打满这是所有 DBA 的噩梦。在 PolarDB 上慢查询治理的优先级比传统架构更高——因为数据量更大一次全表扫描带来的代价更恐怖。我的经验是做好三件事开启慢查询日志和性能洞察把超过阈值比如 1 秒的 SQL 全部抓出来按频率和耗时排序逐条分析。对核心链路的 SQL 做定期的执行计划巡检重点关注有没有因为数据分布变化导致执行计划漂移。建立新 SQL 上线前必须过执行计划评审的流程。这个流程在 100TB 规模的业务里不是繁文缛节而是保命用的。5. 哪些业务适合上 PolarDB 存算分离一份诚实的选型建议5.1 适合的场景数据增长快、读写不均、受制于存量架构综合前面的案例我把适合的场景归纳成四类。第一类是数据量已经或即将跨过单机天花板的业务。单机 MySQL 或 RDS 单机实例存不下、扩不动又不想立刻承受分库分表的业务改造代价PolarDB 是比分库分表平滑得多的替代方案。存算分离把容量上限从物理机提升到了分布式存储池绝大多数业务在 100TB 以内都不用再考虑拆库。第二类是读写严重不均的业务。报表、BI、监管报送、数据分析这类读密集场景叠加在核心交易库上传统架构下只能互相拖累。PolarDB 的一写多读能让你用几个只读节点把读写隔离开各走各的节点各用各的资源。第三类是想要摆脱商业数据库授权费包袱的企业。Oracle 兼容版让这类客户可以在不大改应用的前提下迁移存储成本和授权成本的对比是肉眼可见的。第四类是流量有明显波峰波谷的互联网业务。大促前加只读节点、大促后缩容按量付费成本可控。这在固定物理机架构里是完全做不到的。5.2 不建议的场景数据量太小、需求太特殊也不是所有场景都适合上 PolarDB。我建议下面这几种情况要谨慎。第一数据量连 100GB 都不到的小型应用。存算分离的优势需要在足够的规模下才能体现小数据量跑在 PolarDB 上成本未必比单机实例划算反而是杀鸡用牛刀。第二对某些冷门数据库版本、插件有强依赖的业务。比如用了某个只有特定社区版才支持的插件或者有自己的深度定制内核需求。虽然 PolarDB 对 MySQL 和 PostgreSQL 生态的兼容性已经很好但要先做详细的兼容性评估再做决定不能拿关键业务赌应该没问题。第三原本就是强事务、低并发、数据量小的内部系统。这种系统直接在单机数据库上跑得很好迁移的成本和风险反而超过了收益。技术选型最忌讳的就是因为别人都在用所以我也要用。5.3 几个容易被忽略的坑最后分享几个实际使用中容易被忽视的地方。第一个坑是只读节点一致性的理解。PolarDB 只读节点基于 redo log 回放正常情况下延迟很低但它仍然是最终一致的模型。如果你的业务有写完必须立刻读到的强一致读需求需要走主节点或者使用会话一致性能力。做读写分离时一定要在代码层面区分哪些 SQL 必须走主库这是很容易被忽略的隐性坑。第二个坑是连接数管理。PolarDB 集群的计算节点有连接数上限在大量应用连接池配置不当的情况下可能还没到性能瓶颈就先触达连接数上限。建议把应用侧连接池的 max 值收敛到一个合理范围并开启连接复用。第三个坑是数据归档不能停。100TB 不是终点数据还在增长。即便容量上限撑得住成本和性能也不会允许你把所有数据都留在热库。所以冷热分层归档要作为长期的运维制度来做而不是等到存储爆了才想起来。第四个坑是别迷信容量上限。PolarDB 单集群容量虽然能做到 100TB 级别但超大规模的单库对 SQL 质量、分区策略、索引设计的要求都非常高。容量上限只是安全网真正决定你能不能用好 100TB 数据的是你日常的治理功夫。我自己在实际项目中看到过太多团队在数据量冲到几十 TB 时才想起做架构升级那时候能选的方案和从容度跟 5TB 时完全不一样。我的建议是如果你的业务增速够快与其等数据量把旧架构逼到墙角不如趁现在就把存算分离这条路摸清楚——先在非核心业务上验证再逐步扩大范围。技术选型这件事最贵的选择往往不是买错了工具而是错过了从容决策的时间窗口。希望这篇案例拆解能帮你少走一些弯路。