一名开发者眼中的 TiDB 与 MySQL 的选择丨 TiDB Community
作者:
大数据模型
对制造业、银行业、通讯业了解多一点,关心专注国产数据库技术布道以及数据资产建设的应用实践。
导读
随着 MySQL 8.0 的发布和即将到来的 5.7 版本的停止支持,许多 MySQL 用户正面临升级和转型的抉择。本文为 TiDB 社区用户撰写,以一名开发者的视角,深入探讨和比较了 TiDB 和 MySQL 的差异。希望通过本文,能为读者在架构选型方面提供一些帮助和指导 。
TiDB 在墨天轮国产数据库排行榜中长年位列前茅,社区活跃度高且人气旺盛。那么 TiDB 使用场景相似产品中,有哪些比较优秀呢?我认为其中一个是 MySQL——毕竟在中国,MySQL 早已深入人心,并且工程师们能够轻松地运用它。
TIDB 与 MySQL 的对比
有些人直接将 TiDB 称为"大号的 MySQL",但实际情况并非如此。为了使工程师们能够像使用 MySQL 一样使用 TiDB,TiDB 在接口层进行了大量的改进。它在语法、表名、引用甚至元数据等方面尽量与 MySQL 保持一致,但是实际执行的每个语句背后都有不同的数据流程和服务流向。因此,尽管在表面上它们相似,但其背后的数据处理和服务机制是不同的。
类型方面 ,MySQL 是纯粹单机式数据库,TiDB 则是分布式数据库。TiDB 能够方便自由地增加节点来扩展存算能力,而 MySQL 则需要通过定向策略,如中间件路由或读写分离等方式来增加节点以提升性能,这使得 MySQL 的扩展性相对受限且相对僵化。
引擎方面 ,MySQL 拥有多个引擎选项,如 MyISAM、InnoDB、Memory 等,并且可以通过插件支持更多的引擎,如 RocksDB 和 HandlerSocket 等。而 TiDB 虽然只有两个引擎选项,但却能够应对各种应用场景的需求。
架构方面 , MySQL 是偏紧密耦合 ,分为接口层、服务层、存储层三个层次。接口层负责请求处理、授权认证和安全性,服务层负责查询解析、分析、优化、缓存和系统内置函数,存储层负责数据的存储和处理,所有这些组件都在一个服务进程中统一运行。 而 TiDB 采用松散耦合的架构,将数据库的关键组件进行抽象,并根据其分布式特性划分为计算层、存储层和协调层。
● TiDB 计算层类似 MySQL 的接口层,负责接收 SQL 请求,处理 SQL 相关的逻辑,并通过协调层找到存储层数据的位置。它与存储层进行交互以获取数据,并最终返回结果。
● TiDB 的存储层负责数据的存储,其存储容量没有上限。通常情况下,存储层会为同一份数据维护 3 个副本;以满足高并发需求。协调层会对存储层中的数据进行负载均衡的处理。
● TiDB 的协调层是集群的管理模块,其主要工作包括三个方面:管理集群的元信息、调度和负载均衡存储层的数据,以及分配全局唯一且递增的事务 ID。
数据处理技术上 ,MySQL 是 B+树 的组织存储结构,B+树适合读多写少,如果写多了,写的影响动作主要是插入、删除,会导致全局的平衡树下面的页频繁分裂或者合并,直接影响性能,影响读放大。 TiDB 是 LSM 树的组织存储结构,擅长写多读少,如果读多了,在内存扫描不到数据,就会去硬盘里面去寻找无序的 sst 文件,所以数据越多越大就会读放大。
处理存储上 ,MySQL 类似微内核,微内核架构由核心服务和插件模块组成, 核心服务负责请求后处理机制流程并进行优化,插件模块主要用来放置 置处理存储的引擎,引擎决定性能上限 , 微内核的插件式对开发者友好,可以自由扩展,所以 MySQL 派生了 infobright、MyRocks 等第三方相关引擎,TiDB 的核心服务分散在 TiDB 模块和 PD 模块里面,两者协同工作构成请求解析、处理、优化及其它服务功能 , TiKV 模块和 TiFlash 模块则是引擎。无论是顺序读写还是随机读写, 核心服务协同背端的引擎 工作串成整个数据全链条过程,MySQL 是在单机单进程的内部去完成这个过程的,而 TiDB 是分布式多进程完成这个过程的。
产品方面 ,MySQL 默认使用 InnoDB 引擎,擅长处理 OLTP 的业务场景。同时,MySQL 还支持插件组装各种引擎,使其成为一个通用型的数据库产品,适用于各种业务场景。而 TiDB 默认采用悲观事务的方式,同样专注于 OLTP,也是一个通用型的数据库产品。然而,这两者之间存在一些差异。由于 MySQL 是单机型结构,如果需要进行扩展,只能通过数据库中间件路由的方式进行划分。而如果数据已满,就需要停机或停服,重新进行数据的分割。
TiDB 具有对业务的无侵入性,且扩展非常简单。在其发展至今,安装和维护方面已经非常成熟。通过 TiUP 工具,可以轻松进行分布式集群的组装和维护操作,并且支持在线升级和无缝迁移。这使得使用 TiDB 的过程更加便捷和高效,使用户能够更好地管理和运维他们的分布式数据库系统。
综上所述,TiDB 与 MySQL 属于不同类型的数据产品,并不能直接进行对比。然而,从数据库的特性和市场趋势的角度来看,它们可以有一些维度上的对比指标。事实上,TiDB 致力于向 MySQL 学习,并且还聘请了 InnoDB 的核心开发工程师,致力于调整 TiDB 的底盘,使其在内部和外部都更像 MySQL。
同类竞争产品
TiDB 是一款 分布式数据库产品 ,它以分布式为标识并能基于线下安装,在国内外都有类似的产品。那么 TiDB 与其他产品有什么不同?参照数据库处理的流程,我将从任务开始到任务结束来详述。
1. 用户发起请求:数据库客户端向指定的数据库集群发起请求。
2. 目标数据库响应:数据库集群的指定节点响应用户的请求。
3. 两者建立会话:数据库集群其中一个节点与客户端产生会话。
4. 对象请求解析 :数据库对接收到的请求进行语法检查、对象解析,并将其转换为对应的关系代数结构,然后进行计划任务优化。
5. 调度并且执行:寻找最合适的副本,根据优先级进行,是内存、缓存、数据快照、存储等等。
6. 监测任务状态:数据库监测执行中任务的状态。
7. 返回数据结果:数据库服务端将执行结果返回给数据库客户端 。
上述环节中,最关键的是第 2 步、第 4 步和第 5 步。
第 2 步是 哪一个节点响应数据库客户的请求,分布式数据库有两种系统架构,一种是中心化架构【master\slave】,一种是去中心化架构。中心化架构的负色职责分清,负责干活、负责指挥、负责接待用户,而去中心化架构则是每个节点角色平等,对待客户的请求,其中的一个节点会瞬间切换成负责接待,剩余的节点根据情况转化执行。
TiDB 在这里采用中心化的架构,节点角色之间的职责更加清晰,分工更加明确。
第 4 步和第 5 步是数据计算和数据存储的关键步骤,TiDB 在这里做了深度的松散解耦,数据计算用 TiDB,数据存储用 TiKV,两者是真正意义上的存算分离,要增加存储容量,可以增加没有 CPU 的硬盘服务器,要增加计算能力,可以增加没有硬盘的服务器。关于分布式的功能和作用则集中在一个 PD 的模块上。
采用集中式的分布式架构的产品则采用了去中心架构,而且计算和存储高度耦合,又称为单机式的分布式架构。
TiDB 比起同类产品在架构上更加高度松散耦合,与云计算技术更加紧密协作,珠联璧合。
TiDB VS MySQL
如果 TiDB 要做大做强,必须要撼动广大开发人员的工作使用习惯。大部分开发人员已经十分熟悉并广泛使用 MySQL,无论是在 TP 应用还是 AP 应用中。不论性能如何,他们首先会选择 MySQL 来开发业务代码。这也意味着 MySQL 经常被用作 HTAP 数据库。接下来,我将使用 CH-benchmark 来对 TiDB 6.0 和 MySQL 8.0 进行一项测试。
TPC-CH 由未经修改的 TPC-C 模型和事务、以及 TPC-H 查询的改编版本构成,TPC-CH 保持所有 TPC-C 实体和关系完全不变 ,并集成了 TPC-H 模型中的 SUPPLIER、REGION 和 NATION 表。这些表在 TPC-H 查询中频繁使用,并允许以非侵入的方式集成到 TPC-C 模型中。SUPPLIER 包含固定数量(10,000 条)的条目。因此,STOCK 中的一条记录可以通过 STOCK.S I ID × STOCK.S W ID mod 10, 000 = SUPPLIER.SU SUPPKEY 与其唯一的供应商(SUPPLIER 表中对应记录)关联起来。TPC-C 中的原始 CUSTOMER 表不包含引用自 NATION 表的外键。我们并没有改变原始模型,从而保持了与现有 TPC-C 的兼容性,所以外键是从字段 C STATE 的第一个字符开始计算的。TPC-C 规定第一个字符可以有 62 个不同的值(即大写字母、小写字母、数字),因此我们选择了 62 个国家来填充 NATION。根据 TPC-H 规范,主键 N NATIONKEY 是一个标识符。它的值被规定,从而使得与这些值相关联的 ASCII 值是一个字母或数字,即 N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97. 122]。因此,不需要额外的计算来跳过 ASCII 码中数字、大写字母和小写字母之间的间隔。不支持从字符转换到 ASCII 码的数据库系统可能会偏离 TPC-H 模式,使用单个字符作为 NATION 的主键。REGION 包含国家的五个地区。新表之间的关系使用简单的外键字段来建模:NATION.N REGIONKEY 和 SUPPLIER.SU NATIONKEY。
在 CH-Benchmark 中结合了 TPC-C 和 TPC-H 两种基准 ,它把原来 TPC-C 中的 9 个表和 TPC-H 中的 8 个表修改合并成了 12 个表,并将两者的伸缩模型也统一起来(Scaling TPC-H by the same factors of TPC-C)。
测试环境
硬件配置
测试配置
生成数据
在我的实验中,我使用了 TiDB Bench 对数据进行了压测,生成这些数据的工具是 CH-benchmark。
安装 CH-benchmark
4.1 建表语句
4.2 导入数据
4.3 运行压测命令
192.168.2.x 上面安装 tiup bench
4.4 测试摘要
4.4 测试总结
保留对 MySQL8.0 和 TiDB6.0 的内部参数不变, 单纯从单机 load data 数据插入、 tpmC 性能、以及 tpc-h 的性能数据表面来看,MySQL8.0 要比 TiDB6.0 要好。然而,实际情况并非如此,因为 TiDB 还有很大的调优空间。正如前面提到的,它们是两个不同的产品线,但这里证明了 TiDB 的友好性。它是十分兼容 MySQL 的,如果你从单机版的 TiDB 开始,随着业务的扩大,你可以自由、轻松地进行扩展。
我对 TiDB 的展望
软件开发的角度,TiDB 的解耦是完整的,如今 TiDB 已经发展到了 7.0 版本。 我对 TiDB 未来的期待有三个方面 : TiDB 模块源代码,可以做为分布式计算基础参考,派生更多的可能性,类似 presto 的路线延伸;TiKV 模块源代码,可以作为分布式存储参考,以后的发展方向可能是文件数据存储;PD 模块源代码的技术路径发展是轻量级的元数据存储的管理,三者兼进,TiDB 将能够最大化地帮助用户降低存储成本,提升计算弹性,通过分布式实现元数据最优存储,灵活、可靠,在更多场景得到应用。
评论