对于RocksDB和LSM Tree的一些理解，以及TiDB架构初识

LSM Tree的读写过程

HBase、LevelDB，rocksDB（是一个引擎）底层的数据结构是LSM Tree
适合写多读少的场景，都是追加写入内存中的MemTable，写入一条删除（或修改）标记，而不用去访问实际的数据，从而大大提高写的速度
追加顺序写（innodb的页是随机的）
sst和memTable有序是为了compact，范围查询，key 的有序性可以让我们对sst其进行增量编码、indexblock的页目录

写操作

MemTable：是一个内存缓冲区，跳表实现，数据有序，append操作到这个内存，默认大小64M，期间有预写操作，每次刷盘都会在 L0 层上产生一个新的 SST 文件（rocksDB中默认L0上有四个SST，超过就compact）
![[Pasted image 20250125221824.png]]

SST： 默认 SST 文件大小：64MB，其中有多个block（4k）存数据，有布隆过滤器和indexBlock，类比innodb中的页目录
![[Pasted image 20250125223209.png]]

因为sst中会有许多操作不同，但是key相同的数据，为了避免空间放大和读放大（读多个sst），有compact操作，就是某一层的sst数量超过阈值，和下一层有相同key范围的sst进行归并排序，通过 K 路归并算法逐步合并多个 SST 文件

读操作

以下是查找步骤：

检索 MemTable。
检索不可变 MemTables。
搜索最近 flush 过的 L0 层中的所有 SST 文件。
对于 L1 层及以下层级，首先找到可能包含该 key 的单个 SST 文件，然后在文件内进行搜索。

块索引在 SSTable 文件被打开时加载到内存。在查找时首先从内存中的索引二分查找找到块，然后一次磁盘寻道即可读取到相应的块。只加载索引，再找block

搜索 SST 文件涉及：
（可选）探测布隆过滤器。
查找 index 来找到可能包含这个 key 的 block 所在位置。
读取 block 文件并尝试在其中找到 key。

目前的实现

newSQL和NoSQL和传统sql

1. 前两个的出现
1. 都是为了解决传统sql的单机限制，如容量和自动恢复和分布式事务，如mycat中间件只能解决分片和容量，解决不了自动恢复，分布式事务还要引入seata
2. mysql支持的是异步和半同步复制，宕机的时候部分数据不一致
3. 刷盘上面，分为，mysql（传统）用的是B+树结构，即刷的是对应的页（磁盘的页和内存的页的格式相同），还有就是tidb是kv的追加------其实这么总结实际上是因为只了解innodb和rocksDB（这个只是区别，不是解决的问题）

2. new和no的区别：
nosql如mongoDB
NewSQL仍然采用关系型数据模型，如TiDB完全适配Mysql，在下层会把表结构转化为kv结构，即表格和数据行的模型。这意味着数据结构必须遵循预定义的表格模式和关系。而NoSQL则采用了不同的数据模型，如键值对、文档、列族和图形等。NoSQL的数据模型更加灵活，适应了不同类型和结构的数据存储需求。

NewSQL对数据一致性要求更高（但是实际上MongoDB后续也支持分布式事务），追求强一致性（ACID特性）。这意味着在数据写入与读取过程中，数据一定会达到一致的状态。然而，NoSQL对一致性要求相对较低，更注重可用性和性能，可能会出现数据在不同节点间的延迟和冲突。

TiDB架构（newSQL）

![[Pasted image 20250125113215.png]]

组件	作用
TiDB	Server 无状态 SQL 层，接收 SQL 请求并转发给 TiKV
TiKV	Server 存储引擎，提供事务、行存数据（类似 MySQL），引擎是RocksDB
PD Server	元数据管理，调度 TiKV 集群，保存Region的位置，生成事务时间戳

执行流程

TiDB Server 解析 SQL、进行语法和语义检查。
通过优化器生成执行计划（选择索引、确定 join 顺序等）。
查询 Region 元数据：
1. TiDB Server 向 PD Server 查询目标数据对应的 Region 位置。
2. PD 返回对应的 TiKV 节点地址。（PD可以类比MongoDB的Config Server）
TiDB发起查询