共计 5382 个字符，预计需要花费 14 分钟才能阅读完成。
前言
岁月是一把杀猪刀，我把近几年对 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
