TiDB简介

自己的理解

TiDB 是一套基于MySQL的协议实现的从零搭建的分布式数据库
也是国产之光. 

他的底层存储基于键值对的TiKV的简直对存储. 
持久化采用LSM-tree的存储结果
Log-structured merge-tree

据称支持512个TiKV节点进行横向扩容存储.
网易游戏,平安科技都深度使用了TiDB数据库. 

他支持高吞吐量的写入, 之多多副本保证安全性
使用raft保证一致性, 使用列存的TiFlash来保证大数据的查询效率. 
需要说明, 因为LSMtree的特殊结构, 大表的查询其实延迟还是比较高的
建议还是需要使用比较好的符合业务逻辑的分页等处理. 

TiDB的版本

TiDB6.x 兼容 MySQL5.7.25 
TiDB7.x 兼容 MySQL8.0.11 

TiDB8.x 也是兼容的MySQL8.0.11 
需要说明. TiDB跟MySQL的innodb存储引擎没有任何关系

他的存储是自己实现的一套 KV 键值对数据库. 

TiDB的创建公司

平凯星辰:
平凯星辰（PingCAP）是一家专注于分布式数据库技术的公司，
成立于2015年，总部位于中国北京。该公司主要产品是TiDB，
这是一个开源的分布式关系型数据库，
旨在解决传统单机数据库在面对海量数据和高并发访问时的性能瓶颈问题。

TiDB的设计灵感来源于Google的Spanner和F1系统，
它结合了传统关系型数据库和NoSQL数据库的优点，
支持水平扩展、强一致性事务和实时分析等功能。

平凯星辰的团队由一批数据库和分布式系统领域的专家组成，
他们致力于推动数据库技术的创新和发展。
公司的客户遍布全球，涉及金融、电子商务、游戏、物流等多个行业。

2013年平凯星辰的创始人之所 黄东旭创立的codis的开源项目
致力于解决redis单节点性能瓶颈. 
后来作为联合创始人开发了TiDB的数据库.

TiDB的结构

TiDB的组件说明

1. TiDB Server
TiDB Server是TiDB数据库的SQL层，
负责接收SQL请求，处理SQL相关的逻辑，
并实现MySQL协议以兼容MySQL客户端。它的主要功能包括：

SQL解析与优化：
将SQL语句解析为执行计划，并优化执行路径，以提高查询效率。
分布式执行：
将执行计划分发到各个TiKV节点执行，并收集执行结果。
核心SQL功能：
支持大部分MySQL的SQL语法和功能，包括事务、索引、聚合、排序等。

2. TiKV Server
TiKV Server是TiDB的分布式存储层，
负责存储实际的数据。它是一个基于Raft协议的分布式KV
（键值对）存储系统。主要功能包括：

数据存储：
以分布式方式存储数据，支持水平扩展。
强一致性：
通过Raft协议确保数据的一致性和高可用性。
事务支持：
提供分布式事务支持，保证ACID特性。

3. PD Server (Placement Driver)
PD Server是TiDB的元数据管理和调度组件，
负责集群的调度、元数据管理、时间戳分配等。它的主要功能包括：

集群调度：
管理和调度TiKV节点，确保数据分布均衡，处理节点故障和恢复。
元数据管理：
存储和管理集群的元数据，如Region（数据分片）的位置信息。
时间戳分配：
为事务分配全局唯一的时间戳，支持Snapshot Isolation级别的事务隔离。

4. TiFlash
TiFlash是TiDB的列式存储扩展组件，
主要用于实时分析处理（OLAP）。它的主要功能包括：

列式存储：
采用列式存储格式，适合高效的分析查询。
实时同步：
与TiKV同步数据，确保数据的实时一致性。
高性能OLAP：
提供高性能的分析查询能力，支持复杂的OLAP操作。

MySQL兼容性情况

TiDB 高度兼容 MySQL 协议，
以及 MySQL 5.7 和 MySQL 8.0 常用的功能及语法。
MySQL 生态中的系统工具
（PHPMyAdmin、Navicat、MySQL Workbench、DBeaver 和其他工具）、
客户端等均适用于 TiDB。

但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：
有更好的解决方案，例如 JSON 取代 XML 函数。
目前对这些功能的需求度不高，例如存储过程和函数。
一些功能在分布式系统上的实现难度较大。
除此以外，TiDB 不支持 MySQL 复制协议，但提供了专用工具用于与 MySQL 复制数据：

从 MySQL 复制：
TiDB Data Migration (DM) 是将 MySQL/MariaDB 数据迁移到 
TiDB 的工具，可用于增量数据的复制。

向 MySQL 复制：
TiCDC 是一款通过拉取 TiKV 变更日志
实现的 TiDB 增量数据同步工具，可通过 MySQL sink 将 TiDB 增量数据复制到 MySQL。

关于LSM和B+tree的优缺点

LSM-Tree对写入更加友好，而B-Tree通常被认为对读取更加友好。
对于OLTP的效率极高,想提高查询效率,必须使用TiFlash
优势: 
LSM-tree通常能够承受比Btree更高的写入吞吐量，
因为它具有更低的写放大，而且在内存落盘时，
因为写入的是紧凑的SStable文件，不必重写树中的多个页，
这种差异对磁盘写入十分重要，顺序写的速度远大于随机写。
LSM-Tree具有更低的磁盘碎片，它不是面向页的，此外定期合并SStable同样能消除碎片化

缺点:
压缩过程会干扰正在进行的读写操作，
虽然有些压缩是增量的，并且是后台线程进行的，
允许并发访问，但是由于磁盘的并发资源是十分有限的，
所以容易出现读写等待的情况
数据库数据量越大，压缩所需的磁盘带宽就越多
如果是超高并发的场景，压缩跟不上写入速率，
可能会导致磁盘上未合并的段数量不断增加，直到磁盘空间不足，
这会导致数据库读性能进一步降低。
为了避免这种情况出现，往往需要额外的监控程序对数据库进行监控
B+树（例如innodb）在使用中日志记录相同键的多个版本，能够提供更强大的事务语义。

写放大: 
由于一次数据库写入请求导致的多次磁盘写被称为写放大，
例如使用b树或者b+树时导致页分裂会增加写入开销。
对于大量写密集的业务，性能瓶颈很可能在于数据库写入磁盘的速率，
这种情况下，写放大具有直接的性能成本，
此外，由于ssd只能承受有限次的擦出覆盖，也尤其关注写放大指标

查询版本信息

TiDB 6.5.3: 
mysql> select version() ;
+--------------------+
| version()          |
+--------------------+
| 5.7.25-TiDB-v6.5.3 |
+--------------------+
1 row in set (0.00 sec)

TiDB7.5.4 :
mysql> select version() ;
+--------------------+
| version()          |
+--------------------+
| 8.0.11-TiDB-v7.5.4 |
+--------------------+
1 row in set (0.00 sec)

更高版本
TiDB8.1.1
select version() ;
+--------------------+
| version()          |
+--------------------+
| 8.0.11-TiDB-v8.1.1 |
+--------------------+
1 row in set (0.001 sec)