TIDB

公司数据量激发到数十亿条，且每日增量在两千万左右，mysql的分库分表已经没办法承受日益增大的数据量，因为涉及到交易，需要事务支持，所以综合考虑改换用TIDB作为数据存储，mysql作为配置表存放位置。

一、数据库发展史

SQL关系型数据库–>NoSQL非关系型数据库–>newSQL

二、为什么要使用newSQL型数据库(TIDB)?

1. 非关系型数据库基于KV存储，没办法提供事务，不支持sql，不保证强一致性。
2. 关系型数据库分库分表分片键少查询麻烦，单机数据库已经无法满足海量数据。
3. NewSQL支持OLAP和OLTP

三、TIDB的进化路程？

sharding nothing

例如：TiDB 3.0版本

1. 优点
   无限水平扩展，没有容量上限，对海量数据友好
   对金融级别的一致性ACID事务支持，业务改动小
   故障自恢复的高可用
   sql和单机数据库基本一致
2. 缺点
   没有全部兼容传统数据库语法
   对于一些场景。秒杀延迟不如单机数据库

sharding everything

例如：AWS Aurora,阿里云PolarDB
基于共有云，存储量基于云盘磁盘大小，主从复制

1. 优点
   易用，100%兼容Mysql，业务兼容性好
   对一致性要求不高的场景，读可以水平扩展
2. 缺点
   本质还是单机数据库，如果支持大数据量，仍然需要分库分表
   内存和容量不匹配，单表量大会导致抖动
   跨机的事物一致性问题（存在同步延迟）
   分析能力限于单点

HTAP

1. 定义
   HyBrid Transactional/Analytical processing 混合事物分析处理
2. 标准
   业务透明的水平扩展能力
   分布式事务的支持
   多数据中心故障自恢复

四、OLTP和OLAP分别是什么？

1. OLTP是支持短时间内大量并发的数据操作，且保证强一致性
2. OLAP是支持复杂的只读操作，读取海量数据进行分析计算

五、TIDB总体架构？

PD：整个集群的管理者，主要储存元数据(哪些表存在哪个DB上)，负责负载均衡，分配全局唯一的数据ID
TIDB：负责接收和解析SQL请求的，通过PD中存储的元数据找到数据存在哪个TIKV上，并和TIKV进行交互，将结果返回给用户
TIKV:负责真正存储数据的存储引擎
TI Spark: 解决用户复杂的OLAP查询需求的组件

六、TIDB的核心特性

1. 高度兼容MySql,支持实时迁移MySql分库分表
2. 100%支持事务
3. 支持水平扩展，分为计算能力(加TIDB)和存储能力(加TIKV)
4. 高可用

七、TIDB基本操作

1. 可以支持绝大多数的MySql操作
2. 可以读取历史数据，通过设置类似于Hbase中版本号，关键语句Set @@tidb_snapshot=”时间”，以用Set @@tidb_snapshot=””结束

八、数据迁移（TIDB Lighting）

Lighting是一个将全量数据高速导入TIDB集群的工具，组成成分：

1. Tidb-lighting(“前端”) 主要完成适配工作，通过读取数据源，在下游TIDB集群中创建表，将数据转换成KV形式发送到TIKV-Import，检查数据完整性等
2. TIKV-Import(“后端”)完成将数据导入TIKV集群的工作

九、TIDB的技术内幕-内存存储

1. TIKV:可以看做一个巨大的Map缓存,按照key的二进制存储有序

2. RocksDB:负责将数据落库在磁盘上,底层是LSM树,到达指定大小flush到磁盘上，磁盘的树定期做merge操作合并成大树

3. Raft:一致性协议,提供leader选举，成员变更，日志复制。Tikv利用Raft做数据复制。每个数据变更都会落地为一条Raft日志，安全的同步到Group多节点中
   存储数据流程：
   Data–>Raft–>Raft同步多节点–>RocksDb–>flush–>Disk
   

4. Region:将TIKV中kv分成多段，每一段都是一系列连续的key，称之为region,每个region都有startKey和endKey(左闭右开)

5. Replica:数据副本，一个region可能有多个Replica保存在不同节点，通过Raft保证数据一致性，多个Replica组成group，其中一个作为Leader，其他都是Follower,读写都是Leader进行，然后在复制给Follower
   

6. MVCC：多版本控制，避免性能损失和死锁发生
   原：key1–>value1
   Key2–>value2
   Key3–>value3
   MVCC后：
   key1-version3–>value1
   key1-version2–>value1

7. 事务：Percolator模型,不检测写写冲突，只在提交的时候会冲突检测

十、TIDB的技术内幕-计算

1. TiDB主要面对的是OLTP业务，需要快速的读取，修改数据，所以选择行存是比较合适的
   Index(索引)支持主键索引和Secondary Index,支持唯一索引和非唯一索引

2. TIDB是一个全局有序的KV型Map，所以会给每个表分配TableID(集群唯一)，每一个索引会分配IndexId(表内唯一),每一行都分配一个RowId(表内唯一)

3. 数据格式:
   唯一索引Key:tablePrefix{tableId}_tablePrefix{RowId}_indexedColumnsValue
   非唯一索引：Key:tablePrefix{tableId}_tablePrefix{RowId}_indexedColumnsValue_rowId
   Value:[col1.col2]

4. 元数据：每个DataBase和Table都分配一个唯一的Id，在编码成Key-value形式是，这个id会编码到key中用m_作为前缀存储在TIKV中

5. 分布式计算：在每个节点都进行处理，然后进行预集合
   

十一、TIDB的技术内幕-调度

调度的基本操作：增加/删除Replica以及在raft的Replica group之间的转移
信息收集：tikv会定期像pd汇报信息。以及每个raft group的leader与pd之间的心跳包