数据结构-数

遍历

四种主要的遍历思想为:前中后指的是根节点遍历位置

前序遍历:根结点 ---> 左子树 ---> 右子树

中序遍历:左子树---> 根结点 ---> 右子树

后序遍历:左子树 ---> 右子树 ---> 根结点

层次遍历:只需按层次遍历即可

前序遍历:1  2  4  5  7  8  3  6 

中序遍历:4  2  7  5  8  1  3  6

后序遍历:4  7  8  5  2  6  3  1

层次遍历:1  2  3  4  5  6  7  8

平衡二叉树

它是一棵空树或它的左右两个子树的高度差的绝对值不超过1,并且左右两个子树都是一棵平衡二叉树,同时,平衡二叉树必定是二叉搜索树。

AVL 树

对平衡要求严格,插入和删除操作后可能需要频繁进行旋转操作来恢复平衡,这在一定程度上增加了操作的时间开销。因此,对于插入和删除操作频繁的场景,AVL 树可能不是最优选择。

红黑树

红黑树是一种自平衡二叉查找树,典型的用途是实现关联数组。可以在O(logn)时间内做查找,插入和删除,这里的n是树中元素的数目。

红黑树是每个节点都带有颜色属性的二叉查找树,颜色为红色或黑色。在二叉查找树强制的一般要求以外,对于任何有效的红黑树我们增加了如下的额外要求:

  性质1. 节点是红色或黑色。

  性质2. 根是黑色。

  性质3. 所有叶子都是黑色(叶子是NIL节点)。

  性质4. 每个红色节点必须有两个黑色的子节点。(从每个叶子到根的所有路径上不能有两个连续的红色节点。)

  性质5. 从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点。

  下面是一个具体的红黑树的图例:

特性

红黑树并不像 AVL 树那样严格平衡,从根节点到叶子节点的最长路径不会超过最短路径的两倍。这种近似平衡使得红黑树在插入和删除操作后的调整相对简单,不需要像 AVL 树那样频繁地进行旋转操作。

B树

B树(B-tree)是一种树状数据结构,能够用来存储排序后的数据。这种数据结构能够让查找数据、循序存取、插入数据及删除的动作,都在对数时间内完成。B树,概括来说是一个一般化的二叉查找树,可以拥有多于2个子节点。与自平衡二叉查找树不同,B-树为系统最优化大块数据的读和写操作。B-tree算法减少定位记录时所经历的中间过程,从而加快存取速度。这种数据结构常被应用在数据库和文件系统的实作上。

B树作为一种多路搜索树(并不是二叉的):

  1) 定义任意非叶子结点最多只有M个儿子;且M>2;

  2) 根结点的儿子数为[2, M];

  3) 除根结点以外的非叶子结点的儿子数为[M/2, M];

  4) 每个结点存放至少M/2-1(取上整)和至多M-1个关键字;(至少2个关键字)

  5) 非叶子结点的关键字个数=指向儿子的指针个数-1;

  6) 非叶子结点的关键字:K[1], K[2], …, K[M-1];且K[i] < K[i+1];

  7) 非叶子结点的指针:P[1], P[2], …, P[M];其中P[1]指向关键字小于K[1]的子树,P[M]指向关键字大于K[M-1]的子树,其它P[i]指向关键字属于(K[i-1], K[i])的子树;

  8) 所有叶子结点位于同一层;

B+数

B+树是B树的变体,也是一种多路搜索树:

  1) 其定义基本与B-树相同,除了:

  2) 非叶子结点的子树指针与关键字个数相同;

  3) 非叶子结点的子树指针P[i],指向关键字值属于[K[i], K[i+1])的子树(B-树是开区间);

  4) 为所有叶子结点增加一个链指针;

  5) 所有关键字都在叶子结点出现;

全部评论

相关推荐

08-21 09:59
已编辑
门头沟学院 golang
事故起因:&nbsp;需求需要聚合库中所有组件,编码完成后发现es索引中未添加规范器,导致Nginx、NGINX和nginx等被多次统计,但是右边列表查询是不区分大小写的,此时楼主想着直接给索引加上规范器即可(产品需求忽略大小写),便参照其他同事的迁移索引脚本完成了编写并在本地环境完成测试事故产生编写的迁移脚本完全是参考同事编写的,相关的字段直接使用索引的json文件编写,没有考虑此索引存着特殊性,含有很多_source字段,导致不在json文件中的所有字段丢失,导致客户部分用到_source的数据丢失,但是本地测试时没有用到相关内容,也忘记告知测试导致本次事故产生解决方案其实很简单,因为只是加个规范器并不涉及数据修改什么的,直接把原值复制就行,循环赋值指定字段导致数据丢失事故总结第一时间知道是由于自己的迁移脚本造成的,人真的一下子懵了,可能这就是职场新人吧,那一下午需求基本没写出来,脑子里全是寄了,可以提前毕业了啥的,整个人陷入了一种死锁状态。晚上邮件通知后,导师完成版本修复开始着手给客户补数据,两个后端+一个架构师+产品经理&nbsp;从18.30开始补救&nbsp;到至少凌晨1点吧(导师让我先走&nbsp;不然第二天没人处理问题)&nbsp;,我最后一次询问是1:26分&nbsp;让我先睡,还在修复中,晚上梦里全是他们在补救什么的,基本没睡着,一会儿拿手机看有没有说修复完成事故感想这次事故真的给了很大一个教训,犯得第一个重大错误是没有理清楚迁移方案,直接参照别人的完成编写,没有自己的思考第二&nbsp;第一次感觉到自己技术不足的严重性,这次事故最无力的是我的错误导致他们来帮我善后,我帮不上任何忙,真的很无力希望大家以我为戒吧,千万要先自己考虑好方案,涉及数据的工作一定要在cr时让别人好好审审,一定要和测试沟通
职场捅娄子大赛
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务