最近涉及信创的事情很多，也有很多小伙伴和我讨论信创数据库转型需要注意哪些问题。其实最后涉及到的问题包括两个方面，一个是模型选择，一个是迁移。从Oracle到国产和开源数据库的数据迁移目前其实已经比较成熟了，有大量的工具可以使用。当然，数据量大的业务迁移还是有一些工作量的，但还是可以克服的。其实我们目前遇到的最大的问题就是选择的问题。国内数据库太多，选择困难。其实很多数据库的选型可能有些偏差，大家过于关注TPCC、TPCH等测试可能对实际选型影响不大。每个数据库供应商都会很好地优化这些基准测试，因此您实际上无法从这些测试中获得很多有价值的数据。其实在选择数据库的时候，我们还是要从迁移成本、使用成本、复杂的业务支撑能力等方面入手。其实最需要测试的第一个方面就是与Oracle的兼容性，因为我们大部分人都想把系统从Oracle迁移过来。与Oracle的兼容性越好，迁移成本越低。兼容性测试只需要关注一些特殊的SQL语法、窗口/统计函数、常用函数、SEQUENCE、PL/SQL存储过程等，除了兼容性，第二重要的因素就是高可用。高可用性是保证业务SLA的关键。高可用切换方案能否满足业务SLA的需求，切换能否实现自动化，切换是否流畅，都是需要慎重考虑的问题。实验性的。而且这种测试往往需要在一定的负载下进行，甚至是高负载。第三个重要特性是备份和恢复。虽然所有的数据库都支持备份和恢复，但它们的能力差异很大。备份和恢复操作是否顺畅，与磁带库和虚拟磁带库的兼容性，与常用备份工具平台的兼容性，都是需要考虑的因素。此外，备份和恢复的粒度，是否支持表级甚至块级的恢复也是一个关键的考虑因素。可靠性测试不好做，需要耐久性测试。要想在有限的时间内从耐久测试中发现问题，对测试用例的要求是非常高的。此外，我们还必须密切关注一些CBO优化器问题。原生的PG数据库和Oracle在HASHJOIN等高级表连接上有一些区别。虽然PG也支持HASHJOIN，但是在某些场景下，PG对HASHJOIN的支持并不完善。比如下面这个场景：我们创建两个表，执行一个or表连接条件的查询，会发现执行计划并没有使用HASHJOIN，而是使用了NESTEDLOOP。而如果去掉Or的表连接条件，又回到性能更好的HASHJOIN连接方式。当表的数据量很大时，这两种连接的性能差别很大。我们将这个测试用例应用到国内一些基于PG的数据库中，得到的结果是相似的。例如，在openGaussv3上，我们得到了类似的结果。如果我们的应用程序中有这样的SQL，我们该怎么办呢？只能重写，拆分这些SQL或者使用UNION语句重写。正好手头有一套OB4.0的环境，测试了一下，执行计划是这样的：OB在CBO优化器中自动改写了这样的SQL，在执行计划中看到了UNION操作。国内的数据库还存在很多这样的问题。所以，在做选择的时候，最好把自己ERP、SCM、仓储、财务等系统中一些比较复杂、数据量大的SQL提取出来。对要选择的产品做一些测试，或许能得到比比较更有价值的数据。原文地址：https://mp.weixin.qq.com/s/rN98qdecM2R3HTJ0SsQJjA
