按图索骥,再谈数据库迁移之路

本文转载自 韩锋频道  作者:韩锋

数据库迁移,是个老生常谈的问题,之前也曾写过一篇文章。近期,针对这一课题,自己有了些新的思考,下面将具体展开谈谈。在这之前,我先谈谈数据库迁移的现实需求。这也算是目前行业发展的一个小总结。




1. 背景:迁移之源,多变之秋


     人生基本上就是两件事,选题和解题。最好的人生是在每个关键点上,既选对题,又解好题。人生最大的痛苦在于解对了题,但选错了题,而且还不知道自己选错了题。正如人生最大的遗憾就是,不是你不行,而是你本可以。



❖ 数据规模大幅增加

近些年来,信息数据呈快速增长态势。如下图所示,全球数据量总和,预计将从 2018 年的 33ZB 增至 2025年的 175ZB。国内数据体量在未来 7年将实现复合增速 30%以上的快速增长,并在 2025年成为与欧洲、中东、非洲、亚太和美国等地区相比体量最大的区域。数据的爆发式增长,导致对数据存储容量、数据计算需求有个更好的要求,这也催生企业在基础设施层面不断革新,进而不断推动数据库向前进一步发展。

从数据库市场来看,也验证了这一趋势。整体市场呈现稳定的发展趋势,最近的数据表明,国内的数据库市场已经达到200亿规模。

❖ 开源方案,大行其道

开源数据库,其源代码具备全球共享、免费等特点,开发者可在其源码中修改或使用。在近一、二十年来,越来越多的企业将开源方案作为构建底层支持的可选答案。特别是随着互联网的兴起,大量互联网企业选择使用了开源数据库产品,也加速这些产品的成熟与发展。这其中MySQL、PostgreSQL、MongoDB 和 Redis 是当前开源数据库最为重要的参与者。


❖ 数据上云,大势所趋

从2017至 2018年,整个数据库市场增长了 18.4%,其中云数据库增长贡献 68%。以AWS、Microsoft、Alibaba为代表的云厂商,取得了快速发展,极大地重塑了全球供应商格局。国内互联网科技巨头,纷纷布局数据库产业,借力云计算实现数据库等基础软件领域的迭代与超越。如下图的数据库规模排名,云数据库厂商均取得不俗的增长,最新数据则更是如此。甚至有机构预测,今明两年从数据库部署形态上看,云部署数据库会超过传统部署方式。

❖ 国产化趋势明显

正如下图所示,国内数据库市场仍然为欧美垄断,但国产化趋势已非常明显。以国产自研或开源定制路线的厂商层出不求,从最新的调查结果来看,已经有130+的国产数据库厂商初选。

从一叶扁舟到百舸争流,传统国产数据库历经长时间艰难探索,已逐步崭露头角。国外大厂长期垄断国内数据库市场。Oracle、IBM 和 Microsoft 等老牌厂商凭借先发优势在市场份额中占据了有利地位。国产数据库起步较晚,但潜力巨大。正如下图可见,国产数据库占比正不断增加。

❖ 总结:多种变化,驱动迁移

综上所述,从数据规模体量的增大,到开源商业的变化,再到云化趋势明显、国产化趋势加剧;而这些变化都带来同一个诉求,那就是数据库迁移。展开来说,是如何完成异构数据库迁移?完成体系架构完全不同的数据库之间的迁移(例如从单机到分布式)?完成从线下到云上的迁移?完成在线的、不终端业务的迁移?等等。诸多上述问题,对迁移提出了非常高的要求。本文下面尝试从迁移的多个阶段来阐述,需要哪些能力才能完成这一过程。






2. 数据库迁移之路


     人生基本上就是两件事,选题和解题。最好的人生是在每个关键点上,既选对题,又解好题。人生最大的痛苦在于解对了题,但选错了题,而且还不知道自己选错了题。正如人生最大的遗憾就是,不是你不行,而是你本可以。



在实际的迁移中,是一个比较复杂的过程,可根据阶段做个拆解。

1).迁移评估阶段

此阶段是完成迁移前的评估,为后续迁移改造、迁移过程做好铺垫工作


❖ 数据库画像

数据库画像结果,可为后续选型评估、架构规划提供依据。

  • 系统级

    收集系统级信息,包括但不限于硬件(CPU、MEM、NET、DISK)、操作系统(内核、参数、安全策略等)、性能(系统高峰期24小时负载)等

  • 实例级

    收集实例级信息,包括但不限于架构(单机/集群、版本等)、参数(数据库参数等)、数据规模(表、索引等空间使用)、运行态信息(如QPS、TPS、会话、事务等)

  • 对象级

    收集对象级信息,包括但不限于结构信息(表、分区、分片、索引、视图、序列等)、统计信息、访问特征(读写比、频率等)、预警类(如大表、复杂结构、DBLink等)

  • 语句级

    收集语句级信息,包括但不限于SQL文本(全量)、执行特征(次数、响应时间等)、执行计划。

  • 应用级

    收集复杂应用信息,包括但不限于计算文本(如存储过程、触发器、函数等)、 执行特征(次数、响应时间等)


❖ 应用画像

应用画像结果,为后面应用改造做好铺垫。

  • 应用拓扑

    收集应用架构、应用与DB关系、应用访问特征等。


❖ 风险评估

针对上面收集的数据库、应用画像信息,针对重点风险点做出评估。


  • 数据库架构

    源库使用集群、分库分表等架构,做出提示。

  • 数据库结构

    源库使用复杂结构(如分区表)、不支持结构(LOB、可更新视图等),做出提示。

  • 数据库语句

    源库使用复杂SQL(如多表关联)、特殊语法或方言等给出提示。

  • 数据库应用逻辑

    源库大量使用存储过程、触发器、函数等。

  • 应用架构

    应用使用何种访问方式(如java、c、go等),对于某些旧有的方式予以提示。

  • 性能维度

    源库存在明显的性能访问高峰,明显的热点对象。

  • 规模维度

    源端数据库总体或单体对象规模较大的情况。

❖ 选型建议

根据上面收集信息及风险评估内容,给出选型的建议。这里存在几个难点,一个是多目标数据库的基础能力抽象,一个是两者的适配评估。功能上包括两部分:

  • 目标端建模

    目标端在架构、结构、应用、性能指标等方面的基础抽象。

  • 评估适配建议

    根据源端和目标端情况,结合风险及性能要求给出适配选型建议。

2).迁移改造阶段


❖ 对象改造

这一阶段主要是通过结构映射及不兼容提示,来减少改造工作量。

  • 映射规范

    适配多目标端给出结构映射规范。

  • 结构改造

    基于给定输入,输出改造后结构。可能存在非一一对应的情况,可根据源与目标的差异,异构改造。

  • 不兼容提示

    对于不兼容的情况,给出文字提示,人工介入。


❖ 语句改造

这一阶段主要通过语句改写,减少改造工作量;同时提供增强功能,满足语句改造后的测试等需求。

  • SQL改造

    基于给定输入,给出改造后的语法。

  • 不兼容提示

    对于不兼容的情况,给出文字提示,人工介入。

  • 增强-执行计划对比    

    可对比两边执行计划,方便研发优化语句写法。

  • 增强-性能对比

    可对比两边执行效率,方便研发优化。此处需保证同等测试环境。


  • 增强-SQL自主优化

    提供优化改写能力,而非基于简单规则。此处需注意,语义等价性问题。


❖ 应用改造

此处应用是指数据内置的计算能力(如存储过程等)。这一阶段主要是通过逻辑改写,减少人工工作量。在实现上,一般建议使用外部程序逻辑(如java)进行处理,而不是改造为目标端内部计算应用。原因是尽量减少数据库耦合。此处,存在较多难点,且需要人工检查改造后的语义是否正确。

  • 应用改造

    基于给定输入,给出改造后的实现(推荐java)。

  • 不兼容提示   

    对于不兼容的情况,给出文字提示,人工介入。

  • 应用校验      

    对比两侧的实现,验证处理逻辑是否一致。

3).迁移数据阶段


❖ 全量/增量数据迁移

完成异构数据库间的数据迁移工作。主要难点是效率、准确性。

  • 全量迁移

  • 增量数据迁移

    基于指定时间戳后的增量迁移能力

  • 增强-分拆、合并能力

    支持一拆多,多合一迁移能力。

  • 增强-迁移计算能力    

    支持在迁移实时计算能力(如lookup)。

  • 增强-通用异构适配能力    

    统一迁移能力,不依赖某种库。

  • 增强-提供可配置UI    

    提供可配置同步界面,简化操作。

  • 增强-数据转换能力    

    提供字符集、时区等转换能力。


❖ 数据对比

见后面说明

4).在线运行阶段

❖ 数据同步

在线运行时,需提供数据库端的异构同步能力,满足业务随时回迁的需求。

  • 实时同步

    提供异构数据库间数据实时同步能力,难点在于大吞吐、实时性。

  • 增强-细粒度同步

    支持库、用户、表同步能力。

  • 增强-同步计算能力

    支持在同步的实时计算能力(如lookup) ,难点在于效率。


❖ 数据对比

数据对比,是用户对比双线运行的基本要求,需要满足实时对比并兼顾效率。

  • 异构对比

    提供异构数据源之间全量、增量数据对比能力。

  • 增强-细粒度对比

    支持库、用户、表、记录级别对比能力。

  • 增强-数据补差

    提供差异数据的双向补齐能力。


❖ 数据路由

数据路由,为业务提供统一数据库访问入口,并基于此提供双路控制能力,可做到按流量、按读写、按访问类别(生产、测试)等做数据访问路由。


❖ 基础运维

此部分的能力比较多,本质就是同时提供异构数据库在线同步运维能力。例如包括统一变更、统一导入导出、统一授权、统一审计等。尽量从运维侧角度来看,后面是一套逻辑库。

你可能感兴趣的:(按图索骥,再谈数据库迁移之路)