TiDB架构（二）

需要一个什么样的数据库
扩展性：弹性横向扩展（弹性角度看，颗粒度越小越好；写入能力的线性扩展机制）
强一致性高可用性：CAP里的强一致性（副本一致性），RPO（数据系统所能容忍的数据丢失量），RTO（数据系统所能容忍的数据恢复时间）实现RPO=0，RTO足够小（与网络相关）
标准SQL支持ACID事务
云原生：由于计算与存储架构设计高度分离，云原生的弹性设计成为了必须
HTAP：混合数据服务，基于解决数据容量的前提下，海量数据的OLAP和OLTP的融合，行列混合，具备资源隔离，需要兼容数据库与大数据的生态，统一数据查询服务
兼容主流生态与协议：用户角度，降低门槛

数据技术栈领域里常见的基础因素
数据模型 数据存储与检索结构
数据格式 存储引擎
复制协议 分布式事务模型
数据架构 优化器算法
执行引擎 计算引擎

计算与存储分离
弊端：
计算与存储强绑定，意味着两种资源总有一个是浪费的
我们在对服务器进行选型的过程中，开始纠结是计算型、还是存储型，大大增加了复杂度和降低通用性
在云计算的场景下，弹性的颗粒度是机器，不能真正做到资源的弹性

如何构建一个分布式存储系统
了解TiKV如何进行Trade offRock
了解TiKV数据引擎的数据结构、高可用设计与数据分片设计
存储引擎：更细粒度的弹性扩容、高并发读写、数据不丢不错、多副本保障一致性及高可用、支持分布式事务
数据结构：传统OLTP（Btree）TIDB（LSM tree）本质用空间置换写入延迟的思想，用顺序写入替换随机写入

TiKV单节点选择了基于LSM-tree的RockDB引擎
RockDB是一款非常成熟的LSM-tree存储引擎
支持批量写入（Atomic batch write）
无锁快照读（Snapshot）：这个功能在数据副本迁移过程会起到作用
raft算法

如何实现扩展：预先分片（静态）、自动分片（动态）
静态解决了数据容量的问题
优先考虑动态分片
方式（Hash、Range、List）
了解TiKV的扩展、调度方式
掌握TiKV的整体架构



描述TiKV的MVCC与事务支持
多版本控制（MVCC）：TiKV的MVCC实现是通过在Key后面添加版本号来实现，简单来说，有了MVCC之后，TiKV的Key排列是这样的，实现了并发控制，SI的隔离级别，历史数据恢复的功能


协助处理器（Coprocessor）
Coprocessor就是TiKV中读取数据并计算的模块，每个TiKV存储节点，我们都有一个协调计算器 (用于下推)

如何构建一个分布式SQL引擎
如何在KV上实现逻辑表

基于KV的二级索引设置

SQL引擎过程

分布式SQL引擎主要优化策略

关键算子分布式化

如何构建一个Online DDL算法

TiDB Server是一个对等，无状态的，可横向扩展的，支持多点写入的，直接承接用户SQL的入口
从进程角度看TiDB-Server

TiDB-Server 其他功能
前台功能 后台功能
管理连接和账号权限管理 垃圾回收（GC）
MySQL协议编码解码 执行DDL
独立的SQL执行 统计信息管理
库表元信息，已经系统变量 SQL优化器与执行器