数据库迁移SQL语句兼容问题如何高效处理？——关于国产数据库应用的一些难点探讨

twt企业IT社区 2022-07-27

637

传统企业现在的系统绝大多数还是运行在Oracle，Db2等国外商业数据库上，随着近些年来数据库的变化，国内信息系统所采用的关系型数据库正逐步向国产数据库、分布式国产数据库方向转型。然而不同数据库的特性有差别，SQL语法也有很多差异，因此在迁移数据库的过程中不仅涉及数据的迁移，还包括应用的适配改造。本文从社区近期的交流中选取部分相关探讨，分享给大家以供参考，也欢迎更多同行到社区交流。

1、是否有必要用分布式数据库？什么场景、系统建议用分布式数据库？

@wanglaye 某大型金融机构信息技术经理：

从实践的角度总结几点建议，供参考：

传统稳态类系统都已经在集中式数据库上跑了很多年，进行分布式改造是件非常谨慎的事情。如果要提高性能和可用性，可以采用业务拆分的方式，将业务分布在不同的应用节点上，每个应用节点有自己的传统数据库。这种架构也在某种意义上实现了分布式。性能方面可以对每个应用节点及对应的数据库进行扩容；可用性方面，由于业务进行了拆分，当某个业务节点发生故障时将这个业务节点隔离，将请求导向其他节点，这部分工作可以通过自动化运维平台实现自动切换。

何种场景选择分布式数据库，可以考虑这些因素：

交易量规模是否很大。
交易是否有明显的周期性。周期性的交易系统很适合分布式数据库，利用弹性伸缩能力灵活调度资源。
预算。分布式数据库对硬件需求较低，节省硬件成本。有些情况选择分布式数据库，是为了适应技术发展趋势，作为试点。也是需要额外的预算支持。
业务系统架构。分布式架构与分布式数据库搭配使用。

@yata52 某大型保险数据库管理员：

对于信创改造过程中，使用集中式架构出现性能瓶颈的系统，可以考虑使用分布式数据库来尝试解决。

@huawei851120 某省农信数据库运维工程师：

世人都说高并发数据量大的系统适合用，可这些系统往往都是重要性高的系统。如果单位没有足够的人力和物力投入的话，还是建议先用交易量小重要等级低的先用国产数据库。

2、分布式数据库底层存储，选择集中式存储还是分布式存储，怎么选择？有哪些考虑因素?

@annoymous：

目前市面上已经有好些专门做数据库底层分布式存储架构，即使传统数据库也可以采用底层分布式架构；分布式数据库大部分本身就已经具备分布式存储架构，具有冗余性，再采用集中式存储就没有必要。

@yata52 某大型保险数据库管理员：

分布式数据库使用集中式存储，随着分布式数据库存储节点接入增多，单台存储节点的IO性能必然出现下降。而如果使用服务器本地的SSD磁盘作为分布式数据库的存储，那么单台存储节点的IO性能不会随着节点增加而出现性能下降。

同时目前随着技术的发展，目前服务器本地使用NVME接口的SSD时，性能已经达到甚至超过了集中式存储。所以对于新建系统且新购服务器时，建议直接使用服务器本地存储。

@huawei851120 某省农信数据库运维工程师：

基于分布式中间件架构的国产数据库，交易直接用裸金属服务器部署，就是在物理机上部署。云原生数据库基于云的平台的分布式存储。国产数据库的技术路线不一样，用的存储也不一样。

3、在表结构，业务重构的情况下，如何进行数据迁移，确保安全准确？

@hanfeng_twt SphereEx 数据库架构师：

数据迁移的方案，从大的分类上有三种：

1.基于数据的逻辑迁移

这种方式的适配范围更广，适配场景多，但迁移效率一般较差其对库表结构有要求。

2.基于日志的物理迁移

这种方式的实时性较高，但需做更多的适配性工作。

3.基于应用的数据迁移

这种方式属于定制方案，需要应用侧解决数据迁移问题。效率中等，可加入定制策略。

在保证数据安全方面，可通过数据校验完成。一般的迁移都支持离线的校验，原理是通过某种算法对部分或全部字段实现校验；或者通过采样统计的方式完成。

4、分布式数据库数据离线保存需求如何满足？

【问题描述】在分布式数据库中，已经有多副本冗余，也有类似于Oracle的rman备份，是否有必要逻辑导出备份？否则如何满足监管数据离线保存需求？

@yata52 某大型保险数据库管理员：

部分分布式数据库物理备份恢复期间需要将全量备份集拷贝到所有存储节点，或者以NFS方式进行挂载。而逻辑备份相较于物理备份，恢复限制条件更少，任意计算节点均能完成恢复，而且通过binglog备份也能实现数据前滚，相对更灵活。

5、数据库迁移SQL语句兼容问题如何高效处理？

【问题描述】从传统数据库迁移到国产数据库中，如果出现sql语句的兼容问题，比如说迁移之后，原来正常的sql变成了慢sql，这样的情况怎样高效处理？

@yata52 某大型保险数据库管理员：

上线前做好充分验证，通过功能测试、性能测试将出现的性能下降模块进行分析调优。利用Oracle自带的SPA等工具统计高频SQL，并在国产库中回放对比效率差异（部分国产库已支持SPA回放）。上线后利用APM监控工具实现SQL级监控，发现一条优化一条。

@huawei851120 某省农信数据库运维工程师：

1，迁移之前，要请真正有经验的专家对SQL全部摸排一遍，全部的SQL！

2，投产前要经过测试，尤其是并发高的交易场景进行压力测试。

6、对于分布式数据库在多表关联、聚合查询性能偏弱的问题，有什么思路吗？

【问题描述】在分布式数据库的实际使用中，在充分利用分片将表进行分片处理后，从实际使用过程中可以发现，对于复杂查询、多表关联、聚合查询等这类较为复杂，涉及表较多的SQL，分布式数据库的查询性能比较差，对比传统集中式的Oracle仍没有优势。现在主流的思路是，将这类处理交由程序去解决，数据库仅作简单的SQL处理，这种用法已经渐渐的趋于KV数据库的使用思想了，那么这种思路合理吗？当然，现在是个厂商都在吹HTAP，假设分布式数据库HTAP技术能在三年之后趋于成熟，那么对我们现在分布式数据库的使用习惯和程序开发思维，又有哪些启发？

@wanglaye 某大型金融机构信息技术经理：

我们在实践中，也遇到过类似的问题，比如分布式数据库对于存储过程不支持。由于原来使用了Db2，把一部分应用逻辑放在了数据库的存储过程里。我们的做法是，把逻辑交回给应用，应用做代码改造。题主这一具体问题，我们还没有遇到，所以无法给出实践参考。

不过，从我们的实践角度出发，引入分布式数据库后，代码改造是不可避免的，目前不可能平滑100%兼容，所以原来对于Db2等传统数据库的习惯，势必要改的。所以，在引入分布式数据库之前，建议充分评估兼容性，和代码改造量，评估是否可接受。否则，一旦引入后再去推动代码改造，又是一番问题。

最后一个问题，我们从运维的角度出发，给DBA提供了一些转型建议：

1 、制定规范和标准，降低运维风险

例如把升级、上线、备份、迁数等工作整理成标准模板文档，形成运维资产随时调用；或更进一步地，把数据建模和数据库设计、容量规划、 SQL 开发、高可用架构设计等工作整理成规范文档，面向所有数据库开发人员提供咨询指导。

2 、借助运维工具，发展自动化、平台化运维

常规序列化操作如安装、巡检、升级、备份等，借助自动化运维平台；以往通过手工更新的数据库配置信息表交给配置管理系统来管理；数据库的监控告警可以利用近几年大热的 Prometheus+grafana 技术进行配置，或者引入商用产品建设数据库监控平台或数据库性能分析系统；等等

3、主动拥抱新技术

自主搭建一套测试环境进行学习实践是转型的开端。

4、懂技术，也要懂业务和管理

数据库运维人员一定要从项目前期调研就开始参与，因为项目前期所进行的调研、需求、 poc 测试是了解新技术的第一步，可以最快速地了解市场主流技术和应用现状。到了项目建设期，就更需要技术和管理的复合型人才了，数据库运维人员自身已经有了技术实力，更能方便地把业务需求与实践相结合，利于项目成功落地。项目建成后进行新技术推广时，技术人员的优势又能进一步凸显，因为无论是何种新技术的推广实施，一定要先制定完善的技术升级规范，提前做好测试。

@hanfeng_twt SphereEx 数据库架构师：

个人观点：

1.尽量简化数据库的使用，特别是在分布式架构下，一方面可以减少复杂度，一方面减少可能的抖动。

2.纯原生分布式架构处理复杂查询，较分库分表的还是有优势的，可以在一定程度上解决部分复杂分析问题。

3.Oracle的优化器及软硬一体能力，表现比国产库好很多，这是短期内无法改观的。

4.更为复杂的查询需求，可考虑仍然使用ETL+MPP或流式查询来解决。

5.HTAP的实现能力，各产品有差异；对于开发上要有针对性的设计。