MySQL 国产化替代观察

字数 5256阅读 1315评论 0赞 1

内容摘要：

MySQL5.7停服，需考虑国产化替代方案，综合考虑自身情况选择。国内开源方案更平滑，如GreatSQL、PolarDB-X等，提升高性能、高可用、易用性、安全性，为用户提供更好的选择。

当前摘要为AI生成

近期在中国信通院主办的 2023 OSCAR 开源产业大会上，发布的一份《开源数据库生态发展研究报告》吸引到我。这份报告是中国信通院旗下的云计算开源产业联盟写的，比较权威。报告针对最为流行的开源数据库-MySQL 发展现状、技术创新、产业应用三方面梳理了发展情况，并对我国基于MySQL技术路线的开源数据库产业进行展望。报告根据 MySQL 开源数据库5.7版本生命周期即将结束，结合在金融、电信、能源行业的情况，阐述了用户在数据库替代和迁移选型过程中所考虑的诸多因素及可能的技术选型方案。针对这一报告，也谈下我的一些观点。下文图未做特殊说明的，均取自上面的研究报告。 完整报告参考[阅读原文]。
##1. 大背景：MySQL 5.7 即将 EOL 
### 1).MySQL 5.7 EOL 
 EOL，即生命周期结束（End of Life）。根据Oracle官方信息，到了2023年10月，MySQL 5.7将迎来其生命周期的终结，也就是俗称的“停服”。这意味着该版本将不再获得更新或安全补丁，同时也意味着各个行业使用MySQL 5.7数据库的业务系统将面临多种潜在风险…
![](/home/attachment/202403/14/1228765_171040295179313.PNG)

数据库停服，意味着一系列的问题，包括在安全漏洞修复、稳定性、安全性、软硬件环境适配、运行维护支持、生态系统萎缩及使用开源 MySQL 本身可能带来的合规性风险等。
### 2).MySQL 使用现状
 报告中也谈到了MySQL在国内，特别是5.7版本的使用情况。作为最为流行的开源数据库，MySQL在国内有大量的装机量，从全球占比来看，中美占据半壁以上。而作为最为流行的版本，MySQL5.7在众多版本中也是占比最高的。报告中以金融行业为例，说明了MySQL 5.7的使用情况。
![](/home/attachment/202403/14/1228765_171040305387517.png)

## 2. 国产化替代选型考虑因素 
### 1).选择开源 MySQL理由 
 从上面的数据可见，MySQL 在国内有着巨大的使用量，不仅仅在互联网行业，其他行业也同样有着广泛的使用。那为什么大家如此喜爱这一产品？这也是后面我们在考虑国产化替代上需要关注的因素。报告中同样给出了一组调查数据。
![](/home/attachment/202403/14/1228765_171040311447254.png)

从数据中不难发现，开源和生态是用户选择这一产品最为主要的两个因素。一方面软件开源大大降低了使用门槛，可以让用户快速了解使用产品；同时也可吸引到大量开发者来为之贡献，实现软件迭代闭环，促进快速发展。这也是国内很多数据库厂商纷纷采用开源策略的初衷。另一方面，完善的生态体系促进了产品发展，上下游生态产品将有助于用户快速开发、使用这一产品，降低使用难度。这也是国内大部分产品的短板——还没有形成较为完善的生态体系，因而大多采用的兼容方式，已借用相对成熟的生态体系。由此可见，国内很多产品都提供了 MySQL 的兼容模式，正是基于此。
### 2).使用 MySQL 的主要问题
 当然，使用开源 MySQL 也并非是完美方案，同样面临很多问题。这也是希望未来在 MySQL 的替代过程中能够解决的问题。报告中也收集到用户吐槽的一些问题。
![](/home/attachment/202403/14/1228765_171040314453674.png)

这些问题中主要是来自两个方面，一是开源软件所带来的问题，主要是运行维护、协议合规等问题，这些都是开源软件在企业内使用的常见问题，对于非国内开源的软件，问题更为凸显；二是 MySQL 软件自身在功能、性能、稳定性等方面的问题，这也是企业选择开源的一个风险，无法像使用商业软件一样，可以跟厂商有较为紧密的互动、获得稳定的技术支持。
### 3).替换 MySQL 5.7 的考虑因素
 鉴于上面谈到的 MySQL 5.7 即将停止服务，那么如何替换就成为很多企业需考虑的问题。在选择具体技术方案之前，首先看看用户在面对替换时优先考虑哪些问题。报告以金融行业为例，收集了用户在替换时需考虑的几个因素。下文我将这些因素逐一展开说明。
![](/home/attachment/202403/14/1228765_171040320186958.jpg)

## 3. 替代主要技术路线及产品 
### 1). 替代技术路线选择 
 通过上文可知，替换数据库需要考虑诸多因素，那当前用户是如何选择的呢？报告以金融行业为例，收集来自用户的的反馈。从下图所示的用户选择来看，替换为国产数据库是主流的选择，选择升级到8.0次之，仍然冒险使用 5.7 版本很少。
![](/home/attachment/202403/14/1228765_171040323513209.png)

既然替换（含升级）是用户的主流选择，那么当前可支持 MySQL 替换的技术路线有哪些呢？报告中明确指出有三种可行的技术路线：
* 迁移到 MySQL 支持版本，如 MySQL 8.0
* 迁移到国内的 MySQL 开源分支
* 迁移到国产商业数据库

### 2). 主流技术方案对比
 这里结合上文谈到的用户在面对替换场景优先考虑的这些因素，针对这三种可行的技术路线，做了个简单的雷达图分析。图中的维度对比是来自上文的考量因素。图中由内到外，对应迁移难度从难到易、成本由高到低、其他因素均从内到外为高到低递减，也就是说越靠外侧，越是优选之策。那么从下图可以看出，国内开源方案相对比较均衡，且全面优于升级到8.0版本的方案，后者在长期发展上有优势。而与国产商业数据库对比来看，后者的优缺点更加鲜明，部分对比项上有明显的优势，但同样也存在明显的劣势，主要表现在成本及兼容性上。因此用户如何选择，需综合考虑自身的情况。下文将重点对比下各个维度。
![](/home/attachment/202403/14/1228765_171040326863242.png)

❖ 迁移难度
 迁移难度，是大部分用户在国产化替代中最为优先的考量因素，从现有几种替换方案来说差异很明显。原生 MySQL 的迁移相对难度不大，官网也提供了从5.7到8.0的升级方案及配套工具。但这里需要强调一点，8.0版本与5.7还是存在不小的差异，还没有做到完全向下兼容，因此还是需要做部分工作，包括从开发、架构及运维方面。国内开源方案，相对更为平滑，其是基于原生5.7版本构建而成，与官方版本的差异很小，更多是在功能及国产化适配上的增强，因此迁移难度在三个方案中是最小的，用户通常可以复用现有5.7的全套技术栈，相对难度和风险都是最小的。国产商用方案相对而言，是迁移难度最大的。不同商用方案的技术架构不同，有些是采用MySQL做了二次化封装而成，有些则完全自研并实现了一定MySQL兼容；那么无论是采用哪种技术路线，都涉及迁移中必要的评估工作。这一过程通常会包括功能、非功能及性能评估，包含诸多的评测内容。如评估结果与原生MySQL 5.7的差异较大，则都需要进行后续的迁移改造。此外，在后续的结构、数据迁移方面也无法利用原生工具完成，需要厂商或第三方来提供相关迁移工具和方案。
 ❖ 改造成本
 从上面的迁移难度看，各方案都多少存在一定的改造成本，但差异也是比较明显的。原生方案中由8.0替换5.7，可能会存在一定的修改量，这需要在充分理解版本间差异的情况下进行修改。相对而言，国内开源方案在改造成本上则更有优势，鉴于其主要是针对部分功能及对国产化适配的增强，可以理解为对5.7是“100%”的兼容，在改造成本方面几乎为零。国产商用部分则是三者中改造成本最高的，在前期充分的评估后，需要摸清与5.7的功能差异，有针对性的进行改造适配。有些问题，甚至需要在架构层面进行调整才能解决。这里需考虑的成本不仅仅包括财力投入，也包括人力及时间成本等。
 ❖ 可用性
 金融行业对可用性的要求是极其严苛的，能够投入到生产环境使用的产品都是经过充分的考虑与验证。如需要新引入产品，哪怕仅仅是产品版本的重大升级，同样是需要进行评估与验证的。针对上面几种方案，升级到8.0，是需要有个版本重大升级后的验证过程，充分验证其可用性。对于国内开源方案，因其是基于5.7构建而成，因此其可用性基本可视同5.7的能力，对于用户来说，无需做太多验证类工作。对于国产商业方案来说，各家产品均优先在可用性上做了处理，但同样需要做一定的验证工作。
 ❖ 安全性
 数据库作为数据的主要载体，其对安全尤其是数据安全上有着严格要求。在具体安全能力上，主要包括有数据的保密性、完整性、可用性、访问控制、身份验证、备份恢复、审计监控、安全合规、防范攻击及必要的物理安全。原生的MySQL 8.0主要延续了5.7在安全方面的能力，可满足企业基本的安全诉求。国内开源，在安全性上有着更多的增强，包括针对数据加密方面国密算法的支持等。国产商用方面，则在安全上有着更多的增强，通过自身或与第三方工具的配合，可实现更高的安全性。
 ❖ 产品性能
 产品性能，一直是 MySQL 被部分用户吐槽的方面。原生的MySQL在高频、小批量的数据访问方面有一定优势，在稍微复杂的方面则有先天的短板。在MySQL 8.0上，这种情况有了一定的改善，通过支持诸如 Hash Join 等特性，做了一定的增强。当然，我们也要客观的看到，其较其他产品还是存在差距的。国内开源方面，针对性能方面有着更多的增强，有些没有合入官方版本的性能补丁被合入，其性能较原生MySQL有了进一步的增强。而国产商业方面，通过针对优化器、执行器乃至算法的支持，其性能有更为优异的表现，特别是随着分布式、列存、向量化执行引擎等关键能力的突破，其性能较原生或国内开源版本，有了质的飞跃。
 ❖ 兼容性
 好的数据库产品，还需要构建完善的上下游生态，这直接关乎到用户的使用体验。作为后来者，通常会选择兼容主流产品作为一条“捷径”。企业也通常会将兼容性作为选择的产品的考量因素之一。上述几种方案中，8.0在兼容性方面会采取向下兼容模式，会存在少量细微的差异；国内开源因是在5.7版本上构建，兼容性几乎等价于开源版本；在国产商业产品上，兼容性还存在不小的距离，需要不断完善增强。
 ❖ 运维管理及易用性
 数据库产品作为一种复杂的基础软件，提高易用性、降低运维管理难度是关乎于使用者体感的重要因素。在具体措施上，一方面通过内核的不断优化，提升易用性；一方面则通过自研或与第三方工具集成，降低使用管理的难度。从上述三个方案来看，社区开源产品无论是5.7还是升级到8.0都会面临一定的管理问题，原生的开源产品大多没有提供必要的配套工具等；同时基于内核层面的易用性问题，也很难在开源代码中快速合入实现。相对而言，国内开源会好一些，部分易用性问题可以在内核层实现。国产商用的则更有一些优势，很多商业产品都提供了很多周边工具来减少运维强度。
### 3).主流开源替代产品
 那么针对上面谈到的方案二，即迁移到国内开源产品上，报告中也整理了部分国内开源产品，包括 GreatSQL、PolarDB-X、StoneDB、TenDBCluster-TenDB、AliSQL 等一批基于 MySQL 开源分支构建的产品，这些产品已初步构建多方参与的社区生态，在应用落地、社区活跃度、代码贡献等层面围绕自身特点进行不断完善。报告中还对比了这些产品：
![](/home/attachment/202403/14/1228765_171040329326700.png)
在这些开源产品中，以 GreatSQL、PolarDB-X 等为代表的一些产品均取得不俗的成绩。它们通过构建国内自有开源生态社区，稳步推进生态发展。通过活跃的开源社区，不断更新迭代产品发展，快速响应解决社区问题，完善产品在不同业务场景下的需求，逐步形成更为符合中国特点的生态体系。以 GreatSQL 为例，通过增加如并行查询、线程池、MGR增强、SQL兼容增强、国密算法等特性及能力，提升在高性能、高可用、易用性、安全性上的表现，为国内用户提供了MySQL5.7停服替换的一种更好的选择。除了上述产品外，国内还有很多其他基于 MySQL 的开源或基于开源分支之上的商业产品，都可以作为用户替代的选择。相信这些产品未来也将担当起 MySQL 替换的重任。下图是来自墨天轮社区统计的 MySQL 体系的国内产品。
![](/home/attachment/202403/14/1228765_171040337958869.png)

数据库国产化信创数据库数据库选型 MySQL

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

MySQL 国产化替代观察

添加新评论0 条评论

文章目录收起目录

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料