陆金所花了18个月把PB级的数据从Oracle系统迁走，这个过程中系统的使用者并没有感觉到任何变化，这让整个迁移显得格外顺利。起因要从2013年说起，那时候交易量暴涨，原来的Oracle架构在扩展性和成本上碰到了墙。单机的存储容量不够用了，授权费还越来越高，监管部门的要求也变得越来越严。最关键的是，业务已经扩展到了基金、网贷、信托、资管、银行理财、证券、保险还有主账户这些全金融场景，只用一个系统应付这么多不同的需求显然已经力不从心。所以，一场自力更生的“去Oracle”大迁徙就这么开始了。 为了这次大迁徙，公司召集了500人一起战斗。首先，大家没有直接动手碰核心数据库，而是先在一些边缘的、流量比较小的地方做测试。他们用了6个月的时间跑通了MySQL、Elasticsearch、Redis、TiDB和HBase这套多引擎的组合方案。大家验证了SQL的语义能不能兼容，事务是不是一致，监管指标合不合格，确认没问题后才开始大面积推广。 接着，公司搭建了一套自动化工具链来帮忙干活。这个工具链可以逐条检查SQL语句和接口，生成替换方案清单；还能在DAO层和动态数据源之间一键切换读写来源；它能把Oracle的DDL和DML命令实时同步到MySQL的备库里；最重要的是如果要回滚到Oracle上，它也能反向同步数据保证两边一致。有了这套工具链，团队在接下来的12个月里把几百个子系统、90%的数据库还有PB级的数据都迁走了。整个过程中功能版本不停地在上线更新，但业务部门完全没感觉到任何变化。 技术上之所以这么顺利，是因为公司采用了“一主多辅”的混合存储方案。核心的交易业务还用MySQL和InnoDB做主库来扛高并发；全文检索用Elasticsearch来处理资产搜索；高频读写的订单号和用户ID用Redis做缓存热点；大事务表就交给TiDB来代替Oracle；日志和画像这种非结构的大容量冷数据则交给HBase去存。这种分层设计既保留了Oracle的兼容性，又让每个引擎都能在最擅长的领域发挥作用。 为了防止迁移过程中出现服务降级的情况，公司用了一个叫做“流量剪刀差”的策略。先让一部分表只读MySQL的数据，其他表还是走Oracle；然后把高频的写操作和事务型写操作切到MySQL上；等到低峰时段的时候再一次性把所有表切换过去；最后反向同步一下Oracle确保监管指标可以追溯回来。整个过程中业务没有感知、数据没有丢失、指标也没有超标。 总结下来有三点经验值得借鉴：先从边缘的小场景试起避免风险；先把自动化平台搭建起来代替人力劳动；多引擎互补才能让合适的技术做合适的事。未来公司还打算统一数据模型、开发框架和运维监控，把这些分散的数据库能力封装成金融级数据底座，为AI风控、实时资产图谱还有多资产投研提供统一的支撑。这场长达18个月的PB级迁徙不仅帮陆金所甩掉了Oracle的包袱，也让公司提前布局好了下一阶段的金融科技赛道。