前言

岁月是一把杀猪刀，我把近几年对TiDB的回顾、思考、了解、定义写成一段实在的故事，做为国产数据库人气一哥成长的见证者，我看着他一路成长，心愿TiDB前面的路能够越走越顺。

2018年

初识TIDB,那是2018年8月份，过后基于国产数据分析产品调研的背景，我在网上东寻西找，搜查奇珍异宝，而后TiDB跃入眼前。2017 易观 OLAP 算法大赛，TiDB竟然取得冠军，这个较量我有关注过，没有想到是TiDB拿了冠军，TiDB是谁？它做了一些什么？ 第二名是咱们耳熟能详的Clickhouse，竟然比Clickhouse还快，置信工程师都好奇了。回顾2017 易观 OLAP 算法大赛题目，这是一道用户剖析业务场景，漏斗剖析题目，咱们在购买商品的过程中，须要触发的事件包含 “启动”，“登陆”，“搜寻商品”，“查看商品”，“生成订单”并在零碎后盾生成相干数据。业务需要如下

（1）计算2017年1月份中，顺次有序触发“搜寻商品”、“查看商品”、“生成订单”的用户转化状况，且工夫窗口为1天。

（2）计算2017年1月和2月份中，顺次有序触发“登陆”、“搜寻商品”、“查看商品”、“生成订单”、“订单付款”的用户转化状况，且工夫窗口为7天，“搜寻商品”事件的content属性为Apple，“浏览商品”事件的price属性大于5000。

依据官网的介绍，市面上现有的解决方案在数据量较大的状况下，计算效率较低，为了更好的晋升用户体验，如何更好的解决问题。官网给出60分合格的解决方案，1底层存储用HDFS，2建设Hive表，并以利用标识、日期、事件名称为分区，3查问用presto，并自定义UDAF，或者利用Spark core自定义雷同逻辑。

即便基于内存的presto的解决方案，也是刚及格而已，我的对TiDB的刻画，记录在2018年我的《XXX报告》外面，如下

之前咱们介绍的另外一个数据服务公司易尚国内，它举办了数据大赛，由PINGCAP取得了冠军， PingCap的产品叫做TIDB。精确来说TIDB不是一个数据查问引擎，它是一个数据库，性质属于 NEWSQL,它是立于谷歌spaner/F1的论文思维。TiDB 的设计指标是 100% 的 OLTP 场景和 80% 的 OLAP 场景 ,一脚踏两船，在OLTP和OLAP两个畛域提供一站式的解决方案。

我对TIDB的第一印象是此物一心两用，主业是OLTP，副业是OLAP，一脚踏两船，然而我始终没有搞明确它是怎么做到一脚踏两船。过后我印象中它曾经GITHUB开源，然而文档社区没有那么成熟，所以笔者没有开展装置测试摸底。下图是当初调研的数据库，过后没有gauss，没有OceanBase。

2019年

2019年，TiDB的市场推广十分胜利，周边的小伙伴都晓得TiDB，然而我始终不理解TiDB的技术细节，只晓得它是大一号的MySQL,MySQL能做的它都能做，MySQL不能做的它也能做。终于一天，我下定决心，在本人的虚拟机上，通过ansible装置了3个节点阵容，每个节点是4C和4G，基于tpc-h做了基准测试，并把实践意识付诸实践，做了相干的试验验证，对TiDB有了宏观的理解。

我始终好奇2017年的TiDB是怎么拿下较量的冠军？那是一场OLAP较量， 过后TiDB还没有Tiflash引擎，次要分为三大块，别离是TiDB、TiKV、PD, TiDB自身是无状态的计算引擎，预计过后做了特地设置使热数据都沉闷在TiDB外面，如果是冷数据再往TiKV查找。在数据写入硬盘的底层方面，TiDB选用了RocksDB，RocksDB兼容LevelDB原有的API，并且对LevelDB进行了一系列的优化，包含对SSD硬盘的优化，针对多CPU、多核环境进行优化，减少了LevelDB不具务的性能，例如数据合并、多种压缩算法、按范畴查问等数据存储管理的能力，RocksDB就是TiDB的性能天花板。2017年的易观大赛，过后没有Tiiflash的情况，TiDB基于此等条件取得了冠军。

TiDB前面的翻新，将OLTP存储与OLAP存储解耦，OLTP的性能天花板是RocksDB,而OLTP写数据的时候，会有一份数据写入TiFlash，OLTP存储与OLAP存储物理拆散，对外却是对立的逻辑管理系统，TiDB提供SQL拜访拜访入口，让传统的DBA能够像应用MySQL那样应用TiDB。

2020年

TiDB非常重视用户的感触和产品的品质，2020年TiDB做了两个事让我历历在目，一个是TiUP，TiUP是对一个TiDB集群的生命周期治理保护的我的项目。发动这个我的项目的起因，过后TiDB做了调研，即便大厂的研发工程师装置一个低配的TiDB集群至多也要花费三个小时，所以有了TiUP我的项目，通过TiUP很快就部署了一个TiDB环境。第二个是产品抓虫的大赛，每一个产品都有BUG，TiDB推心置腹，悬赏找虫，不分地界，引起国外工程师的关注，其中苏黎世理工大学的Dr. Manuel Rigger通过援用最新技术NoREC找出最多的BUG。开源无国界，TiDB致力于开源技术布道，同时也在寻找市场上商业机会，推出的TiDB Cloud也失去人们肯定的认可，TiDB Cloud立足于TiDB技术内核实现云计算的弹性麻利可用性，让宽广开发者更方便使用TiDB。

2021年

2021年TiDB推出5.0版本，在原有 HTAP 引擎 TiFlash 的根底上引入 MPP 架构，提供与存储匹配的分布式计算引擎，进一步晋升海量数据下的并行计算与剖析能力。通过与 TiDB-Server 共享 SQL 前端，实现解析器（Parser）和优化器的共享，TiDB 向业务提供一体化的入口，可能主动抉择单机执行或 MPP 模式，并且将事务型和剖析型的负载隔离，使得单方在高并发量压力下互不烦扰。这个时候我十分好奇TiDB模块的优化器的工作细节，当初的5.0版本，它要辨认单读还是批量操作，还要思考Tiflash的数据分布和继续的数据管理，数据是从OLTP还是从OLAP找，TiDB承载的智能调度工作量比以前大了，它须要比以前更多与TIKV和PD合作能力高质量实现工作。

TiDB Hackathon 2021大赛，He3 团队就抉择了冷热数据分层存储，设计中将热数据寄存在 TiKV 上，将查问和剖析几率比拟少的冷数据寄存到便宜通用的云存储 S3，同时使 S3 存储引擎反对 TiDB 局部算子下推，实现 TiDB 基于 S3 冷数据的剖析查问。其实这就是业界谋求的智能数据集成系统利用场景，集成系统可能辨认宽广的数据源，包含RDBMS、NOSQL、分布式系统、文件系统等等，可能对进行辨认并进行连贯，采集数据到最近的存储系统外面，这样第二次第三次间接去最近的存储系统。要害核心技术挑战是智能调度辨认最近的存储系统与数据源的一致性， 同理TiDB在这里要辨认TiKV和S3的一致性，对TiDB提出更高的要求。

我定义了TiDB模块的概念范畴，TiDB模块是一个实现分布式【包含单机计算能和批量计算】、无状态、实现SQL、客户端输出连贯会话治理的计算引擎。开源界有一个Presto,然而Presto是齐全局限于内存的解决能力，然而Presto没有存储引擎成为不了数据库，TiDB与PD和TIKV联结在一起成为数据库， 独立TiDB的模块能够嵌入集成到其它零碎上，例如冷热数据分层存储，整个数据集成数据链路中，TiDB作为智能调度解决组件，承当上下游数据的治理传输。

从TPC-H和TPC-DS意识TiDB

小白出身农民，立志改变命运，终于开了五金的电子商务批发网站，天下还有很多像小白一样的人们，他们都想趁着互联网浪潮，趁势而下，大赚一笔，然而他们未必是五金生意，有可能是外卖，有可能是玩具，有可能是生活用品。不论销售什么，至多有供应商、用户、商品等独立根底实体， 依赖根底实体之上有商品洽购入货和商品外售的记录，如果咱们往细节查究，还有商品评估、商品珍藏、商品营销方面的考量，这里咱们疏忽它。8个表包含供应商信息、国家信息、地区信息、用户表、商品表、商品供给表、批发订单表、订单明细表形成最根本元素的电子商务框架，能够视为最通用的数据库设计，基于范式设计的构造如下，一个电子商务利用网站上线了。

一个牢靠稳固的电商平台岂但能够承当成千上万的流量，而且平安无误的执行每个行为。举个例子，商品上线一万个商品，有十万个客户上来争相哄抢。底层背地，雷同一个数据对象被多集体浏览浏览，放入购物蓝、生成订单、交易结帐后客户的钱包扣钱，而商家帐户正确流入客户资金 ，同时商品数目正确扣减。保障客户、商家、商品数目的一致性，即便服务器宕掉、网络提早、自然灾害导致的地震海啸或者人为主观的歹意性的起因，三者仍然放弃一致性，不会产生客户扣钱了然而商家没有收到了，或者商家入帐了而客户那边还没有扣钱，商品数目与交易数量对不上呈现超买超卖的状况。

更加不可能产生进行对外提供服务的可能性，交易窗口24小时对外开放，不休不眠，对于互联网来说，每一秒都是金钱。基础设施稳固牢靠、服务平台稳固牢靠、零碎服务稳固牢靠，业务工作的过程中始终被审计，不论呈现什么问题都要可追溯、可跟踪。

对于业务一直递增的电商平台，传统的单机解决方案要存在IO瓶颈，无奈应酬高流量，而NOSQL解决方案齐全否决关系范式建模，只能用文档建模或者键值健模对原生业务利用侵入大，给传统利用开发工程师加大了工作量。中间件解决方案诚然解放了利用开发工程师的生产力，却给后盾的DBA带来更多的运维工作。1.减压问题，其中一个节点压力过大，如何保障业务失常的前提下把压力转移到其它节点下面。2.扩容 退出新的节点，如何让新节点正好划分适合的数据。

当这个电子商务网站积淀了大量的数据，须要做数据分析去了解用户的偏好和市场的需要。基于8个表的构造，咱们构建了22个模型，这个就是tpc-h基准测试了。每个模型都少了多表关联，最长的有4个表关联或者5个表关联，关联后做聚合、过滤、分组、归并、排序等等。

为了深刻了解用户的偏好和市场的需要，数据维度越来越多，须要退出评估、珍藏、浏览、点藏维度，而且数据的一直增长，与数据计算能力呈反比，增加更多的服务器诚然能够进步计算能力。然而打消冗余的范式建模不适宜简单业务剖析景，例如拉链表，每天减少那么一丁点数据，业务上心愿那一点变动产生在单表上，分析模型底层太大变动。

阿里的业务也是维度建模，维度建模不像关系建模那样打消数据冗余，相同它集成更多的数据冗余，进步计算能力，tpc-ds就是采取了维度建模，tpc-ds与tpc-h的的本质区别就是不同角度的利用建模，tpc-h还可能为OLTP在线应用服务，而tpc-ds齐全没有思考范式，更加关怀剖析主题。tpc-ds模型模拟一个全国连锁的大型零售商的销售零碎，其中含有三种销售渠道：store（实体店）、web（网店）、catalog（电话订购），每种渠道应用两张表别离模仿销售记录和退货记录，同时蕴含商品信息和促销信息的相干表构造。TPCDS采纳雪花型数据模型，三种渠道的销售、退货表、及总体的存货清单作为事实表，其余商品相干信息、用户相干信息、工夫信息等其余信息等都作为维度表，同时各表命名达到见名识义，具体如下表所示：

很显著，tpc-ds的业务主题是销售渠道分析模型，依据模型业务人员很快能够进行渠道比拟、渠道强弱，渠道环节比照、购买订单剖析，然而不善于财务分析模型、人力资源分析模型、装运分析模型、库存治理分析模型。7张事实表和17张维度表如下，简略两表关联通过星型模型实现大部分的业务剖析场景，再简单的业务通过雪花模型也能够实现。

tpc-h的特色如下

  • 测试大规模数据，解决大数据问题
  • 对理论商业问题进行解答
  • 执行需要多样或简单的查问（如长期查问，报告，迭代OLAP，数据挖掘）
  • 以高CPU和IO负载为特色，
  • 通过数据库保护对OLTP数据库资源进行周期同步

后面说过了TPC-DS采纳维度建模，与TPC-H的范式建模，所以必须要产生ETL过程。事实版的TPC-DS利用要买通多个数据源，对接多个数据库，对数据进行荡涤、整顿、标准，对立置放到数据仓库外面。依据业务调整数据分层分类分级，设计面向主题的数据集市，特地须要全局和倒退的视角，建模应该在了解整体业务流程的根底上。

结尾

最初概括TiDB解决的问题 ，TiDB是一个开源的、分布式、计算存储拆散、弹性可扩大、反对行式列式、实现HTAP性能的数据库。首先它能够做业务利用的数据库，勿论它的OLTP能够去到多少并发，必定会比MySQL高，事务、ACID、并发、封闭、串行化它都反对，所以解决100%的业务问题，当数据存储积淀到Tikv，同时会雷同的数据积淀到TiFlash，TiFlash是列存存储，TiDB对TiFlash的拜访操作是通过MPP的形式进行，然而因为关系范式建模的起因，TiDB可能以相似TPC-H简单的SQL做数据查问，充其量只能解决30%的剖析问题。更简单的数据利用零碎建设，须要通过本身的生态工具把数据从TIKV转移到HADOOP，另立数据仓库从新维度建模组织治理，能够解决70%的问题 。

文章作者：angryart 公布工夫：2022/3/25
原文链接： 从2018到2022: 一个大数据工程师眼中的TiDB