Hi~各位读者朋友们，感谢您阅读本文，我是笠泱，本期分享一个国内自研且开源的NewSQL数据库TiDB，当逐渐了解后笔者给予四个字评价“岂止强悍！”简直是数据库中的六边形战士，几乎满足了对数据库的所有需求，完整阅读本文大约需要30分钟。

本期导语

数据库技术发展简史

数据库技术产生于20世纪60年代末70年代初，其主要主要研究如何存储，使用和管理数据。随着计算机硬件和软件的发展，数据库技术也不断地发展。数据库技术在理论研究和系统开发上都取得了辉煌的成就。

• 从数据管理的角度看，数据库技术到目前共经历了如下三个阶段：

1. 人工管理阶段-数据量小独立,用户直接管理
2. 文件系统阶段-使用文件存取数据,冗余度高,管理维护难
3. 数据库系统阶段-专门的数据库软件系统管理数据,高效方便,易于共享维护

• 按照数据模型发展的主线，数据库技术的形成过程和发展可分为如下三个阶段：

4. 层次和网状数据库管理系统-可以理解为使用指针来表示数据之间的联系
5. 关系数据库管理系统(RDBMS)-可以理解为理解为使用二维表来表示维护数据间的关系
6. 新一代数据库技术的研究和发展-针对关系型数据库存在数据模型，性能，扩展性，伸缩性等方面的缺点，出现了：

ORDBMS:面向对象数据库技术。如：PostGreSQL

NoSQL:非结构化数据库技术。如

1)键值存储数据库：Redis

2)列式储数数据库：HBase、ClickHouse

3)文档型数据库：MongoDB

4)图形数据库：Neo4J

NewSQL:这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。如：TiDB、OceanBase

从MySQL到TiDB

如今的数据库种类繁多，RDBMS（关系型数据库）、NoSQL（Not Only SQL）、NewSQL，在数据库领域均有一席之地，可谓百家争鸣之势。那么我们为什么要学习使用TiDB呢？接下来就从我们最熟悉的MySQL的使用说起！

场景引入

假设现在有一个高速发展的互联网公司，核心业务库MySQL的数据量已经近亿行，且还在不断增长中，公司对于数据资产较为重视，所有数据要求多副本保存至少5年，且除了有对历史数据进行统计分析的离线报表业务外，还有一些针对用户数据实时查询的需求，如用户历史订单实时查询。

问题分析

1.MySQL能否满足上述场景需求?

根据以往的MySQL使用经验，MySQL单表在 5000 万行以内时，性能较好，单表超过5000万行后，数据库性能、可维护性都会极剧下降。当然这时候可以做MySQL分库分表，如使用Mycat或Apache Sharding-Sphere。

2.分库分表的能否解决问题?

分库分表的优点非常明显，如：将大表拆分成小表，单表数据量控制在 5000 万行以内，使 MySQL 性能稳定可控。将单张大表拆分成小表后，能水平扩展，通过部署到多台服务器，提升整个集群的 QPS、TPS、RT等数据库服务指标。

但是，此方案的缺点也非常明显：分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险。分表后，对 SQL 语句有一定限制，对业务方功能需求大打折扣。尤其对于实时报表统计类需求，限制非常之大。事实上，报表大多都是提供给高层领导使用的，其重要性不言而喻。分表后，需要维护的对象呈指数增长（MySQL实例数、需要执行的物理SQL变更数量等）。

问题解决

基于以上核心痛点，我们需要探索新的数据库技术方案来应对业务爆发式增长所带来的挑战，为业务提供更好的数据库服务支撑。调研市场上的各大数据库，我们可以考虑选用NewSQL技术来解决，因为NewSQL技术有如下显著特点:

- 理论上无限水平扩展能力

- 分布式强一致性

- 完整的分布式事务处理能力与 ACID 特性

而TiDB数据库在GitHub的活跃度（截止目前已在GitHub上获得了超32,000颗星星）及社区贡献者方面都可以算得上是国际化的开源项目，是NewSQL技术中的代表性产品，所以我们可以选择使用TiDB数据库!

小结

传统关系型数据库历史比较久，目前RDBMS的代表为Oracle、MySQL、PostgreSQL，在数据库领域也是“辈份”比较高的，其广泛应用在各行各业，RDBMS大多为本地存储或共享存储。

但是此类数据库存在着一些问题，如自身容量的限制。随着业务量不断增加，容量渐渐成为瓶颈，此时DBA会通过多次的库表sharding，以此来缓解容量问题。大量的分库分表，不仅耗费了大量人力，还使得业务访问数据库的路由逻辑变得复杂。除此之外，RDBMS伸缩性比较差，通常集群扩容缩容成本较高，且不满足分布式的事务。

NoSQL类数据库的代表为Hbase、Redis、MongoDB、Cassandra等，这类数据库解决了 RDBMS伸缩性差的问题，集群容量扩容变得方便很多，但是由于存储方式为多个KV存储，所以对SQL的兼容性就大打折扣。对于NoSQL类数据库来说，只能满足部分分布式事务的特点。

NewSQL领域的代表是Google的spanner和F1，其号称可以实现全球数据中心容灾，且完全满足分布式事务的ACID，但是只能在Google云上使用。

TiDB诞生在大背景下，也弥补了国内在NewSQL领域中的空缺。TiDB自2015年5月写下第一行代码以来，至今已发布大小版本几十次，版本迭代十分迅速

TiDB概述

TiDB是什么？

我们先看TiDB官网（https://docs.pingcap.com/zh/tidb/stable/overview）原文定义：TiDB 是 PingCAP （https://cn.pingcap.com/about-us/）公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

TiDB可以简单理解为是MySQL的加强版/分布式MySQL/MySQLPlus。

数据库受欢迎程度权威排行榜DB-Engines Ranking（ https://db-engines.com/en/ranking）最新数据如下：

TiDB数据库具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，是大数据时代理想的数据库集群和云数据库解决方案。现已被3000多家不同行业的领先企业应用在实际生产环境，涉及互联网、游戏、银行、保险、证券、航空、制造业、电信、新零售、政府等多个行业，包括美国、欧洲、日本、东南亚等海外用户。

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。

TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

TiDB怎么诞生的?

著名的开源分布式缓存服务 Codis 的作者，PingCAP联合创始人兼CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，笔者之前看过其直播，开源狂热分子+技术大神级别人物。

2012 年底，他看到了Google在2012-2013年相继发表的Spanner 和 F1 两套系统论文，让业界第一次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。这两篇论文描述了 Google 内部使用的一个海量关系型数据F1/Spanner，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋， PingCAP 的 TiDB 在此基础上诞生了。

TiDB架构特性

TiDB 整体架构

TiDB架构详细参阅TiDB官网：https://docs.pingcap.com/zh/tidb/stable/tidb-architecture

TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有为分析型的场景加速的列式存储TiFlash、用于解决用户复杂 OLAP 需求的 TiSpark 组件、简化云上部署管理的 TiDB Operator 组件。

• 架构图解

TiDB Server

TiDB Server是SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接收客户端的连接和SQL 请求，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，通过负载均衡组件（如 TiProxy、LVS、HAProxy、ProxySQL 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

PD Server

Placement Driver (简称 PD) 是整个 TiDB 集群的元信息管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

此外，PD 本身也是由至少 3 个节点构成，PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用。建议部署奇数个 PD 节点。

TiKV Server

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。

TiFlash

TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiSpark

TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。

TiDB Operator

TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上，极大地降低了用户使用和管理 TiDB 的门槛与成本。

TiDB 核心特性

TiDB 具备如下众多特性,其中两大核心特性为水平扩展与高可用

1. 高度兼容 MySQL

大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。对于用户使用的时候，可以透明地从MySQL切换到TiDB 中，只是“新MySQL”的后端是存储“无限的”，不再受制于Local的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中。

2. 分布式事务

TiDB 100% 支持标准的 ACID 事务。

3. 一站式 HTAP 解决方案

TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。

4. 云原生 SQL 数据库

TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合 TiDB Operator 项目 可实现自动化运维，使部署、配置和维护变得十分简单。

5. 水平弹性扩展

通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

6. 真正金融级高可用

相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

水平扩展

无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力(TiDB)和存储能力(TiKV)。

TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。

TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。

PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。

所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。

高可用

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。

• TiDB

TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。

• PD

PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。

• TiKV

TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。

TiDB 存储和计算能力

存储能力-TiKV-LSM

TiKV Server通常是3+的，TiDB每份数据缺省为3副本，这一点与HDFS有些相似，但是通过Raft协议进行数据复制，TiKV Server上的数据的是以Region为单位进行，由PD Server集群进行统一调度，类似HBASE的Region调度。

TiKV集群存储的数据格式是KV的，在TiDB中，并不是将数据直接存储在 HDD/SSD中，而是通过RocksDB实现了TB级别的本地化存储方案，值得一提的是RocksDB和HBASE一样，都是通过 LSM树作为存储方案，避免了B+树叶子节点膨胀带来的大量随机读写，从而提升了整体的吞吐量。关于RocksDB简介请参阅https://docs.pingcap.com/zh/tidb/stable/rocksdb-overview#rocksdb-简介

计算能力-TiDB Server

TiDB Server本身是无状态的，意味着当计算能力成为瓶颈的时候，可以直接扩容机器，对用户是透明的。理论上TiDB Server的数量并没有上限限制。

部署实践

使用 TiUP 部署 TiDB 集群

https://docs.pingcap.com/zh/tidb/stable/production-deployment-using-tiup

在 Kubernetes 上快速上手TiDB

https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/get-started

基于kubesphere平台部署TiDB：

https://www.kubesphere.io/zh/docs/v3.4/application-store/external-apps/deploy-tidb/

扩展阅读

推荐各位读者朋友另可参阅中国国际金融股份有限公司（简称“中金公司”）的研究报告《数据库系列报告开篇：技术路径复盘及展望》，值得一读。（原文链接：https://research.cicc.com/frontend/recommend/detail?id=2640）

数据管理技术发展阶段

1. 人工管理阶段

20世纪50年代以前，计算机主要用于数值计算.从当时的硬件看，外存只有纸带，卡片，磁带，没有直接存取设备；从软件看（实际上，当时还未形成软件的整体概念），没有操作系统以及管理数据的软件；从数据看，数据量小，数据无结构，由用户直接管理，且数据间缺乏逻辑组织，数据依赖于特定的应用程序，缺乏独立性。

2. 文件系统阶段

50年代后期到60年代中期，出现了磁鼓，磁盘等数据存储设备.新的数据处理系统迅速发展起来.这种数据处理系统是把计算机中的数据组织成相互独立的数据文件，系统可以按照文件的名称对其进行访问，对文件中的记录进行存取，并可以实现对文件的修改，插入和删除，这就是文件系统.文件系统实现了记录内的结构化,即给出了记录内各种数据间的关系.但是，文件从整体来看却是无结构的.其数据面向特定的应用程序，因此数据共享性差，且冗余度大，管理和维护的代价也很大。

3. 数据库系统阶段

60年代后期，出现了数据库这样的数据管理技术.数据库的特点是数据不再只针对某一特定应用，而是面向全组织，具有整体的结构性，共享性高，冗余度小，具有一定的程序与数据间的独立性，并且实现了对数据进行统一的控制。

数据库模型发展阶段

1. 第一代数据库系统  层次和网状数据库管理系统

层次和网状数据库的代表产品是IBM公司在1969年研制出的层次模型数据库管理系统。层次数据库是数据库系统的先驱，而网状数据库则是数据库概念、方法、技术的奠基。

2. 第二代数据库系统  关系数据库管理系统(RDBMS)

1970年，IBM公司的研究员E.F.Codd在题为《大型共享数据库数据的关系模型》的论文中提出了数据库的关系模型，为关系数据库技术奠定了理论基础。到了80年代，几乎所有新开发的数据库系统都是关系型的。真正使得关系数据库技术实用化的关键人物是James Gray。Gray在解决如何保障数据的完整性、安全性、并发性以及数据库的故障恢复能力等重大技术问题方面发挥了关键作用。关系数据库系统的出现，促进了数据库的小型化和普及化，使得在微型机上配置数据库系统成为可能。

3. 新一代数据库技术的研究和发展

   目前已从多方面发展了现行的数据库系统技术。我们可以从数据模型、新技术内容、应用领域三个方面概括新一代数据库系统的发展。

   (1) 面向对象的方法和技术对数据库发展的影响最为深远

80年代，面向对象的方法和技术的出现，对计算机各个领域，包括程序设计语言、软件工程、信息系统设计以及计算机硬件设备等都产生了深远的影响，也给面临新挑战的数据库技术带来了新的机遇和希望。数据库研究人员借鉴和吸收了面向对象的方法和技术，提出了面向对象的数据库模型(简称对象模型)。当前有许多研究是建立在数据库已有的成果和技术上的，针对不同的应用，对传统的DBMS，主要是RDBMS进行不同层次上的扩充，例如建立对象关系(OR)模型和建立对象关系数据库(ORDB)。

   (2) 数据库技术与多学科技术的有机结合

数据库技术与多学科技术的有机结合是当前数据库发展的重要特征。计算机领域中其他新兴技术的发展对数据库技术产生了重大影响。传统的数据库技术和其他计算机技术的结合、互相渗透，使数据库中新的技术内容层出不穷。数据库的许多概念、技术内容、应用领域，甚至某些原理都有了重大的发展和变化。建立和实现了一系列新型的数据库，如分布式数据库、并行数据库、演绎数据库、知识库、多媒体库、移动数据库等，它们共同构成了数据库大家族。

   (3) 面向专门应用领域的数据库技术的研究

为了适应数据库应用多元化的要求，在传统数据库基础上，结合各个专门应用领域的特点，研究适合该应用领域的数据库技术，如工程数据库、统计数据库、科学数据库、空间数据库、地理数据库、Web数据库等，这是当前数据库技术发展的又一重要特征。同时，数据库系统结构也由主机/终端的集中式结构发展到网络环境的分布式结构，随后又发展成两层、三层或多层客户/服务器结构以及Internet环境下的浏览器/服务器和移动环境下的动态结构。多种数据库结构满足了不同应用的需求，适应了不同的应用环境。

SQL，NoSQL，NewSQL

1. 关系型数据库(RDBMS,即SQL数据库)

商业软件： Oracle，DB2

开源软件：MySQL，PostgreSQL

单机版本已经很难满足海量数据的需求

1. NoSQL

NoSQL = Not Only SQL，意即“不仅仅是SQL，提倡运用非关系型的数据存储

普遍选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力

通常不保证强一致性的(支持最终一致)

主要分类

• 键值（Key-Value）数据库：如 MemcacheDB，Redis
• 文档存储：如 MongoDB
• 列存储：方便存储结构化和半结构化数据，并做数据压缩，对某几列的查询有非常大的IO优势： 如 HBase，ClickHouse，Cassandra
• 图数据库：存储图关系(注意：不是图片)。如 Neo4J

2. NewSQL

针对OLTP的读写，提供与NOSQL相同的可扩展性和性能，同时能支持满足ACID特性的事务，即保持NoSQL的高可扩展和高性能，并且保持关系模型

• 为什么需要NewSQL

NoSQL 不能完全取代 RDBMS

单机RDBMS 无法满足性能需求

使用“单机RDBMS + 中间件”方式，在中间件层很难解决分布式事务、高可用问题

• NewSQL设计架构

可以基于全新的数据库平台，也可以基于现有的SQL引擎优化。

无共享存储(MPP架构)是比较常见的架构

基于多副本实现高可用和容灾

分布式查询

数据Sharding机制

通过2PC，Paxos/Raft等协议实现数据一致

• 代表产品

Google Spanner

OceanBase

TiDB

OLTP和OLAP

• OLTP

强调支持短时间内大量并发的事务操作（增删改查）能力，每个操作涉及的数据量都很小（比如几十到几百字节）

强调事务的强一致性（想想银行转账交易，容不得差错）

举例：“双十一”期间，可能有几十万用户在同一秒内下订单。后台数据库要能够并发的、以近乎实时的速度处理这些订单请求。

• OLAP

偏向于复杂的只读查询，读取海量数据进行分析计算，查询时间往往很长

举例：“双十一”结束，淘宝的运营人员对订单进行分析挖掘，找出一些市场规律等等。这种分析可能需要读取所有的历史订单进行计算，耗时几十秒甚至几十分钟都有可能。

OLAP类数据库代表产品：Greenplum、TeraData、阿里AnalyticDB

本期总结

TiDB作为新一代的NewSQL数据库，结合了Etcd/MySQL/HDFS/HBase/Spark等技术的突出特点，随着TiDB这类NewSQL的推广，会逐渐弱化 OLTP/OLAP的界限，并简化目前冗杂的ETL流程，引起新一轮的技术浪潮。

那像TiDB这类NewSQL数据库有没有什么“挑战”呢？有，即便它开源了，也不是一般企业能玩得上，在生产环境中光部署一套具备高可用的TiDB集群本就需要消耗大量的服务器资源，技术支持成本、运维成本等都会叠加。但总体来说在某些行业和业务领域，TiDB，前景可待，未来可期。

另值得一提的是国内另一个NewSQL数据库翘楚——蚂蚁集团的OceanBase，也是对标金融级，也是自研且开源，待笔者再深入研究下，后续文章再来分享下。

最后，感谢您的阅读！系列文章会同步在微信公众号@云上的喵酱、阿里云开发者社区@云上的喵酱、CSDN@笠泱 更新，您的点赞+关注+转发是我后续更新的动力！