数据结构-各类树的简单理解

数据结构-各类树的简单理解

 

理解：二叉树的查找的优化，也是利用了相似二分查找的思想，让查找的时间复杂度变成O(log2 n)

1. 树

　　N叉树浪费连接的存储空间，N越大浪费越严重

　　解决：N等于2时连接空间浪费率最低，因而有了二叉树

2. 二叉树

　　优势：连接空间浪费率达到最低。

　　缺点：无约束的二叉树是无序的，查找的时间复杂度为O(N)，

       解决：有了二叉搜索树BST（Binary Search Tree）（又称排序二叉树、有序二叉树、二叉查找树）

3. 二叉搜索树BST

　　优势：排序二叉树查询、删除和插入的平均时间复杂度都是O(log2 n)

　　缺点：可是随着节点的添加和删除，查询的时间复杂度在O(log2 n) 到O(n)之间，

　　          也就是说极端状况可能成为链表结构，查询时间复杂度变成O(n)

　　解决：在添加和删除节点时要维持二叉树的平衡 -> 平衡二叉树（AVL树）、红黑树等

　　场景：实际使用很少

4. 平衡二叉树（AVL树）

　　优势：AVL树是高度平衡的二叉树，查找效率很是高，接近二分查找。

　　缺点：每次插入和删除都须要维护平衡，代价高，耗时大。

　　解决：不维持严格平衡，只保证近似平衡 -> 红黑树

　　场景：实际使用很少

5. 近似平衡的二叉树-红黑树

　　优势：性能稳定，插入、删除、查找的复杂度在最好、最坏的状况都是O(log2 n) ，性能略微逊色AVL树。

　　实际中使用的比较多的。

　　缺点：比较适合数据所有加载到内存中。可是数据量大到大量数据在磁盘，须要屡次加载到磁盘中，每一个节点的访问都要通过一次磁盘I/O，  效率是很是低下的。

　　解决：为了减小减小磁盘IO，减小树的高度，使树变得“矮胖”（多叉树）-> B树和B+树

                 数据库索引多使用 B树和B+树

　　应用场景：使用比较多

                    JAVA8 HashMap的底层实现，数组+ 链表/红黑树

                   其中元素个数小于8时是链表，元素个数大于8时是红黑树;若是已是红黑树，元素个数减为6（不是8的缘由：避免频繁转换）时退化为链表。

6. B树（又称B-tree树或B-树）

　　优势：减小I/O次数，多路查找树，B树在提升了磁盘IO性能

　　          B-树查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1)

　　缺点：没有解决元素遍历的效率低下的问题，不利于遍历和范围查找。

　　解决：全部数据放在叶子节点节点上，组成一个双向链表，非叶子节点存储主键索引 -> B+树

　　场景：MongoDB默认存储引擎使用了B树。

　　说明：读多写少且对遍历数据的需求不强，B 树与 LSM 树在该场景下相比B+树有更大的优点

7. B+树：B树的改进版

　　优势：只有叶节点会存储数据

　　场景：MySQL的InnoDB存储引擎使用了B+树

　　注意：B树和B+树的查询效率确定不如红黑树，可是红黑树内存中才有优点。

 

8. B*树：B+树的改进版

 

9. 跳表：

         链表加多级索引的结构

　　能够当作是链表实现二分查找，基于范围查询比红黑树效率高。

　　理论上通过改造后能够代替B+树成为数据库存储索引设计。

 

10. LSM树

　　不管是 B 树仍是 B+ 树，向这些数据结构组成的索引文件中写入记录都须要执行的磁盘随机写。

　　LSM 树的优化逻辑就是牺牲部分的读性能，将随机写转换成顺序写以优化数据的写入。
　　a.在不限制写入的状况下；
　　　　LSM 树的写入性能是 B 树的 1.5 ~ 2 倍；
　　　　LSM 树的读取性能是 B 树的 1/6 ~ 1/3；
　　b.在限制写入的状况下；
　　　　LSM 树的写入性能与 B 树的性能基本持平；
　　　　LSM 树的读取性能是 B 树的 1/4 ~ 1/2；

　　场景：MongoDB默认存储引擎使用了B树，备用引擎是LSM树。
　　　　   Hbase中存储设计使用了LSM树。

问题1：Redis为何采用跳表而不是红黑树？

　　（1）插入、删除、查找以及迭代输出有序序列这几个操做，红黑树也能够完成，时间复杂度跟跳表是同样的。可是，按照区间来查找数据这个操做，红黑树的效率没有跳表高。

　　（2）跳表插入和删除更快、操做更简单。平衡树的插入和删除操做可能引起子树的旋转调转，逻辑复杂。

　　（3）算法实现简单

　　（4）跳表更加灵活，他能够经过改变索引构建策略，有效平衡执行效率和内存消耗。

 

问题2：为何MongoDB使用B树，而mysql使用B+树？

　　（1）B+树内节点不存储数据，全部 data 存储在叶节点致使查询时间复杂度固定为 log n。

      　　  B-树查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1)

     　　   MongoDB追求单条记录的效率发挥到极致，而不重视范围查找（虽然也支持，可是性能不如B+树）。

　　（2）B+树擅长范围查找，而B树不擅长。（最重要的缘由）

　　　　 B+树查询时间复杂度固定为logn，性能稳定。

　　 　　MySQL追求稳定和范围查询。

（3）B+树中非叶子节点不存储关键字，利于加载到内存。

 

问题3：B+树、B树对比？

　　（1）B+树的全部数据都在叶子节点中，非叶子节点不存储数据，只是索引。

　　　　  B树中的节点存储数据；

　　（2）B+树叶子节点之间是双向链表。

               B 树中的叶子节点并不须要链表来串联。

　　（3）B+树更加适合范围查询、且查询性能更稳定