2

是时候了!MySQL 5.7 的下一站,不如试试 TiDB?-品玩

 10 months ago
source link: https://www.pingwest.com/a/284585
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

是时候了!MySQL 5.7 的下一站,不如试试 TiDB?-品玩

top-ad_1db2933.png

业界动态

是时候了!MySQL 5.7 的下一站,不如试试 TiDB?

鸠鸠

发布于 13小时前

导读

在 2023 年 10 月 21 日,MySQL 5.7 将达到其生命周期的终点(EOL,End of Life)。这意味着 Oracle 将不再为 MySQL 5.7 提供官方更新、错误修复或安全补丁。

自发布以来,MySQL 5.7 成为了许多应用开发者的首选的数据库,但日新月异的数据应用场景和技术也对数据库技术栈提出了新的需求。随着 MySQL 5.7 EOL 到来,升级到一个更高版本、且有官方支持的 MySQL 似乎是最直接的方案,但是否有其他选择呢?我们是否可以找到一个既能满足当下不断发展的数据处理需求,又能克服当前 MySQL 技术限制的完美替代方案?

本文将介绍一些可能的替代方案的优缺点,重点探讨分布式数据库(如 TiDB)的架构优势。

1、MySQL 的发展及面临的挑战

当下,数据价值越来越受到企业的重视,“数据驱动”也成为了一个重要的课题,事务性数据处理方式在过去十年中发生了巨大变化,实时、海量的事务处理日益成为主流,同时对从这些数据中获得即时的分析和洞察的需求也依然存在。然而,MySQL 在应对这些不断演进的需求时存在一些局限性:

● 扩展性 :面向写入密集型应用程序,MySQL 的性能变得不稳定。当数据规模超过单个节点的容量时,性能会受到影响。

● 高可用性 :虽然 MySQL 提供了复制和集群等功能以实现高可用性,但要有效地设置和管理这些功能需要仔细规划、配置和持续监控。此外,传统的 MySQL 复制可能出现延迟,进而导致数据不一致。

● 实时分析 :随着企业对事务性数据的实时洞察的需求增加,在 MySQL 架构中将联机事务处理(OLTP)和在线分析处理(OLAP)系统分离的架构会产生性能上的瓶颈。分析查询可能会影响事务处理的性能。而使用单独的分析数据库处理这些查询则增加了技术栈复杂性。

● 应对现代架构 :现代架构向云原生和微服务的转变对 MySQL 这样的单机系统提出了挑战。

当企业的基础设施无法满足需求,数据规模从 1TB 增长到 100TB+,同时仍期望保持相同的性能时,这些限制带来的不便就愈发明显。

2、探索替代方案:MySQL 5.7 EOL 后,何去何从?

随着 MySQL 5.7 EOL 即将到来,现在是重新评估选择并为未来的数据处理能力做好准备的时候了。

Option 1

升级到官方支持的 MySQL 版本

这涉及从 MySQL 5.7 迁移到较新版本,如 MySQL 8.0,由 Oracle 提供维护和支持。

● 优点 :这个选项确保了对现有 MySQL 架构的持续支持,能够持续获取新功能和性能改进。通常,这是最简单的选择,因为它对现有基础设施和应用代码的改动较少。

● 缺点 : 升级到较新版本的 MySQL 并不能解决 MySQL 架构导致的扩展性、高可用性和处理现代云原生架构相关的固有挑战。同时,它还依赖于 Oracle 接下来的战略方向,比如对 MySQL 产品的支持力度。

Option 2

采用第三方 MySQL 商业版本

像 MariaDB 和 Percona Server 这样的 MySQL 分支版本是由第三方公司独立开发,为 MySQL 用户提供了替代路径。

● 优点 : 这些分支版本通常能够比 MySQL 本身更快地引入功能和性能改进。转向分支版本可以依旧获取持续的支持、与 MySQL 兼容的特性的熟悉性以及潜在的增强功能。

● 缺点 : 与 MySQL 一样,这些分支版本在处理高并发的写入密集型工作负载,或在分布式架构中部署时仍面临挑战。此外,支持的力度可能有所不同,一些企业可能不愿意对由社区驱动的项目提供更多的支持。

Option 3

迁移到分布式数据库

如果现有的应用程序需要超出单个 MySQL 实例所能提供的可扩展性和高可用性,那么分布式数据库(如 TiDB)可能是一个合适的选择。

● 优点 : 分布式数据库将传统关系型数据库管理系统(RDBMS)的优点(ACID 特性、对 SQL 的支持)与 NoSQL 系统的优点(水平可扩展性、高可用性)结合在一起。特别是 TiDB,完全兼容 MySQL 5.7,使得迁移变得更加容易。

● 缺点 : 迁移到分布式数据库的过程可能需要进行全面评估,而不仅仅是简单地升级 MySQL 或切换到分支版本。虽然 TiDB 兼容 MySQL,但可能不支持某些 MySQL 特定的功能,并且可能需要对现有的应用程序代码进行一定范围的调整。

3、TiDB ——兼容 MySQL 的分布式数据库

想象一下,如果既能够像操作 MySQL 一样熟悉,同时又获得分布式数据库系统的可扩展性和可用性,那该多好?这恰是 TiDB 所擅长的。

TiDB ( https://www.pingcap.com/tidb/ ) 是由 PingCAP 开发的领先的开源分布式数据库。它无缝地结合了关系型数据库和 NoSQL 数据库的优势,将传统关系型数据库管理系统的 ACID 特性、 SQL 兼容性与 NoSQL 系统的水平可扩展性相结合。

article-body

图 1:TiDB的架构

以下是 TiDB 提供的主要功能的详细介绍:

● 水平扩展性 :TiDB 的分布式架构允许数据自动分片到多个节点上。随着工作负载的增长,您可以轻松地向集群添加更多节点来处理不断增加的需求,而不会出现显著的性能下降。

● 高可用性 :TiDB 通过在多个节点上复制数据来保持数据的冗余,并实现了自动故障切换。即使集群中的一个或多个节点故障,也能确保您的数据保持可访问状态。

● 强一致性 :在许多分布式数据库中,一致性和可用性之间存在权衡。但是 TiDB 不是这样。它使用一种称为 Percolator 的分布式事务协议,保证了快照隔离一致性,确保集群中的所有节点对数据具有一致的视图。

● MySQL 兼容性 :TiDB 支持 MySQL 协议,并且与 MySQL 语法具有广泛的兼容性。这意味着许多现有的应用程序、框架和针对 MySQL 设计的工具可以与 TiDB 一起使用。

● 实时分析 :TiDB 利用 混合事务/分析处理(HTAP) 的能力,实现实时运营分析。TiKV、TiFlash 可按需部署在不同的节点上,解决 HTAP 资源隔离的问题。TiDB 提供了一个统一的平台,用于即时高效地分析运营数据。

● 云原生架构 :TiDB 设计时考虑了云原生的原则,因此非常适合在云环境中部署。它支持 Docker 和 Kubernetes 等容器化技术,并集成了阿里云、AWS、GCP 等云平台。

总结

数据库选型是一项关键决策,它对组织的增长和成功有着重大影响。随着 MySQL 5.7 EOL 到来,现在是 MySQL 用户进行评估、计划并为未来做好准备的时候了。如果您面临可扩展性、高可用性、实时分析或适应云原生架构等挑战,从 MySQL 迁移到分布式数据库(如 TiDB)可能是一个理想的选择。

然而,同样重要的是,要认识到 MySQL 和 TiDB 在 MySQL 生态系统中可以共存并相互协作的可能性。许多客户已经意识到同时使用 MySQL 和 TiDB 的好处,特别是对于大规模应用程序而言。通过在使用 MySQL 的同时,企业利用 TiDB 可以实现更高的可扩展性、高可用性和混合工作负载处理能力。这种协同作用可以实现无缝的数据管理,并满足现代应用程序不断发展的需求。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK