1 从MySQL到TiDB

1.1 场景引入

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

1.2 问题分析

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

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

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

分库分表的优点非常明显，如：

将大表拆分成小表，单表数据量控制在 5000 万行以内，使 MySQL 性能稳定可控。

将单张大表拆分成小表后，能水平扩展，通过部署到多台服务器，提升整个集群的 QPS、TPS、Latency 等数据库服务指标。

但是，此方案的缺点也非常明显：

分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险。

分表后，对 SQL 语句有一定限制，对业务方功能需求大打折扣。尤其对于实时报表统计类需求，限制非常之大。事实上，报表大多都是提供给高层领导使用的，其重要性不言而喻。

分表后，需要维护的对象呈指数增长（MySQL实例数、需要执行的 SQL 变更数量等）。

1.3 问题解决

基于以上核心痛点，我们需要探索新的数据库技术方案来应对业务爆发式增长所带来的挑战，为业务提供更好的数据库服务支撑。

调研市场上的各大数据库,我们可以考虑选用NewSQL技术来解决,因为NewSQL技术有如下显著特点:

• 无限水平扩展能力
• 分布式强一致性，确保数据 100% 安全
• 完整的分布式事务处理能力与 ACID 特性

而TiDB数据库 GitHub的活跃度及社区贡献者方面都可以算得上是国际化的开源项目,是NewSQL技术中的代表性产品,所以我们可以选择使用TiDB数据库!

2.4 总结

传统关系型数据库历史比较久，目前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月写下第一行代码以来，至今已发布大小版本几十次，版本迭代十分迅速

2 TiDB概述

2.1 官网

https://pingcap.com/index.html

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

2.2 简介

TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

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

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

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

3 扩展阅读

3.1 数据管理技术发展阶段

（1）人工管理阶段

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

（2）文件系统阶段

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

（3）数据库系统阶段

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

3.2 数据库模型发展阶段

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环境下的浏览器/服务器和移动环境下的动态结构。多种数据库结构满足了不同应用的需求，适应了不同的应用环境。

3.3 SQL，NoSQL，NewSQL

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

商业软件： Oracle，DB2

开源软件：MySQL，PostgreSQL

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

（2） NoSQL

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

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

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

主要分类

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

（3） NewSQL

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

• 为什么需要NewSQL

        NoSQL 不能完全取代 RDBMS

        单机RDBMS 无法满足性能需求

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

• NewSQL设计架构

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

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

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

        分布式查询

        数据Sharding机制

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

• 代表产品

        Google Spanner

        OceanBase

        TiDB

3.4 OLTP和OLAP

• OLTP

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

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

举例：“双十一”期间，可能有几十万用户在同一秒内下订单。后台数据库要能够并发的、以近乎实时的速度处理这些订单请求（如果下了订单，十几分钟还没有反应，用户肯定要骂人了）

• OLAP

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

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

代表产品：

Greenplum

TeraData

阿里 AnalyticDB

3.5 TiDB怎么诞生的?

著名的开源分布式缓存服务 Codis 的作者，PingCAP联合创始人& CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。

2012 年底，他看到 Google 发布的两篇论文，如同棱镜般，折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据F1/Spanner，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋， PingCAP 的 TiDB 在此基础上诞生了。