1.TiDB引入
1.1.数据库技术发展简史
数据库技术产生于20世纪60年代末70年代初，其主要主要研究如何存储，使用和管理数据。随着计算机硬件和软件的发展，数据库技术也不断地发展。数据库技术在理论研究和系统开发上都取得了辉煌的成就。
从数据管理的角度看，数据库技术到目前共经历了如下三个阶段：
- 人工管理阶段-数据量小独立,用户直接管理
- 文件系统阶段-使用文件存取数据,冗余度高,管理维护难
- 数据库系统阶段-专门的数据库软件系统管理数据,高效方便,易于共享维护
- 按照数据模型发展的主线，数据库技术的形成过程和发展可分为如下三个阶段：
- 层次和网状数据库管理系统-可以理解为使用指针来表示数据之间的联系
- 关系数据库管理系统(RDBMS)-可以理解为理解为使用二维表来表示维护数据间的关系
- 新一代数据库技术的研究和发展-针对关系型数据库存在数据模型，性能，扩展性，伸缩性等方面的缺点，出现了：
- ORDBMS:面向对象数据库技术。如：PostGreSQL
- NoSQL:非结构化数据库技术。如：
- 键值存储数据库：Redis
- 列式储数数据库：HBase
- 文档型数据库：MongoDB
- 图形数据库：Neo4J
- NewSQL:这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。如：TiDB
1.2.从MySQL到TiDB
（1）场景引入
假设现在有一个高速发展的互联网公司,核心业务库MySQL的数据量已经近亿行,且还在不断增长中,公司对于数据资产较为重视,所有数据要求多副本保存至少5年,且除了有对历史数据进行统计分析的离线报表业务外,还有一些针对用户数据实时查询的需求,如用户历史订单实时查询。
- MySQL能否满足上述场景需求？
根据以往的MySQL使用经验，MySQL单表在 5000 万行以内时，性能较好，单表超过5000万行后，数据库性能、可维护性都会极剧下降。当然这时候可以做MySQL分库分表,如使用Mycat或Sharding-jdbc。
- 分库分表的能否解决问题?
将大表拆分成小表，单表数据量控制在 5000 万行以内，使 MySQL 性能稳定可控。将单张大表拆分成小表后，能水平扩展，通过部署到多台服务器，提升整个集群的 QPS、TPS、Latency 等数据库服务指标。
但是，此方案的缺点也非常明显：分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险。分表后，对 SQL 语句有一定限制，对业务方功能需求大打折扣。尤其对于实时报表统计类需求，限制非常之大。事实上，报表大多都是提供给高层领导使用的，其重要性不言而喻。分表后，需要维护的对象呈指数增长（MySQL实例数、需要执行的 SQL 变更数量等）。
（3）解决问题
基于以上核心痛点，我们需要探索新的数据库技术方案来应对业务爆发式增长所带来的挑战，为业务提供更好的数据库服务支撑。
调研市场上的各大数据库,我们可以考虑选用NewSQL技术来解决,因为NewSQL技术有如下显著特点:
- 无限水平扩展能力
- 分布式强一致性，确保数据 100% 安全
- 完整的分布式事务处理能力与 ACID 特性
- 而TiDB数据库 GitHub的活跃度及社区贡献者方面都可以算得上是国际化的开源项目,是NewSQL技术中的代表性产品,所以我们可以选择使用TiDB数据库!
1.3.TiDB概述
（1）TiDB简介
TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。
TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。
（2）OLAP与OLTP的区别
OLTP：强调支持短时间内大量并发的事务操作（增删改查）能力，每个操作涉及的数据量都很小（比如几十到几百字节）
OLAP：偏向于复杂的只读查询，读取海量数据进行分析计算，查询时间往往很长。
1.4.数据库种类简介
（1）关系型数据库(RDBMS,即SQL数据库)
- 商业软件： Oracle，DB2
- 开源软件：MySQL，PostgreSQL
- 单机版本已经很难满足海量数据的需求
（2）NoSQL非关系型的数据存储
键值（Key-Value）数据库：如 MemcacheDB，Redis
文档存储：如 MongoDB
列存储：方便存储结构化和半结构化数据，并做数据压缩，对某几列的查询有非常大的IO优势： 如 HBase，Cassandra
图数据库：存储图关系(注意：不是图片)。如 Neo4J
（3）NewSQL既保持NoSQL的高可扩展和高性能，并且保持关系模型
- Google Spanner：Google最近公开的新一代分布式数据库。
- OceanBase：蚂蚁集团完全自主研发的国产原生分布式数据库。
- TiDB：PingCAP公司自主设计、研发的开源分布式关系型数据库。
2.TiDB架构特性
2.1.TiDB整体架构
TiDB集群主要包括三个核心组件：TiDB Server，PD Server和TiKV Server。此外，还有用于解决用户复杂OLAP需求的TiSpark组件和简化云上部署管理的TiDB Operator组件。
PD Server
Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。
TiDB Server
TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。
TiKV
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，
每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。
TiDB Operator
TiDB Operator 提供在主流云基础设施（Kubernetes）上部署管理 TiDB 集群的能力。它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识，集成一键部署、多集群混部、自动运维、故障自愈等能力，极大地降低了用户使用和管理 TiDB 的门槛与成本。
2.2.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 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 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 节点上。
2.3.存储和计算能力
（1）存储能力-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+树叶子节点膨胀带来的大量随机读写。从何提升了整体的吞吐量。
（2）计算能力-TiDB Server
TiDB Server本身是无状态的，意味着当计算能力成为瓶颈的时候，可以直接扩容机器，对用户是透明的。理论上TiDB Server的数量并没有上限限制。
TiDB作为新一代的NewSQL数据库，在数据库领域已经逐渐站稳脚跟，结合了Etcd/MySQL/HDFS/HBase/Spark等技术的突出特点，随着TiDB的大面积推广，会逐渐弱化 OLTP/OLAP的界限，并简化目前冗杂的ETL流程，引起新一轮的技术浪潮。
3.TiDB安装部署
3.1.TiDB-Local单机版
在Centos 6的版本中如果要部署，这个难度还是比较大的，而且会有很多未知的坑，根据官方的建议，是需要在Centos 7以上的版本中，否则glibc的版本问题会很快碰到。我们安装一套Centos7，采用快速的单机部署的方式来尝鲜。
（1）下载安装包
wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz
（2）解压文件
tar -zxvf tidb-latest-linux-amd64.tar.gz
cd tidb-latest-linux-amd64
（3）启动
启动PD：./bin/pd-server --data-dir=pd --log-file=pd.log &
启动tikv：./bin/tikv-server --pd=“127.0.0.1:2379” --data-dir=tikv --log-file=tikv.log &
启动tidb-server：./bin/tidb-server --store=tikv --path=“127.0.0.1:2379” --log-file=tidb.log &
（4）登入：mysql -h ip -P 4000 -u root
3.2.TiDB-Docker集群版
（1）准备环境
确保你的机器上已安装：
Docker（17.06.0 及以上版本）
Docker Compose
Git
（2）快速部署
下载 tidb-docker-compose
git clone https://github.com/pingcap/tidb-docker-compose.git
（3）创建并启动集群
获取最新 Docker 镜像：cd tidb-docker-compose && docker-compose pull && docker-compose up -d
注意:
得先启动Docker
sudo systemctl start docker
再执行上面的docker-compose命令
（4）查看集群启动状态
docker-compose ps
（5）Navicat测试链接
（6）访问集群监控页面
