【大数据】TiDB理论

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。
一 TiDb简介
　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点：
1 高度兼容 MySQL
　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
2水平弹性扩展
　通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3分布式事务
　TiDB 100% 支持标准的 ACID 事务。
4 真正金融级高可用
　相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
5 一站式 HTAP 解决方案
　TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程。
6云原生 SQL 数据库
　TiDB 是为云而设计的数据库，同 Kubernetes （十分钟带你理解Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
　TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力.

二 TiDb 整体架构

　TiDB 集群主要分为三个组件：
１TiDB Server
　TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或F5）对外提供统一的接入地址。
２PD Server
　Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader的迁移等）；三是分配全局唯一且递增的事务 ID。 　　
　PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
　TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
三 核心特性
1 水平扩展
　无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。
2 高可用
　高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
　TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
　PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
　TiKV 是一个集群，通过 Raft 协议（raft一致性哈算法以及Raft 为什么是更易理解的分布式一致性算法 ）保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。
四 TiDb技术内幕
　1 保存数据 TiDB 技术内幕 - 说存储
　2 计算（很关键如何做sql运算） TiDB 技术内幕 - 说计算
　3 调度(Tidb集群管理) TiDB 技术内幕 - 谈调度
五 安装部署
　tidb安装部署，可能比较麻烦，一步步照着做，如果公司有专门的运维，这个工作可以由运维来搞，但是大多数的中小公司是没有的，都是开发者兼职运维，所以作为一个开发者，还是了解下比较好。
　部署指导 从零开始搭建tidb集群
声明
　以上只是对tidb资料的简单整理和对tidb的一个基本了解，更详细的资料可以转至tidb的官方文档，注意里面的常见问题和解答，很有用：PingCAP Tidb官方文档
————————————————
版权声明：本文为CSDN博主「D_Guco」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/D_Guco/article/details/80641236

 

TiDB 适用场景 不适用场景 及其被替代的产品

TiDB 适用场景：
1.强一致性分布式事务： 
  可以把 TiDB 想象成一个单机的 RDBMS，ACID 事务可以在多节点间进行，无需担心一致性问题。 TiDB 对业务
没有任何侵入性，是传统的数据库中间件、数据库分库分表等优雅的替换方案。
 重点解决 MySQL 的单机性能和容量无法线性和灵活扩展的问题.
 
2.数据归档库：
  若存储不足的时候可以水平扩展机器，TiDB的存储量大，归档的时候可以无需考虑磁盘空间。
  配合TiDB的工具(syncer\mydumper\loader 和TIDB DM)可实现自动归档，当然也无需要考虑源库的操作。
  顺序写入的场景：日志写入、数据审计、财务流水
 
3.MySQL单库超过亿行级别的表较多，否则量级达不到性能不如MySQL。至少是5000万行级别以上的。
 
4.业务爆发式增长，有高并发，业务量增长较快。
 
5.OLAP：
 TiDB 本身的SQL对OLAP支持有限制，需要结合TiSPark.在TiDB3.0之前不支持view，不支持windows functions，
CTE也不支持，TiDB自身对OLAP查询有限。由于TiDB优先OLTP，借鉴Google的 spanner，
对批量INSERT、UPDATE、DELETE操作单次限制在30万行，需要手动修改参数支持DML大批量操作。
  
6.MySQL+MyCAT 这种分库分表的数据合并：
  MySQL+MyCAT的可支撑单表10亿级别的业务，但是需要配置MyCAT等数据库中间件,比较繁琐。
  由于TiDB自身就支持自动分片的功能，可以替换MySQL+MyCAT这种方案。
7.异地多中心、auto-Failover保证数据库高可用:
  TiDB 使用多副本进行数据存储，并依赖业界最先进的 Raft 多数派选举算法确保数据 100% 强一致性和高可用。 副本
可跨地域部署在的不同的数据中心，主副本故障时自动切换，无需人工介入，自动保障业务的连续性，实现真正意义上
的异地多活。不过在实际部署异地多活的时候还是需要考虑网络传输等因素.
8.数据量大时,水平弹性扩展:
 分布式的 TiDB 可随着你的数据增长而无缝地水平扩展，只需要通过增加更多的机器来满足业务增长需要，应用层可以
不用关心存储的容量和吞吐。 TiDB 根据存储、网络、距离等因素，动态进行负载均衡调整，以保证更优的读写性能。
 
TiDB 不适用场景：
1.MySQL单表存储数据在亿级别以下的时候，MySQL+MyCAT方案性能要比TiDB高。
2.资金预算紧张的情况下，运行一个TiDB集群至少需要6台高配SSD硬盘的主机(建议支持NVME协议)
 随着时间的推移和硬件的发展，硬件成本会降低。
3.TiDB on cloud
  虽然有TiDB operator 项目，但是截至2019年3月还不稳定和性能不足，不推荐运行在生产的kubernetes集群。
 尚在PoC阶段。但是Cloud DB 是大势所趋。
4.要求100%不修改源代码迁移应用从MySQL迁移到TiDB。
这个主要是TiDB目前对MySQL的函数和功能的兼容性不足导致的。预期TiDB 3.0会兼容MySQL8.0版本大部分功能。
 
TiDB 不足的地方：
1.宣称HTAP，对于OLAP支持还需要大力发展 ,一般OLAP是列存计算上有比较大的优势,如何在一个数据库里做到行存和列存共存是需要解决的。
2.采用RocksDB 作为存储引擎，其自身存在写放大缺陷(Write Amplification )
3.由于是兼容MySQL的语法，而不是标准SQL，对一些高频SQL语句(merge、full join等)支持不足
4.TiDB作为OLAP应用的时候，若OLTP和OLAP放置到一起对业务影响还是会较大的，需要做资源限制。尚需TiDB的
开发人员努力优化的，作为宣称的HTAP性能有待商榷和验证。
 
 
 
业界采用的方案：
BAT三家有自己开发的对应的云数据库，国内的TMD(toutiao、meituan\xiaomi、didi)等互联网企业均有使用.
 
https://pingcap.com/cases-cn/
 
 
被替换的产品：
1.TiDB替换掉MySQL+MyCAT
2.TiDB替换掉Hbase
3.TiDB替换掉 
4.替换掉OLTP和OLAP是两套存储和计算的方案
 
TiDB 畅想：
1.如何提升OLAP的性能？支持列存数据库
2.对于新兴的硬件的支持如GPU加速、FPGA.
3.生产级的TiDB on kubernetes
4.SQL标准的支持而非MySQL的SQL 方言

什么是ACID

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。

ACID是Atomic（原子性）
Consistency（一致性）
Isolation（隔离性）
Durability（持久性）

Atomic（原子性）：指整个数据库事务是不可分割的工作单位。只有使据库中所有的操作执行成功，才算整个事务成功；事务中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。

Consistency（一致性）：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。

Isolation（隔离性）：指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。

Durability（持久性）：指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

OLTP和OLAP有何区别?

OLTP即联机事务处理，就是我们经常说的关系数据库，意即记录即时的增、删、改、查，就是我们经常应用的东西，这是数据库的基础；
OLAP即联机分析处理，是数据仓库的核心部心，所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析；是处理两种不同用途的工具而已。