暂无图片
暂无图片
4
暂无图片
暂无图片
暂无图片

关系型数据库产品选型分析与建议

原创 茹星棋 2022-12-07
1454



背景

关系型数据库服务通常作为软件产品的核心数据承载服务,而核心数据又作为企业的最宝贵资产,所以关系型数据库服务毋庸置疑地需要以下属性和能力:高安全、高可用、高性能、以及弹性扩展能力,同时关系型数据库产品在开发维护和商业授权方面,需要以下属性:生态成熟度和商业成本。目前备选数据库产品为Oracle、MySQL、PostgreSQL和达梦等数据库,那么为了对比这些数据库产品的上述属性和能力以及其匹配信创国产化要求时尽可能地减少改造成本,需要做以下分析与建议。

数据库流行度排行榜

数据库流行度在一定程度上体现着数据库产品的生态成熟度,其生态越成熟,越可以降低开发和运维人员的使用成本,不仅可以缩短项目工期,而且可以保证产品质量。

国产数据库流行度排行(2021年11月):

数据来源于https://www.modb.pro/dbRank

图形用户界面, 应用程序

描述已自动生成

排行榜图1

图表, 折线图

描述已自动生成

流行趋势图2

排行规则说明:

通过50个左右维度的数据来考察近200个国产数据库的流行度排行,每月1日更新排行数据,用于体现国产数据库的流行度。

详见https://www.modb.pro/db/189802

全球数据库流行度排行(2021年12月):

数据来源于https://db-engines.com/en/ranking

图形用户界面, 文本, 应用程序, 电子邮件

描述已自动生成

排行榜图1

图表, 折线图

描述已自动生成

流行趋势图2

图表, 折线图

描述已自动生成

TIDB流行趋势图3(国产数据库只有TIDB上榜,故单独展现出来)

排行规则说明:

该系统在网站上被提及的次数,以搜索引擎查询结果的数量来衡量。系统中提到的工作邀请数量等等。

详见https://db-engines.com/en/ranking_definition

数据库流行度排行小结

3.1国产数据库流行度排行榜

PingCAP的TiDB本月分数略微上涨4.26,总分619.54,依然以高分居于榜首。从排行榜中可以看出,TiDB在社区平台、高校合作、培训认证、开放文档、代码开源等生态建设方面取得了显著成果,这将是推动TiDB分数上涨的一个持续的动力。11月份,TiDB Cloud 由第三方机构 ePrivacy GmbH 认证符合欧盟 GDPR 要求。

此外,TiDB 5.3.0 版本正式上线,新版本推出持续性能分析功能(目前为实验特性),实现了 HTAP 性能、稳定性、数据迁移效率、高可用性和易用性等大幅提升。新版本的发布使TiDB获得了更多的市场关注度。

达梦数据库自6月份以来,表现十分亮眼,整体分数上涨153.24。11月份,达梦启云数据库3.0全新发布,可靠性、安全性、性能以及易用性获得了大幅提升,为用户带来全新的云原生数据库体验,市场表现良好。

3.2全球数据库流行度排行榜

Oracle数据库与MySQL数据库从2013年(此时Oracle已经收购MySQL)开始几乎从未掉下前两名,这得益于国外数据库技术起步较早,并且已经形成了近乎完美的数据库生态,所以也就不难理解MySQL在被Oracle收购后仍然保持开源,Oracle厂商依然具有数据库市场统治力。从这个角度也可以说明商业与开源并不是“敌人”的关系,反而是“互相成就”的关系,目前MySQL有社区版、标准版、企业版,社区版完全免费开源,吸引着海量用户使用,这些用户中有个人、有团体,这在无形中增加了Oracle的隐形商业用户,同时也丰富着MySQL的生态。而MySQL在被Oracle收购之后,进行了大量来自Oracle专业团队的优化与改进,有些特性直接来自于Oracle数据库,比如之前MySQL经常被吐槽没有Hash Join关联算法,而被Oracle收购后,直接加入此关联算法。即使是社区版,依然可以体验这些优化与改进,而标准本和企业版无非是多了些官方技术服务以及额外配套的企业级管理软件。

PostgreSQL数据库从2013年开始始终保持一个逐步上升的状态,未来形式较好。PostgreSQL数据库与MySQL数据库都在1996年左右诞生,然而其流行程度始终没有赶超过MySQL,究其原因PostgreSQL数据库的功能虽然丰富但是相比MySQL并不足够简单易用,而易用性其实是个非常重要的属性,因为易用,会吸引很多用户群体使用并且反馈问题,改进问题,持续保持热度,进而数据库生态可以不断完善,逐渐走向成熟。

数据库产品属性与能力详细分析

Oracle

1.1高安全:

1.Oracle Advanced Security 不仅能对应用表空间进行加密,有效防止带外访问敏感数据,还能通过校订策略防止敏感数据扩散,确保遵守数据保护法规。

2.Oracle Data Safe使组织能够理解数据敏感性,评估数据风险,屏蔽敏感数据,实现和监控安全控制,评估用户安全性,并监控用户活动,所有这些都在一个统一的控制台中。这些功能有助于管理Oracle数据库的日常安全性和遵从性需求,包括内部部署和云计算。

3.Oracle Audit Vault and Database Firewall 提供全面、可扩展的数据库审计和基于网络的活动监视解决方案,可助力企业分析和报告用户活动,进而有效检测攻击行为,满足合规要求。

4.Oracle 数据库安全性评估工具 (DBSAT) 可提供专业建议,帮助企业降低 Oracle 数据库的安全风险或漏洞威胁。使用 DBSAT,企业可以通过数据库当前状态评估(包括配置)和敏感数据发现等功能,全面洞察数据库的安全和合规态势。

5.Oracle Data Masking and Subsetting 赋能企业在确保数据安全的前提下释放数据价值,同时最大限度降低存储成本。无论是在测试、开发还是合作伙伴环境下,企业都可以安全、经济高效地供应数据。

6.Oracle Database Vault 可在 Oracle 数据库中实施数据安全控制,确保仅特权用户访问应用数据,进而有效降低内外部威胁风险,满足职责分离等合规要求。

7.Oracle Key Vault 可将加密密钥、Oracle 钱包、Java 密钥库和凭证文件安全存储在一个可伸缩、高容错、与加密数据相隔离的多主机集群中。

8.Oracle Label Security 基于数据标签和会话标签执行数据访问控制。它可以按项目代码、区域和数据分类来记录和实施数据访问权限控制,降低未经授权的敏感数据访问风险,确保合规。

1.2高可用:

1.Oracle Real Application Clusters (Oracle RAC)允许客户在多个服务器上运行单个Oracle数据库,以最大限度地提高可用性,并在访问共享存储时实现水平伸缩性。连接到Oracle RAC实例的用户会话可以在中断期间进行故障转移并安全地重播更改,而不会对最终用户应用程序进行任何更改,从而隐藏了中断的影响。

2.Oracle RAC One Node与RAC (Oracle Real Application Clusters)类似,Oracle RAC One Node使用共享磁盘系统为Oracle数据库提供最佳的类高可用性。与并发运行多个实例的Oracle RAC不同,Oracle RAC One Node提供了一个Oracle数据库故障转移解决方案,为集群基础设施提供了便利。它不需要任何应用程序更改,可以支持任何Oracle数据库工作负载,并且很容易升级到完整的多实例Oracle Real application Clusters配置。

3.Oracle Active Data Guard扩展了Oracle Data Guard的功能,提供高级的数据保护、灾难恢复和可伸缩性优势。在创建、维护和管理一个或多个同步备用数据库时,使用Oracle Active Data Guard来应对灾难和数据损坏。

4.Oracle Application Continuity(AC)是Oracle RAC、Oracle RAC One Node和Oracle Active Data Guard选项中提供的一种特性,可以通过恢复中断后受影响的数据库会话的运行中工作来屏蔽终端用户和应用程序的中断。

5.Oracle Sharding将数据集的片段分布在不同计算机上的多个数据库(shards)上,包括内部部署的和云计算的。它支持全局分布式、线性可伸缩、多模型数据库。它不需要专门的硬件或软件。在实现这一切的同时,Oracle Sharding提供了强大的一致性和SQL的强大功能,支持结构化和非结构化数据,以及Oracle数据库生态系统。它满足数据主权需求,并支持需要低延迟和高可用性的应用程序。

6.Oracle Recovery Manager (RMAN)是在Oracle数据库上执行备份和恢复任务,并自动管理备份策略的Oracle数据库客户端。Oracle RMAN简化了数据库文件的备份、恢复和恢复。

7.Oracle Database Flashback Technologies(Flashback Technologies)是一套数据恢复解决方案,通过有选择性和有效地消除错误的影响,逆转人为错误。Oracle Database Flashback支持所有级别的恢复,包括行、事务、表和整个数据库。

8.Oracle Multitenant使Oracle数据库具有容器数据库(CDB)的功能。一个CDB整合了多个可插入数据库(PDB),一个可移植的模式、模式对象和非模式对象集合。无论部署在本地还是云中,使用Oracle Multitenant,应用程序都可以在自包含的pdb中运行,从而提高资源利用率、管理和整体安全性。

9.Edition-based redefinition (EBR)支持在线应用程序升级和不间断应用程序可用性。当前应用程序和升级后的应用程序都可以同时运行,允许用户逐步过渡到应用程序的新版本,而不会中断业务连续性。

10.Oracle Site Guard通过为整个Oracle堆栈(包括web层、应用层、数据库、虚拟基础设施和存储)提供完全自动化的端到端灾难恢复,确保全面的业务连续性。

11.Oracle Active data Guard为企业数据确保高可用性、数据保护和灾难恢复。在创建、维护和管理一个或多个同步备用数据库时,能够在灾难和数据损坏中幸存下来。

12.Oracle GoldenGate当与其他Oracle MAA技术结合使用时,消除了日常数据库维护和升级、操作系统补丁、应用程序升级和平台迁移期间的停机时间。所有操作都有failback功能保护,消除了丢失数据的风险。Oracle GoldenGate可以部署在多主或active-active配置中,以实现数据库的可伸缩性或分布式同步。

13.Oracle Exadata 能够简化数字化转型、提高数据库性能和降低成本,是运行 Oracle 数据库的理想平台。Wikibon 分析报告 (PDF) 指出,Oracle Exadata 可帮助客户提高可用性和性能,降低成本高达 40%。得益于灵活的 Oracle 云基础设施、Oracle Cloud@Customer 和本地部署方案,企业将能够轻松、快速地实现数据库基础设施现代化、应用上云和数字化转型。

14.Oracle 零数据丢失恢复一体机 X9M 是一款集成式数据保护解决方案,可消除整个企业中所有 Oracle 数据库的数据丢失风险。如今,勒索软件攻击生产数据和备份数据的新闻屡见不鲜,企业需要现代化的数据(尤其是关键任务数据库)保护解决方案来应对现代威胁。Oracle 零数据丢失恢复一体机可在所有事务变更发生时记录和验证变更,从而提供卓越的可恢复性,持续保护数据库。无论发生何等中断(包括勒索软件攻击引发中断),数据库都可以在零到一秒内恢复。藉此,企业不必再执行完整备份,可以有效缩短备份用时,还可以释放数据库服务器资源,专注于运营工作。

1.3高性能:

1.Oracle Database In-Memory

提供了一种独特的双格式架构,可以同时使用传统的行格式和新的内存中列格式在内存中表示表。Oracle SQL 优化器自动将分析查询路由到列格式,将 OLTP 查询路由到行格式,从而透明地提供两全其美的性能优势。Oracle Database 自动维护行格式和列格式之间的完全事务一致性,就像当前维护表和索引之间的一致性那样。新的列格式是纯内存中格式,不会在磁盘上持久保留,因此不存在额外的存储成本或存储同步问题。

2.Oracle Partitioning

分区是一种强大的功能,它允许将表、索引和索引组织的表细分为更小的部分,从而使这些数据库对象能够在更细的粒度级别上进行管理和访问。Oracle提供了一系列全面的分区方案来满足每种业务需求。此外,由于分区在SQL语句中是完全透明的,因此可以在任何应用程序中使用分区,从打包的OLTP应用程序到数据仓库。

3.TimesTen In-Memory Database

Oracle TimesTen In-Memory Database (TimesTen) 改变了运行时数据驻留位置的假设,能够提供实时应用性能(低响应时间和高吞吐量)。它支持在内存中管理数据,并且会对数据结构和访问算法进行相应的优化,从而显著提升数据库操作的执行效率,并最终大幅改善响应能力和吞吐量。在引入 TimesTen Scaleout(一种基于现有内存技术的无共享横向扩展架构)之后,TimesTen 可支持数据库透明地扩展至数十个主机,达到数百 TB 的大小并支持每秒处理数亿次事务,而无需手动执行数据库分片或负载分区。

4.Oracle Real Application Testing

Oracle Real Application Testing可以帮助企业在将系统更改,例如硬件和软件升级、配置更改等部署到生产环境之前,在测试环境中全面评估这些系统更改对真实世界应用程序的影响。Oracle Real Application Testing包含两个特性,数据库重播和SQL性能分析器。它们使企业能够迅速采用新技术,在减少风险的同时为业务增加价值。

5.Oracle Advanced Compression

Oracle Advanced Compression提供了提高性能同时降低存储成本的数据库压缩功能。Oracle高级压缩减少了组织对所有类型的数据(关系(表)、非结构化(文件)、索引、数据保护重做、网络和RMAN备份的总体数据库存储占用,还提高了数据库基础设施的所有组件的性能,包括内存和网络带宽。

6.Oracle Exadata

Oracle Exadata 能够简化数字化转型、提高数据库性能和降低成本,是运行 Oracle 数据库的理想平台。Wikibon 分析报告 (PDF) 指出,Oracle Exadata 可帮助客户提高可用性和性能,降低成本高达 40%。得益于灵活的 Oracle 云基础设施、Oracle Cloud@Customer 和本地部署方案,企业将能够轻松、快速地实现数据库基础设施现代化、应用上云和数字化转型。

1.4生态成熟度:

目前关系型数据库流行度排名稳定前三,在全球范围内占有极大的数据库市场份额,经过30多年的发展,拥有优越的安全性、完整性、稳定性,以及支持多种操作系统、多种硬件平台等特点,得到了广泛的应用。从工业领域到商业领域,从大型机到微型机,从UNIX操作系统到Windows操作系统,均有成功的Oracle应用案例,然而虽然Oracle数据库在OLTP领域依然拥有优势,但由于面向云上转型时间较晚,已经丢失很多市场份额,尤其是当下火热的云时代,已经不是很多企业在上云时会考虑的首选数据库。

1.5商业成本:

商业成本极高,Oracle软件本身是免费的,所以任何人都可以从Oracle官方网站下载并安装Oracle的数据库软件,收费的是License,即软件授权,如果数据库用于商业用途,就需要购买相应Oracle产品的License。

现在Oracle有两种授权方式,按CPU(Process)数和按用户数(Named User Plus)。前一种方式一般用于用户数不确定或者用户数量很大的情况,典型的如互联网环境,而后一种则通常被用于用户数确定或者较少的情况。

关于服务价格:一般地,购买Oracle的License都包含首年的服务费,以后的费用按每年原价的22%计算。

1.6弹性扩展能力:

1.Oracle Real Application Clusters (Oracle RAC)允许客户在多个服务器上运行单个Oracle数据库,以最大限度地提高可用性,并在访问共享存储时实现水平伸缩性。连接到Oracle RAC实例的用户会话可以在中断期间进行故障转移并安全地重播更改,而不会对最终用户应用程序进行任何更改,从而隐藏了中断的影响。

2.Oracle Exadata 能够简化数字化转型、提高数据库性能和降低成本,是运行 Oracle 数据库的理想平台。Wikibon 分析报告 (PDF) 指出,Oracle Exadata 可帮助客户提高可用性和性能,降低成本高达 40%。得益于灵活的 Oracle 云基础设施、Oracle Cloud@Customer 和本地部署方案,企业将能够轻松、快速地实现数据库基础设施现代化、应用上云和数字化转型。

3.Oracle Real Application Testing可以帮助企业在将系统更改,例如硬件和软件升级、配置更改等部署到生产环境之前,在测试环境中全面评估这些系统更改对真实世界应用程序的影响。Oracle Real Application Testing包含两个特性,数据库重播和SQL性能分析器。它们使企业能够迅速采用新技术,在减少风险的同时为业务增加价值。

4.Oracle Advanced Compression提供了提高性能同时降低存储成本的数据库压缩功能。Oracle高级压缩减少了组织对所有类型的数据(关系(表)、非结构化(文件)、索引、数据保护重做、网络和RMAN备份的总体数据库存储占用,还提高了数据库基础设施的所有组件的性能,包括内存和网络带宽。

5.Oracle TimesTen In-Memory Database (TimesTen) 改变了运行时数据驻留位置的假设,能够提供实时应用性能(低响应时间和高吞吐量)。它支持在内存中管理数据,并且会对数据结构和访问算法进行相应的优化,从而显著提升数据库操作的执行效率,并最终大幅改善响应能力和吞吐量。在引入 TimesTen Scaleout(一种基于现有内存技术的无共享横向扩展架构)之后,TimesTen 可支持数据库透明地扩展至数十个主机,达到数百 TB 的大小并支持每秒处理数亿次事务,而无需手动执行数据库分片或负载分区。

MySQL

2.1高安全:

2.1.1连接安全性

MySQL基于访问控制列表(Access Control list, acl)对所有连接、查询和其他用户可以尝试执行的操作使用安全性。还支持MySQL客户端和服务器之间的ssl加密连接以及数据库实例之间的ssl加密数据同步。

2.1.2备份与恢复

MySQL的备份与恢复生态很成熟,无论在开源层面还是商业层面。

  1. 物理备份与恢复工具(全量+增量):Xtrabackup免费开源,隶属于Percona公司,GPLv2授权,可以说是MySQL的标准物理备份与恢复开源工具,在线热备,稳定高效,媲美MySQL企业级备份工具,无论是个人还是企业都经过大量实践。
  2. 逻辑备份与恢复(全量)工具:Mysqldump、Mysqlpump、Mydumper和MySQL Shell Dump&Load,这里重点强调下MySQL Shell Dump&Load,请看基准测试对比图,如下图所示:

转储

加载

如这些基准测试所示,MySQL Shell能够快速转储数据,最高可达3GB/s的速度,并以200MB/s以上的速度加载数据(禁用InnoDB重做日志时)。

MySQL Shell与以前的工具相比,能够获得显着的性能改进。在许多情况下,即使是功能最强大的硬件,过去耗时数小时甚至全天的转储现在都可以在不到一个小时甚至不到几分钟的时间内完成。

同样重要的是,通过加载这些转储还原服务器也要快得多。与加载等效的.sql转储文件相比,从Shell转储中还原大型数据库仅需花费一小部分时间。当需要紧急恢复时,这可以释放一些宝贵的时间!

  1. 逻辑备份与恢复(增量):MySQL针对数据的所有更改都会记录到binlog,增量的备份只需备份binlog即可,而恢复无论是mysqlbinlog还是binlog2sql(第三方开源工具)都可以做到按时间点或者事件点恢复,无论是个人还是企业都经过大量实践。
  2. 延时备份与恢复:基于MySQL灵活的数据复制协议,可以配置延时复制策略,这样做的好处是即使在面临被删除数据库甚至是整个实例都可以拥有快速恢复完整数据的窗口时间,结合上述的逻辑恢复工具可以快速地把数据恢复到被删除前的完整状态。
  3. 异地灾备:基于MySQL灵活的数据复制协议,跨地域灾备的实施无论在技术成本上或者商业成本上都相对低廉,比如考虑到专线的成本过于高昂,那么通过互联网和SSL加密传输的方式也可以保证数据复制的安全性。

2.1.3数据加密

  1. 动态脱敏:围绕MySQL的动态脱敏开源平台和开源工具有很多,比较知名并且大量应用的是Yearning和go-inception,应用和数据库都无需做任何改动,即可以对查询的数据进行动态脱敏。
  2. 数据文件透明加密:加密表空间文件,读取时自动解密,对应用端透明。
  3. 数据逻辑加密:MySQL自身具有加密与解密函数,同时围绕MySQL的数据加密商业解决方案也比较成熟。

2.1.4审计与洞察

围绕MySQL的访问审计与洞察,可基于大量开源平台和开源数据库中间件实现,对数据库无任何侵入,保证性能的前提下提升安全性。

2.2高可用:

MySQL发展至今,在高可用性方面不断前进,从最初的异步复制、半同步复制、群组复制,演进到现在的InnoDB Cluster和InnoDB Replica Set。不同的高可用架构也是针对不同的业务需求而产生的,高可用性越高意味着成本也越高。可以从以下几个方面去明确目标:

  1. 恢复时间目标(RTO):服务从故障中恢复需要多长时间
  2. 恢复点目标(RPO):服务在故障中允许丢失的数据
  3. 故障类型:
        • 高可用:单一服务器故障,网络分区
        • 容灾:整体地域/网络故障
        • 人为错误:操作失误/故意破坏
        • 程度:0/秒/分/小时/...
  • 单一地域
  • RTO=数分
  • RPO=少于1秒
  • MySQL InnoDB Replica Set

  • 单一地域
  • RTO=数秒
  • RPO=0
  • MySQL InnoDB Cluster

图片

  • 多地域
  • 地域故障
  • RTO=数分
  • RPO=数秒
  • MySQL InnoDB Cluster
    • 配合使用异步复制

  • 多地域
  • 地域故障
  • RTO=数分
  • RPO=0
  • MySQL InnoDB Cluster 跨地域部署
    • 两个地域的一致性级别设置为AFTER,或者三个地域,每个地域具有1-2个成员
    • 写入的吞吐量受到影响,写入事务需要保证事务同步

上述的高可用架构都是比较经典通用的架构,基本可以满足绝大部分业务需求,而MySQL具有多种数据复制协议,可根据业务需求再自行深入定制其他高可用架构,并且实施成本很低廉,这也是为什么MySQL的流行度持续活跃的一个重要因素。

2.3高性能:

大量的高并发Web网站使用MySQL数据库足以说明MySQL的高性能基础,而性能也是一个广义的指标,不单是数据库产品本身的性能,围绕着业务SQL的设计,数据库架构的选择,硬件的选择等等都是影响性能的重要因素,故下面只列出MySQL两个经典版本MySQL 8.0对比MySQL 5.7之间的基准测试对比:

MySQL 8.0 Sysbench Benchmark: IO Bound Read Only (Point Selects)

MySQL 8.0 Sysbench Benchmark: IO Bound Read Only (Point Selects)

MySQL 8.0 Sysbench Benchmark: Read Write (update nokey)

MySQL 8.0 Sysbench Benchmark: Read Write (update nokey)

MySQL 8.0 Sysbench Benchmark: Double Write Buffer, IO Bound Read Write

MySQL 8.0 Sysbench Benchmark: Double Write Buffer, IO Bound Read Write

从上面的基准测试图可以明确地看到MySQL 8.0比MySQL 5.7快两倍,究其原因是Oracle官方团队对其进行了大量的优化,所以也推荐使用MySQL 8.0版本。

2.4生态成熟度:

生态成熟度在上文数据库流行度排行榜章节已经简单地介绍过,在此只与同样开源的PostgreSQL数据库做个对比。

MySQL和PostgreSQL的产品风格早期完全是两个极端。MySQL更像是个“基本上满足关系数据库语法的大号KV”,对关系型数据库的高级功能支持的很薄弱。MySQL 5.1和MyISAM存储引擎,不支持ACID,但有如下几点在当时的互联网公司看来是非常合适:

  1. 互联网公司为了扩展,长期的经验是,仅仅把数据库当作是一个“存储”,而非“存储+核心数据逻辑计算节点”。大量的计算都在应用服务器上进行,而应用服务器可以无限水平扩展,同时无需担心有状态的数据迁移问题。
  2. 因为没有提供很多高级功能和数据一致性的保障,MySQL对于简单的sql支持反而更加直接,在速度上有很大的优势。对于OLTP,完全不需要复杂的数据处理功能。简单的select ... from ... where id = xxx; insert into xxx;update xxx set xxx=xxx where id = xxxx是OLTP的主流功能。基于这些功能的ORM的出现大大地提高了生产效率。
  3. 对于OLAP,尽管PostgreSQL查询分析功能很强,但是一般互联网公司的数据量实在太大,用PostgreSQL这种数据库根本无法处理。通常会用MapReduce,Hive,Pig等大数据处理工具来分析。
  4. PostgreSQL早期并不支持“逻辑复制”。物理复制意味着存储格式的细节完全暴露,不兼容的版本无法直接组成主从同步,于是无法做滚动升级。这就意味着在升级数据库时,必须停服,把整个集群升级后再恢复。这个缺陷让PostgreSQL的运营不受互联网业务的待见,毕竟谁也不希望自己的业务停服。而MySQL从一开始就是逻辑复制(这其实是由于MySQL一直是server和存储引擎分离的架构,逻辑复制发生在server层)。

反过来再看PostgreSQL的优点,会发现对于OLTP并没有太大的吸引力:

  1. 丰富的数据类型,通常用处不大,常用类型足够了。如果有复杂类型,业务上自己序列化,存储成varchar就行。可以用json,avro等。序列化反序列化都发生在业务服务器,更好维护和优化;
  2. 强大的审计函数,互联网早期活下来是一切,审计并不是核心需求(通常需要严格审计的领域早就会用Oracle,不差钱);
  3. 强大的索引。PostgreSQL的自定义索引功能很强大。但是对于MySQL,关键的几列有索引就够了,不需要复杂的高级索引。早期MySQL的查询优化器智商堪忧,但如果要改,一句explain,然后force index也就是了。对于开发人员简单直接。有一段时间LBS很流行,当时Mongo很潮地直接支持了空间索引。当时大家纷纷地“NoSQL”,就更不会看PostgreSQL一眼。然后到了大概2015年,MySQL 5.7也支持空间索引了。
  4. PostgreSQL的MVCC实现很强大。serial snapshot isolation是很强。但是到了需要变更数据严格一致的时候,MySQL的select ... for update也可以实现,并且后续MySQL的Innodb存储引擎也支持了MVCC。
  5. 对于序列号,sequence是很好。但是互联网公司对于简单场景用auto increment。对于分布式场景就直接用分布式序列号生成服务了。PostgreSQL的序列号产生器~偏鸡肋。
  6. PostgreSQL的全文索引很强,但强的过ES?强的过专门定制的搜索引擎系统?要知道搜索业务最关键的是把“最匹配搜索人需要的搜索结果返回出来”,而不是仅仅“能搜到一堆不分主次但满足关键字匹配的结果”。

综上所述,早期MySQL变成了广大互联网企业OLTP的技术标准。无论做什么业务,MySQL都不可或缺。在行业里广大程序员普遍对MySQL更熟悉。大量围绕MySQL的商业服务或者开源服务都成为了行业主流。新一代分布式数据库,像TiDB为了吸引用户,首先要做的是“兼容MySQL的语法”。

再往后,MySQL增加了更多“关系型数据库该有的”功能,比如完全支持ACID的Innodb成为默认存储引擎,比如5.7的json原生支持,8.0的window function/CTE,函数索引。而PostgreSQL也增加了更多的“互联网功能”,但是时机已经过去了。大家MySQL跑着业务好好的,而切换数据库绝对不是仅仅像某些ORM标榜地换一个Dialect就行的。而是整个编程模型,性能表现,运维工具和流程都要有巨大的变化。

而关于PostgreSQL转向MySQL之前有一个很有名的案例,Why Uber Engineering Switched from Postgres to MySQL,阅读全文可以发现其很重要的一个原因是低效的数据复制,而MySQL的逻辑复制技术发展到今天其灵活性和稳定性可以说是独当一面的存在了,它既可以快速地实现各种高可用和弹性扩展集群,同时也可以实现诸如备份、闪回、数据订阅等等业务需求,对运维人员也是极其友好。

最后围绕着MySQL的还有两大世界开源分支版本Percona Server for MySQL和MariaDB,前者不仅为MySQL提供了大量开源运维工具并且也提供了新型存储引擎,并且完全兼MySQL,后者更是MySQL原作者所创立,也是大多数云产品的一部分以及大多数Linux发行版中的默认配置。

2.6商业成本:

如果需要免费使用MySQL数据库,那么MySQL社区版完全可以满足需求,即使它也属于Oracle公司,所以本节更多地关注其是否在中美大环境下是否有闭源风险。本节不再讨论其GPL授权是否有闭源风险(理论上不会有,即使闭源,最大的受益者也是MySQL分支版本)直接从中美当前的一些文件条例以及数据库技术架构本身的角度分析使用 MySQL 数据库是否会出现被“卡脖子”的情况。

  1. 商业风险(美方角度):

Oracle 公司的数据库产品中,多数产品受美国出口管控条例(Export Administration Regulations,EAR)管控,Oracle 官方已在2019年 8 月更新了其产品对应的出口管控类别编码(Export Control Classification Number,ECCN,这里关于 ECCN 的背景和分类我们不展开描述)。

其中,对于 Oracle 数据库产品线(Oracle 10g 以及以上版本)以及其他配套软件工具均在 5D992.C 类别中。对于 MySQL 产品线,MySQL 企业版、MySQL 标准版、MySQL 经典版、MySQL 集群版以及 MySQL 嵌入式版同样在 5D992.C 类别中,然而,在 Oracle 提供的表单中,并没有 MySQL 社区版(MySQL Community Edition)的记录。

http://www.oracle.com/us/products/export/eccn-matrix-345817.html

由此可见,MySQL 社区版作为开源软件,在 EAR 条例的政策中,有别于 MySQL 企业版等商业软件。下面是 MySQL 官网关于各 MySQL 版本的介绍,这里我们不展开描述。   

这个时候问题来了,MySQL 项目以及整个开源生态发展到今天,其中关系早已是,你中有我,我中有你,MySQL 中就包含大量第三方组件,这些组件有些作为功能合入了主版本,如我们今天使用的半同步复制源于 Google;而有些组件则作为软件包合入并保留了原有 license,如 innodb 默认使用的异步调用包 libaio。那么如果这些组件受到 EAR 管控怎么办?这时候 MySQL 社区版是否还能和 EAR “划清界限”?

由于 MySQL 中涉及的第三方软件太多并且存在持续增加的可能,关于这点我们不能完全给出肯定,但是,我们特别查找了关于出口加密软件源码在 EAR(734.17) 中的描述。由于加密软件与通信安全相关,其管控力度有别于普通软件,在一定程度上可作为边界进行对比参考。(这里关于加密软件为何特殊的缘由我们不展开描述)。

首先,在满足 EAR(742.15(b)) 要求的前提下,面向公众开放的加密软件源代码不受管控。

https://www.ecfr.gov/cgi-bin/retrieveECFR?gp=&SID=c15df34b40ffa8da7671d1bc180330c5&mc=true&n=pt15.2.734&r=PART&ty=HTML#se15.2.734_117

接下是 EAR-742.15 的具体内容:

对于加密类软件,首先需要遵守加密软件出口 license 条例,其次,每项出口均需要经过二次审查。而对于加密软件源码,面向公众开放的加密软件源码,不在 EAR 管控范围内(当然,这并不意味着它不受美国其它法律条例限制,此处我们不展开描述),但是,使用、修改、发布这些源码时,需要向美国商务部相关单位(BIS 和 ENC Encryption Request Coordinator)进行邮件报备。

https://www.ecfr.gov/cgi-bin/text-idx?SID=00a8f54989eaf101a84eff3db59ac6e9&mc=true&node=se15.2.742_115&rgn=div88

结合两方信息,我们在 Oracle 给出的 ECCN 编码中没有发现 MySQL 社区版,同时 MySQL 所包含的含加密功能的软件(如 OpenSSL\ Kerberos)满足面向公众开放源码的要求。因此,除非 EAR 内容大幅度修改,否则使用 MySQL 社区版,目前不存在EAR管控方面的风险。

  1. 商业风险(中方角度):

阐述完美方的文件条例,下面我们对国内的趋势性文件做一个简单的说明。2017 年,工业和信息化部和国家发展改革委两部委正式印发了《信息产业发展指南》,文件中提出“支持开源、开放的开发模式,重点推进云操作系统、云中间件、新型数据库管理系统”。 


这表示,开源模式在基础软件的发展中已得到认可,近几年 MySQL 在中大型终端用户群体中,除了应用的规模外,应用的深度也在不断发展,越来越多的非互联网行业用户开始走开源 + 自主管理的整体发展模式,这也使 MySQL 数据库的生态环境不断丰富成熟,因此,从近几年金融、电信和交通等行业的建设成果看,使用 MySQL 并不存在政策风险。 

综上所述,当前环境下,不论从中方或是美方政策视角出发,选择 MySQL 社区版数据库,不会存在商业上的风险。

  1. 技术可行性( RTO/RPO 可用性级别):

最后,从技术架构角度,以 Oracle RAC 为代表的商业数据库高可用,通常与存储设备一同部署,由中高端双(多)控制器磁盘阵列充当数据的保险箱,因此 RAC 架构是将数据库的风险转移到存储设备,增强了系统故障中的短板(磁盘),本质上是提升了单点抵抗故障的能力,但局部单点故障仍存在。

而 MySQL 高可用架构,如主从复制/组复制,则采用一主多从模式,将一份数据保留到多个位置(银行业通常采用本地 1 主 1 从 + 同城 2 从的共 4 个库组成数据库高可用组),本质上是利用数据冗余换取更高概率的数据安全,做到避免单点故障。(关于主从复制与组复制和 Oracle RAC 的对比我们不展开讨论)。

因此,在架构得当、运维规范的前提下,MySQL 的高可用机制也能提供金融级的保障能力,同时,对于以上高可用功能,MySQL 社区版与 MySQL 企业版完全一致,能够在不被“卡脖子”的前提下,满足业务对数据库的可靠性要求。

2.7弹性扩展能力:

在MySQL数据库大量应用的今天,其一大特点就是具有弹性扩展能力,这也很符合互联网的业务,在活动、推广等大流量进入之后,弹性扩容引流,不仅可以提升数据库的可靠性,同时可以提高数据库的吞吐量,在流量降低之后,弹性缩容,节约成本。这种弹性扩展能力也是传统数据库Oracle和开源数据库PosrgreSQL所不具备的。而MySQL弹性扩展能力发展到今天,基于其“clone”插件和“MGR”插件,简单高效地拥有上述能力,同时可保证对业务无侵入,对用户无感知。

PostgreSQL

3.1高安全:

3.1.1连接安全性

  1. 身份验证:GSSAPI,SSPI,LDAP,SCRAM-SHA-256,证书等
  2. 强大的访问控制系统
  3. 列和行级安全性
  4. 具有证书的多因素身份验证和其他方法

3.1.2可靠性、灾难恢复

  1. 写前日志记录(WAL)
  2. 复制:异步,同步,逻辑
  3. 时间点恢复(PITR),主动备用
  4. 表空间

3.2高可用:

对于PostgreSQL数据库的高可用实践,从原理来讲,高可用必定要实现数据同步层、高可用管理层以及对外统一访问接口这三个层面。那么PostgreSQL数据库和MySQL数据库的常用高可用组件版本和各方面也会有稍微有区别。

  1. PostgreSQL高可用方案之pgpool-II

pgpool-II底层的同步模块采用PostgreSQL异步流复制。

  1. PostgreSQL高可用方案之patroni

近年还有一种比较流行和经典的高可用就是patroni

3.3高性能:

  1. 索引:b -tree,多列,表达式,部分
  2. 高级索引:GiST, SP-Gist, KNN GiST, GIN, BRIN,覆盖索引,Bloom过滤器
  3. 复杂的查询规划器/优化器,仅索引扫描,多列统计
  4. 事务,嵌套事务(通过保存点)
  5. 多版本并发控制(MVCC)
  6. 并行化读查询和构建b -树索引
  7. 表分区
  8. SQL标准中定义的所有事务隔离级别,包括Serializable
  9. 表达式的即时(JIT)编译

3.4生态成熟度:

PG生态产品的创建时间普遍晚于Mysql的生态产品,大部分项目是2012年以后才创建的,不过几乎所有的生态产品都已经经历了最痛苦的5年,已经进入了成熟期。

PG生态的发展虽然也和它的用户群体不断壮大有关,不过PG生态发展过程中,出现了一些与Mysql生态发展不同的特征,PG数据库的发展的推动主力并不是互联网企业,而是企业用户。

Mysql的生态发展是互联网企业先打了个样板,然后推动企业市场发展起来的。PG生态的发展起源于企业应用市场,互联网企业也随之发现了其中的商机,很快将其纳入到云服务平台之中。大量的国产数据库产品也以PG的开源项目为基础,包括人大金仓、神通、瀚高、优炫、华为Opengauss、海量G100、腾讯TBASE、阿里Polardb-PG等一系列国产数据库都是基于BSD授权的PG源码。

3.5商业成本:

PostgreSQL是在PostgreSQL许可证下发布的,这是一个自由的开源许可证,类似于BSD或MIT许可证。

PostgreSQL全球开发集团始终致力于让PostgreSQL永远成为免费和开源软件。目前还没有修改PostgreSQL许可证或在不同的许可证下发布PostgreSQL的计划。

3.6弹性扩展能力:

暂无这方面的资料。

达梦

4.1高安全:

高安全等级的数据库管理系统,达到国家安全四级、EAL4+级满足GB/T 20273、 GB/T 18336。

增强改进多项安全性。

4.2高可用:

达梦主备集群顾名思义就是一主一备(也可以一主多备)是一种集成化的高可靠性解决方案,同时满足用户对数据安全性和高可用性的要求。解决由于硬件故障、自然灾害等原因导致的数据库服务长时间中断问题,满足用户不间断提供数据库服务的要求,即实现系统的双机热备功能。在使用的过程中,如果是实时同步模式的话,主机和备机的数据保持完全一致。主机产生一条新的记录时,在记录写入数据库文件之前,会把新产生的redo日志文件发送到备机,由备机重新执行接收到的redo日志,来保证主备集群数据的一致性。

如果主机发生故障,则备机会自动切换为主机,代替原主机的职能。以此保证服务的连续性。在原主机故障恢复之后,重新加入集群之后,则变为备机,由新主机继续执行相关的任务,并同步数据到备机。

4.3高性能:

达梦采用多趟扫描、代价估算的优化策略,支持查询计划的HINT功能,可供经验丰富的DBA对特定查询进行优化改进,进一步提高查询的效率和灵活性。

达梦提供查询计划的重用,可以减少重复分析操作,有效提升语句的执行效率。达梦采用参数化常量方法,使得常量值不同的查询语句,同样可以重用查询计划。

达梦提供查询结果集缓存策略,在服务器端实现结果集缓存,可以在提升查询速度的同时,保证缓存结果的实时性和正确性。

达梦采用更加有效的异步检查点机制,相对原有检查点长时间占用缓冲区的策略相比,逻辑更加简单,速度更快,对整体系统运行影响更小。

达梦采用多版本并发控制技术,使得查询与更新操作间互不干扰,有效提高了高并发应用场景中的执行效率。

达梦中实现了数据字典缓存技术,执行期间不必封锁整个数据字典,可以有效降低DDL操作对整体系统并发执行的影响。

达梦为具有多个处理器 (CPU) 的计算机提供了并行查询,以优化查询执行和索引操作。并行查询其优势就是可以通过多个线程来处理查询作业,从而提高查询的效率。

达梦数据压缩采用智能压缩策略,自动选择最合适的压缩算法进行数据压缩,可以显著提升数据的压缩比,进一步减少系统的空间资源开销。

4.4生态成熟度:

支持更广泛的技术选型。

支持多种云计算基础设施环境、支持多种软硬件平台。

4.5商业成本:

网上无相关资料,咨询客服回复留下姓名和联系方式,安排专业的工作人员联系。

4.6弹性扩展能力:

当单个达梦数据库系统在SQL执行过程中发现当前操作需要大量的内存和CPU资源,且当前局域网上有可利用的空闲DM数据库计算资源时,就可以把当前的SQL操作拆分成多个任务和相应的数据分发到这些可以利用的达梦数据库,并回收计算结果加以整合,从而实现复杂SQL的弹性计算。

整体综合对比与选型建议

雷达对比图如下所示(商业成本越高,其分值越低):


归根结底,数据库技术无非是服务于业务的一种技术选型,并且没有哪种数据库产品可以解决所有业务场景,所以需要结合详细的业务场景选择出最适合的数据库产品。

如果业务场景比较侧重低廉商业成本和生态成熟度,那么MySQL和PostgreSQL都是比较好的选择,如果在MySQL和PostgreSQL中比较注重生态成熟度为减少项目工期成本,那么无疑MySQL比较适合。即使存在Oracle商业公司闭源MySQL的风险,MySQL的两大世界开源分支版本Percona Server for MySQL和MariaDB也具备与MySQL相同的能力和一定的生态成熟度,完全可以代替使用。

如果业务场景比较侧重匹配信创国产化和生态成熟度,那么结合国产数据库流行度排行,无疑达梦是最优的选择(TIDB不在信创国产化目录),并且其声称兼容Oracle协议,那么改造成本理论上比较低廉,最终还是需要实际操作验证。

如果业务场景比较侧重弹性扩展能力,那么据现在的技术成熟度,MySQL无疑是最优的选择,它经历了大量的互联网流量验证。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论