换数据库不是「换数据库」：度小满400亿条数据迁移背后的架构重构

📰 概要

换数据库，听起来就是把"往A写"改成"往B写"。

但度小满金融在2026年4月29日分享的经历告诉你：这个认知害死人。

他们从Eggroll迁移到OceanBase时，发现OceanBase原生提供的入库方式是一个本地脚本。没有分布式调度、没有弹性伸缩、没有高可用保障。

直接用它跑日均数百亿级别的入库？不可能。

他们的选择是：基于Kubernetes重建入库服务。结果：吞吐从400万条/秒提升到800万条/秒，峰值达到1000万条/秒。

OceanBase原生obloader有三个致命短板。

第一个是远程文件"两段式"搬运。数据存在远程对象存储DGS上，脚本只认本地文件，必须先下载再导入。大批量场景下可能撑爆磁盘。

第二个是海量文件"各自为战"。几千个文件的入库任务，脚本之间无法协调。全靠"人肉调度"：提高吞吐？多开几个脚本。想降压力？手动关几个。

第三个是稳定性"裸奔"。没有进程守护、没有故障恢复、没有重试机制。脚本异常退出，任务就中断，需要人工介入排查。

这三个问题，每一个都需要重新设计架构才能解决。

度小满的工程师说得很清楚：答案不是在脚本上缝缝补补。

脚本的局限是结构性的：它是单机的，无法横向扩展；它是同步的，无法并行执行；它是无状态的，无法故障恢复。这些是"脚本"这种形态的原罪，不是参数调优能弥补的。

要把入库能力从"脚本"升级为"服务"，意味着从底层重新设计。

度小满从三个维度重构。

远程直读，消灭中转。入库服务直接对接对象存储，支持DGS协议远程读取文件。

分布式调度，代替人肉协调。入库任务通过K8s调度能力自动分配。

弹性伸缩，按需扩缩容。入库高峰期自动扩展Pod数量，低峰期自动收缩。

吞吐翻倍，不是靠堆机器换来的。

远程直读消除I/O瓶颈。分布式调度消除单点瓶颈。弹性扩缩容消除资源瓶颈。三层优化叠加，才实现了翻倍的效果。

什么情况不建议照搬这套架构：如果你的数据量在百万级以下、入库时间窗口充足、错误容忍度高，K8s重构的工程成本可能大于收益。这种情况不建议用这套架构。

但如果你的场景涉及：日均亿级以上数据入库、严格的SLA要求、7×24小时运行——度小满的经验值得参考：换数据库，本质是换架构。