55 lines
3.8 KiB
Markdown
55 lines
3.8 KiB
Markdown
## 树
|
||
|
||
### 三种基本的存储引擎
|
||
|
||
- 哈希存储引擎
|
||
是哈希表的持久化实现，支持增、删、改以及随机读取操作，**但不支持顺序扫描**，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,如果不需要有序的遍历数据，哈希表就是your Mr.Right
|
||
- B树存储引擎
|
||
是B树的持久化实现，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。
|
||
- LSM树（Log-Structured Merge Tree）存储引擎
|
||
和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。**当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。**
|
||
|
||
### BTree和B+Tree
|
||
|
||
[详解](https://www.cnblogs.com/vianzhang/p/7922426.html)
|
||
|
||
B树是为磁盘存储而专门设计的一类平衡搜索树
|
||
|
||
B+树中的B代表平衡（balance）
|
||
B+树最大的性能问题是为了读取有序性,插入会产生大量的随机IO,因为磁盘寻道速度慢
|
||
|
||
- 典型应用
|
||
|
||
|
||
|
||
### 平衡二叉树（AVL Tree）
|
||
|
||
### LSM树 与 B+ Tree
|
||
|
||
产品:HBase, Cassandra, LevelDB, SQLite,甚至在mangodb3.0中也带了一个可选的LSM引擎
|
||
|
||
[LSM树由来、设计思想以及应用到HBase的索引](https://www.cnblogs.com/yanghuahui/p/3483754.html)
|
||
[概念](https://www.cnblogs.com/bonelee/p/6244810.html)
|
||
|
||
设计背景:顺序读写磁盘（不管是SATA还是SSD）快于随机读写主存，而且快至少三个数量级。这说明我们要避免随机读写，最好设计成顺序读写
|
||
|
||
LSM树的设计思想非常朴素：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘,，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。极端的说，基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级
|
||
|
||
它的原理是把一颗大树拆分成N棵小树， 它首先写入到内存中（内存没有寻道速度的问题，随机写的性能得到大幅提升），在内存中构建一颗有序小树，随着小树越来越大，内存的小树会flush到磁盘上。当读时，由于不知道数据在哪棵小树上，因此必须遍历所有的小树，但在每颗小树内部数据是有序的
|
||
|
||
以上就是LSM树最本质的原理，有了原理，再看具体的技术就很简单了。
|
||
|
||
1. 首先说说为什么要有WAL（Write Ahead Log），很简单，因为数据是先写到内存中，如果断电，内存中的数据会丢失，因此为了保护内存中的数据，需要在磁盘上先记录logfile，当内存中的数据flush到磁盘上时，就可以抛弃相应的Logfile。
|
||
|
||
2. 什么是memstore, storefile？很简单，上面说过，LSM树就是一堆小树，在内存中的小树即memstore，每次flush，内存中的memstore变成磁盘上一个新的storefile。
|
||
|
||
3. 为什么会有compact？很简单，随着小树越来越多，读的性能会越来越差，数据也有冗余,因此需要在适当的时候，对磁盘中的小树进行merge，多棵小树变成一颗大树。
|
||
|
||
#### LSM tree 操作流程如下：
|
||
|
||
1. 数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到 WAL 文件中。
|
||
2. 内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
|
||
3. 随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。
|
||
|
||
|