首页 » Web前端 » php和mariadb技巧_MariaDB 和 MySQL 周全比拟选择数据库需要推敲这几点

php和mariadb技巧_MariaDB 和 MySQL 周全比拟选择数据库需要推敲这几点

访客 2024-12-14 0

扫一扫用手机浏览

文章目录 [+]

谁在利用 MySQL 和 MariaDB?

MySQL 和 MariaDB 都发布了各自的用户名单。

php和mariadb技巧_MariaDB 和 MySQL 周全比拟选择数据库需要推敲这几点

利用 MySQL 的有 Facebook、Github、YouTube、Twitter、PayPal、诺基亚、Spotify、Netflix 等。

php和mariadb技巧_MariaDB 和 MySQL 周全比拟选择数据库需要推敲这几点
(图片来自网络侵删)

利用 MariaDB 的有 Redhat、DBS、Suse、Ubuntu、1&1、Ingenico 等。

功能比较

有一些令人愉快的新功能(如窗口函数、角色掌握或公共表表达式(CTE))可能值得一提,但本文只是为了比较两个数据库,以是我们在这里只谈论个中一方专门供应的功能,以便更好地帮助读者选择得当自己的数据库。

让我们来看一下只有个中一个数据库专门供应的功能:

1. JSON 数据类型——从 5.7 版本开始,MySQL 支持由 RFC 7159 定义的原生 JSON 数据类型,可以高效地访问 JSON 文档中的数据。

MariaDB 没有供应这一增强功能,认为 JSON 数据类型不是 SQL 标准的一部分。
但为了支持从 MySQL 复制数据,MariaDB 为 JSON 定义了一个别名,实际上便是一个 LONGTEXT 列。
MariaDB 声称两者之间没有显著的性能差异,但他们并没有供应基准测试数据来支持这个说法。

值得把稳的是,MySQL 和 MariaDB 都供应了一些 JSON 干系函数,用于更方便地访问、解析和检索 JSON 数据。

2. 默认身份认证——在 MySQL 8.0 中,默认的身份认证插件是 caching_sha2_password,而不是 mysql_native_password。
这一增强通过利用 SHA-256 算法提高了安全性。

3. MySQL Shell——MySQL Shell 是 MySQL 的高等命令行客户端和代码编辑器。
除了 SQL 之外,MySQL Shell 还供应了 JavaScript 和 Python 脚本功能。
不过用户不能利用 mysqlsh 访问 MariaDB 做事器,由于 MariaDB 不支持 MySQL X 协议。

4. 加密——MySQL 对重做 / 撤消日志进行了加密(可配),但不加密临时表空间或二进制日志。
相反,MariaDB 支持二进制日志和临时表加密。

5. 密钥管理——MariaDB 供应开箱即用的 AWS 密钥管理插件。
MySQL 也供应了一些用于密钥管理的插件,但它们仅在企业版中可用。

6. sys 模式——MySQL 8.0 供应了 sys 模式,这是一组工具,可帮助数据库管理员和软件工程师更好地理解通过 Performance 模式网络的数据。
sys 模式工具可用于优化和诊断,不过 MariaDB 没有供应这个增强功能。

7. validate_password 插件——validate_password 插件紧张用于测试密码并提高安全性。
MySQL 默认启用了这个插件,而 MariaDB 则不启用。

8. 超级只读—— MySQL 通过供应超级只读(super read-only)模式来增强 read_only 功能。
如果启用了 read_only,做事器只许可具有 SUPER 权限的用户实行客户端更新。
如果同时启用了 super_read_only,那么做事器将禁止具有 SUPER 权限的用户实行客户端更新。

9. 不可见列——这个功能在 MariaDB 上可用,MySQL 不支持该功能。
这个功能许可创建未在 SELECT 语句中涌现的列,而在进行插入时,如果它们的名字没有涌如今 INSERT 语句中,就不须要为这些列供应值。

10. 线程池——MariaDB 支持连接线程池,这对付短查询和 CPU 密集型的事情负载(OLTP)来说非常有用。
在 MySQL 的社区版本中,线程数是固定的,因而限定了这种灵巧性。
MySQL 操持在企业版中增加线程池功能。

性能

近年来,涌现了很多关于 MySQL 和 MariaDB 引擎性能的基准测试。
我们不认为“MySQL 或 MariaDB 哪个更快”这个问题会有一个终极的答案,它在很大程度上取决于详细的利用场景、查询、用户和连接数量等成分。

不过,如果你确实想知道,下面列出了我们创造的一些最新的基准测试结果。
请把稳,这些测试都是在一组特定的数据库 + 引擎(例如 MySQL+InnoDB)组合上进行的,因此得出的结论只与特定的组合有关。

MySQL 8.0(InnoDB)和 MariaDB 10.3.7(MyRocks)基准测试比拟:https://minervadb.com/index.php/2018/06/01/benchmarking-innodb-and-myrocks-performance-using-sysbench/MariaDB 10.1 和 MySQL 5.7 在商用硬件上的性能比拟:https://mariadb.org/maria-10-1-mysql-5-7-commodity-hardware/MySQL 8.0 和 MariaDB 10.3.5 性能比拟及 UTF8 的影响:http://dimitrik.free.fr/blog/archives/2018/04/mysql-performance-80-and-utf8-impact.html复制

两个数据库都供应了将数据从一个做事器复制到另一个做事器的功能。
它们的紧张差异是大多数 MariaDB 版本许可你从 MySQL 复制数据,这意味着你可以轻松地将 MySQL 迁移到 MariaDB。
但反过来却没有那么随意马虎,由于大多数 MySQL 版本都不许可从 MariaDB 复制数据。

此外,值得把稳的是,MySQL GTID 不同于 MariaDB GTID,以是将数据从 MySQL 复制到 MariaDB 后,GTID 数据将相应地做出调度。

以下是这两个数据库在复制配置方面的一些差别:

MySQL 的默认二进制日志格式是基于行的,而在 MariaDB 中,默认的二进制日志格式是稠浊式的。
log_bin_compress——这个配置决定了是否可以压缩二进制日志。
这个增强功能是 MariaDB 独占的,因此 MySQL 不支持。

MySQL 和 MariaDB 之间的不兼容性

MariaDB 的文档中列出了 MySQL 和 MariaDB 之间的数百个不兼容问题。
因此,我们无法通过大略的方案在这两个数据库之间进行迁移。

大多数数据库管理员都希望 MariaDB 只是作为 MySQL 的一个 branch,这样就可以轻松地在两者之间进行迁移。
但从最新发布的几个版本来看,这种想法是不现实的。
MariaDB 实际上是 MySQL 的一个 fork,这意味着在它们之间进行迁移须要考虑很多东西。

存储引擎

MariaDB 比 MySQL 支持更多的存储引擎类型。
但话说回来,数据库可以支持多少个存储引擎并不主要,主要的是哪个数据库可以支持适宜你需求的存储引擎。

MariaDB 支持的存储引擎包括:XtraDB、InnoDB、MariaDB ColumnStore、Aria、Archive、Blackhole、Cassandra Storage Engine、Connect、CSV、FederatedX、Memory、Merge、Mroonga、MyISAM、MyRocks、QQGraph、Sequence Storage Engine、SphinxSE、Spider、TokuDB。
MySQL 支持的存储引擎包括:InnoDB、MyISAM、Memory、CSV、Archive、Blackhole、Merge、Federated、Example。
在 Linux 上安装

当你在某些 Linux 发行版上安装 MySQL 时,末了可能安装的是 MariaDB,由于它是很多(不是全部)Linux 发行版的默认设置。

Red Hat Enterprise/CentOS/Fedora/Debian 发行版默认会安装 MariaDB,而其他发行版(如 Ubuntu)默认安装 MySQL。

云平台上的可用性

MariaDB 可作为运行在 Amazon Web Services(AWS)、微软 Azure 和 Rackspace Cloud 上的做事。

MySQL 在上面提到的三个平台上也是可用的,同时还可以作为托管做事在谷歌云做事平台上运行。

因此,如果你正在利用谷歌云平台,并希望云供应商为你管理做事,那么可以考虑利用 MySQL,除非你希望自己安装和管理 MariaDB 实例。

容许

MariaDB 采取了 GPL v2 容许,而 MySQL 供应了两个容许选项——GPL v2(用于社区版)和企业容许。

MySQL 的两个容许之间的紧张差异在于可用的功能和支持做事。
用户可以利用 MariaDB 的所有功能,但对付 MySQL 来说并非如此。
MySQL 的社区版不包含线程池等功能,而这些功能会对数据库和查询性能产生重大影响。

发布频率和更新

常日,MariaDB 的发布频率比 MySQL 更频繁。
太高的发布频率既有利也有弊。
从好的方面来说,用户可以更及时地收到功能和缺点修复。
从不好的方面来说,为了让 MariaDB 保持最新的状态,须要更多的事情量。

技能支持

MySQL 的支持团队(包括 MySQL 开拓职员和支持工程师)为客户供应全天候做事。
甲骨文供应了多种支持选项,包括扩展支持、持续支持和高等支持,详细取决于客户的哀求。
MariaDB 支持团队的支持工程师包括了 MariaDB 和 MySQL 数据库专家(由于很多功能最初是由 MySQL 团队开拓的),他们为生产系统供应全天候的企业级支持。

正在进行中的开拓

MySQL 的开拓者紧张是甲骨文的 MySQL 团队,而 MariaDB 开拓通过公开投票和邮件列表谈论的办法进行。
此外,任何人都可以向 MariaDB 提交补丁,MariaDB 开拓团队会考虑将这些补丁添加到主代码库中。
因此,从某种程度上说,MariaDB 是由社区开拓的,而 MySQL 紧张由甲骨文开拓。

结论

好吧,我们无法为你做出决定。
我们能做的便是有针对性地问你一些问题,然后你自己做出决定:

你是否分别基于这两个数据库对你的产品性能做过测试?哪一个表现更好,为什么?你是否打算利用个中一个数据库专门供应的功能?你是否打算利用个中一个数据库专门供应的数据库引擎?能够对数据库的开拓过程产生影响对你来说有多主要?能够参与下一个功能变更投票对你来说有多主要?你是要为企业版本付费还是利用社区版?社区版的功能是否能够知足你的需求?你的操作系统是否默认支持你所选的数据库?要支配它需不须要很多事情量?你利用的是哪个云供应商?他们是否供应托管做事,个中包括你选择的数据库?你是否操持将来从一种数据库类型迁移到另一种数据库类型?如果是这样,你是否考虑过兼容性和复制方面的问题?

如果你能回答好这些问题,可能就很清楚哪个数据库更适宜你。
成都加米谷教诲大数据培训,专注于大数据人才培养,中秋国庆双节活动特惠学员,详情见加米谷大数据微头条!

标签:

相关文章

php创立es索引技巧_Elasticsearch创建索引流程

我们延续上一篇来研究一下ES实际是怎么处理创建索引的流程的,我们根据代码一层层点进去看一下我们瞥见了什么,这个便是包装了创建索引干...

Web前端 2024-12-16 阅读0 评论0