对于RocksDB和LSM Tree的一些理解

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对一致性要求相对较低，更注重可用性和性能，可能会出现数据在不同节点间的延迟和冲突。