1
一名开发者眼中的TiDB与MySQL选择.pdf
10墨值下载
一名开发者眼中的TiDB与MySQL选择
原创数据库架构选型
TiDB长期霸榜国产数据库第一名，社区活跃人气旺盛。作为TiDB其中的一个粉丝，我把近年的学习调研
实践归纳如下，TiDB是一款通用性的数据解决方案，任何数据场景都可以使用它来解决问题，所以它与
所有市场上所有的数据库产品 多多少少存在直接上的或者间接上的竞争关系。
那么市场竞争上谁是TiDB的第一梯队竞争对手,本人认为是MySQL是其中一个，当然也可以是Oracle、
DB2等等，主要是MySQL在中国深入人心，工程师信手拿来就能使用。
TiDB与MySQL的对比
有些人直接称TiDB为大号的MySQL，其实不对，为了工程师像使用MySQL使用TiDB，TiDB在接口层下
了大量的功夫，在语法、表名、引用甚至元数据方面尽量与MySQL贴合，但是每个语句背后执行的都是
不同的数据流程和服务流向。
类型上比较，MySQL是纯粹单机式数据库，TiDB是分布式数据库，TiDB可以方便自由增加节点扩展存
算能力，而MySQL增加节点增强性能，必须通过定向策略，例如中间件路由或者读写分离的方式，显得
呆滞固化。
引擎上比较，MySQL有myisam、innodb、memory等引擎 ，也可以通过插件支持更多的引擎例如
rocksdb，HandlerSocket等等，而TiDB虽然只有两个引擎,但是却能应对所有的应用场景。
架构上比较，MySQL是偏紧密耦合，分为三层分别是接口层、服务层、存储层，接口层负责请求处理、
授权认证、安全，服务层负责查询解析、分析、优化、缓存、系统内置函数，存储层负责数据的 存储和
处理，统一体现在一个服务进程上。TiDB则是松散耦合型，把数据库的关键组件抽象，根据本身分布式
的特性，分别是计算层、存储层、协调层。
TiDB计算层类似MySQL接口层，负责负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过协调层找
到存储计算所需存储层数据的地址，与 存储层交互获取数据，最终返回结果。
TiDB存储层负责存储数据，数据的存储容量没有上限，存储层上同一份数据一般有3个副本，满足
高并发需求。协调层会对存储层中的数据做出负载均衡的处理。
TiDB协调层负责集群的管理模块，经常干的事情有3个，一个是集群的元信息，一个是对存储层的
数据进行调度和负载均衡，一个分配全局唯一且递增的事务 ID。
数据处理技术上，MySQL是B+树的组织存储结构，B+树适合读多写少，如果写多了，写的影响动作主
要是插入、删除，会导致全局的平衡树下面的页频繁分裂或者合并，直接影响性能，影响读放大。TiDB
是LSM树的组织存储结构,擅长写多读少，如果读多了，在内存扫描不到数据，就会去硬盘里面去寻找无
序的sst文件，所以数据越多越大就会读放大。
处理存储上，MySQL类似微内核，微内核架构由核心服务和插件模块组成，核心服务负责请求后处理机
制流程并进行优化，插件模块主要用来放置 置处理存储的引擎，引擎决定性能上限， 微内核的插件式对
开发者友好，可以自由扩展，所以MySQL派生了infobright、MyRocks等第三方相关引擎，TiDB的核心
服务分散在tidb模块和pd模块里面，两者协同工作构成请求解析、处理、优化及其它服务功能 ， tikv模
块和tiflash模块则是引擎。无论是顺序读写还是随机读写，核心服务协同背端的引擎工作串成整个数据
全链条过程，MySQL是单机单进程的内部去完成这个过程的，而TiDB是分布式多进程完成这个过程的。
产品方向上比较，MySQL默认innodb，擅长OLTP的业务场景，同时MySQL可以插件组装各式引擎，换
言之MySQL是一个通用型的数据库产品支持所有的业务场景。而TiDB默认悲观事务，同样是以OLTP为
重，同样是一个通用型的数据库产品。但是两者是不一样的，由于MySQL是单机型的结构，如果它要扩
展，只能通过数据库中间件路由划分，如果数据满了需要停机停服，重新进行数据的割分。
TiDB对业务无侵入性，扩展非常简单，发展至今安装与维护都非常成熟 ，通过Tiup就可以就可以对分布
式集群进行组装维护的相关操作，并且支持在线升级，无缝迁移。
总结，TiDB与MySQL没有对比性， 他们不是同一类的数据产品，但是从数据库的特性和市场方向上出
发 ，他们又有了对比的维度指标。事实上，TiDB努力向MySQL学习，甚至还聘请了innodb的内核开发
工程师，努力调整TiDB的底盘，让TiDB从内向外都像MySQL。
同类竞争产品
TiDB是一款分布式数据库产品，以分布式为标识并能基于线下安装 ，国内同样竞比产品有
OceanBase，国外同比有CockroachDB。TiDB的商业经营主要集中在云数据库上，所以PolarDB也是
TiDB的竞争对手。那么TiDB与PolarDB、OceanBase、CockroachDB有什么不同？
从数据库处理的流程开始讲，从任务开始到任务结束。
1. 用户发起请求， 数据库客户端发起请求到指定的数据库集群。
2. 目标数据库响应 指定的数据库集群指定一个节点响应用户的请求。
3. 两者建立会话， 数据库集群其中一个节点与客户端产生会话。
4. 对象请求解析， 数据库将接收的请求进行 语法检查，对象解析、转换对应的关系代数结构、并进
行计划任务优化。
5. 调度并且执行， 按照拆解的计划寻找数据并进行计算，数据可能是按行式存放的，也可能是按列式
存放的【 TiDB是少数不多的产品中同时提供行式存储和列存存储的厂商】
6. 监测任务状态， 观测数据库的执行中状态。
7. 返回数据结果， 数据库服务端返回结果给数据库客户端
最关键的是第2步、第4步、第5步。
第2步是 哪一个节点响应数据库客户的请求，分布式数据库有两种系统架构，一种是中心化架构
【master\slave】，一种是去中心化架构。中心化架构的负色职责分清，负责干活、负责指挥、负责接
待用户，而去中心货架构则是每个节点角色平等，对待客户的请求，其中的一个节点会瞬间切换成负责
接待，剩余的节点根据情况转化执行。
TiDB在这里采用中心化的架构，节点角色之间的职责更加清晰，分工更加明确。
第4步和第5步是数据计算和数据存储的关键步骤，TiDB在这里做了深度的松散解耦，数据计算用TIDB，
数据存储用TIKV，两者是真正意义上的存算分离，要增加存储容量，可以增加没有CPU的硬盘服务器，
要增加计算能力，可以增加没有硬盘的服务器。关于分布式的功能和作用则集中在一个PD的模块上。
OB则是去中心架构，而且计算和存储高度耦合，所以OB又称为集中式的分布式架构，后面又称为单机
式的分布式架构。
TiDB比起同类产品在架构上更加高度松散耦合，与云计算技术更加紧密协作，珠联壁合。
TiDB vs MySQL
如果TiDB要做大做强，必须要撼动广大码农的工作使用习惯，广大码民对MySQL的使用已经深入人心
了，不管是TP应用，还是AP应用，先不管性能，首先用MySQL完成业务代码的开发，这意味着MySQL
经常被当HTAP数据库来用。下面我用CH-benchmark 针对 TiDB6.0以及MySQL8.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 中的原始
of 10
10墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论