前言
岁月是一把杀猪刀，我把近几年对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个表包括suplier表供应商信息、nation表国家信息、region表地区信息、customer表用户表、part表商品表、partsupp表商品供应表、orders表零售订单表、lineitem订单明细表构成最基本元素的电子商务框架，可以视为最通用的数据库设计，基于范式设计的结构如下，一个电子商务应用网站上线了。
一个可靠稳定的电商平台不但可以承担成千上万的流量，而且安全无误的执行每个行为。举个例子，商品上线一万个商品，有十万个客户上来争相哄抢。底层背后，相同一个数据对象被多个人浏览阅读，放入购物蓝、生成订单、交易结帐后客户的钱包扣钱，而商家帐户正确流入客户资金 ，同时商品数目正确扣减。保障客户、商家、商品数目的一致性，即使服务器宕掉、网络延迟、自然灾害导致的地震海啸或者人为主观的恶意性的原因，三者依然保持一致性，不会发生客户扣钱了但是商家没有收到了，或者商家入帐了而客户那边还没有扣钱，商品数目与交易数量对不上出现超买超卖的情况。
更加不可能发生停止对外提供服务的可能性，交易窗口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%的问题 。
