RDBMS索引日志

一、数据结构

B-tree:

1) 平衡树,子树高度一致,M阶即M叉树

2) 叶节点间相互独立

B+TREE

1) 继承B-TREE

2)n 棵子树的结点中含有n 个key;

3)所有的叶子结点中包含了全部关键码的信息,及指向含有这些关键码记录的指针,且叶子结点本身依关键码的大小自小而大的顺序链接。

4)所有的非终端结点可以看成是索引部分,结点中仅含有其子树根结点中最大(或最小)关键码。

那么更深层次的区别在哪里:

1. 数据(point/record) 在哪里? 如果按b-tree组织,数据有可能在 叶节点 中,有可能在 非叶节点中,对于B+tree,所有数据都在leaf中。

2. 非leaf节点的存储效能

2.1 B-TREE中,不管 non-leaf-NODE(中间层的节点)中存储的是 value的point,还是value的真实record,都需要耗费空间(内存、硬盘)存储这部分point/record

2.2 B+TREE中,non-leaf-node 只存储index,(本身自己还会在leaf中出现,自身的value在leaf中能找到)

2.3 有何意义? 

=> B+TREE每个中间层节点能表达的索引范围更大,系统不管读一次内存/硬盘(例如4K),能得到的索引更多,对于读取多个值的场景,索引查找过程中,内存分页/磁盘扇区复用的概率比B-TREE更高。对于写,B+TREE需要多写几层,也不好说就比B-TREE写的快。

=> seek的过程,B-TREE看运气,可能从ROOT跑到一半就找到值了,B+TREE所有都一样,固定的都需要从ROOT跑到LEAF。

3. 范围查询, 可能B+TREE更优秀

例如  col between 100 and 500, 如果是B-TREE, 查找需要2次,100所在点, 500所在的点,然后中序(先序?后序?)遍历这两个点中间的所有NODE,才能得到所有数据(因为数据在NODE内)。如果是B+TREE,只需要找一次,先找到100所在点,然后顺着 LEAF-LinkedNodeList一直往下走,碰到500停下来即可。

二、Leaf-Node的存储方式

     1. cluster index

key后面带着的就是record,  leaf-node就是data-node, 还有各种说法,例如什么index中key的顺序与data的顺序一致,都是一个意思。

zhangsan: zhangsan, male, 18, class 3, 32012121918231999

wanger: wanger, male, 18, class 3, 32321912831911123

     2. non-cluster index

key后面带着的是*recode,或者说地址,或者说point,一个意思。

zhangsan:  0x3211FF12,  或者  4:page707,21,         最后 ->  zhangsan, male, 18, class 3, 32012121918231999

wanger:     0x3241D5EB,  或者 17:page707, 22,           最后-> wanger, male, 18, class 3, 32321912831911123

那么区别在哪里?

1. non-cluster scan/seek到了leaf-node, 还需要再 get一次相应 address。而cluste-index不需要

2. non-cluster 中,兄弟(zhangsan,wanger)的index在一起,但实际record 往往不在一起,是否会产生大量缺页中断? 而cluster就可以充分的利用os的文件系统的预读特性(顺序读写, not随机读写),在大量读的场景,效率更高。

3. 一个表,只能有一个cluster-index,因为record只存一份(一致性、代价的考虑么?),其他都是non-cluster-index,non-cluster-index的value指向 cluster-index的key。

4. cluster-index对写的要求高, 写速度依赖写顺序、页分裂、树调整、空鼓等。

5. 多个表,共有一个key做外键,那么可以将此key做成cluster-index-space, 让表关联操作的消耗更低。(oracle中就有)

例如,  student, student-score. 可以一个block中存储两个表的数据,

BLOCK 101: 两个表的数据都有

0x10000000    TABLE_student:  zhangsan,  male, 19, ..................

0x10000010    TABLE_score:     zhangsan,  english,  90

BLOCK 102:

0x10001000   TABLE_student:  wanger,  male, 20 , ...................

0x10001010   TABLE_score:     wanger, english,  88

也可以做两个block之间的关联,如

BLOCK 201: 只有一个表

0x20000000    TABLE_student:  zhangsan,  male, 19, ..................

0x20001000      TABLE_student:  wanger,  male, 20 , ...................

BLOCK 202: 只有一个表

0x10000010    TABLE_score:     zhangsan,  english,  90

0x10001010    TABLE_score:     wanger, english,  88

当然,这个例子只是1:1关系的简单结构, n:n的关系更复杂一些,说到底,就是因为cluster-index保证了大家都是有序的,所以join操作的时候快一些。

三、Update 、 Delete对索引的影响

时间: 2024-11-03 19:19:21

RDBMS索引日志的相关文章

引擎 索引 日志查询 权限管理

存储引擎:定义:引擎就是驱动各种数据库的程序,它负责处理数据库相关工作的核心部份.同样的,数据库应用项目的操作指令,均会通过数据库引擎的处理作用到数据库上.引擎的选择: 大尺寸的数据集趋向于InnoDB引擎,因为它支持事务处理和故障恢复.数据库的大小决定了故障恢复的时间长短,InnoDB可以利用事务日志进行数据恢复,这会比较快.引擎分类:(Innodb): 默认版本包含5.5 以上 支持事务 不支持全文索引 索引和数据都在同一个文件中, .ibd 表的结构是在.frm文件中 (MyIsam):

MySQL六:索引原理与慢查询优化

阅读目录 一 介绍 二 索引的原理 三 索引的数据结构 三 MySQL索引管理 四 测试索引 五 正确使用索引 六 查询优化神器-explain 七 慢查询优化的基本步骤 八 慢日志管理 九 参考博客 一 介绍 为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句的优化显然是重中之重.说起加速查询,就不得不提到索引了. 什么是索引? 索引在MySQL中也叫做"

SolrCloud中索引数据存储于HDFS

SolrCloud中索引数据存储于HDFS 本人最近使用SolrCloud存储索引日志条件,便于快速索引,因为我的索引条件较多,每天日志记录较大,索引想到将日志存入到HDFS中,下面就说说怎么讲solr的索引条件数据存储到HDFS中. 一.准备工作 Solr环境或SolrCloud集群,如果不会安装可以看一下Solr5.5.4单机部署或者SolrCloud集群部署 HDFS分布式系统环境,如果不会安装的可以看一下Hadoop2.5.0安装部署 本人就以Solr5.5.4+Tomcat8.5.6单

Heka–>Elasticsearch 索引数据过程的优化

Heka 的参数配置跟Elasticsearch的参数没有关系,Heka只负责按照配置发送数据,所以索引的优化主要在 Elaticsearch端来完成. 下面是Elasticsearch的一些相关概念和知识点: 一些概念 在Elasticsearch中,文档归属于一种类型(type),而这些类型存在于索引(index)中,我们可以画一些简单的对比图来类比传统关系型数据库: Relational DB -> Databases -> Tables -> Rows -> Columns

47、索引原理与慢查询优化

一 介绍 为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句的优化显然是重中之重.说起加速查询,就不得不提到索引了. 什么是索引? 索引在MySQL中也叫做"键",是存储引擎用于快速找到记录的一种数据结构.索引对于良好的性能非常关键,尤其是当表中的数据量越来越大时,索引对于性能的影响愈发重要.索引优化应该是对查询性能优化最有效的手段了.索引能够轻易

mysql:索引原理与慢查询优化

一 介绍 二 索引的原理 三 索引的数据结构 三 MySQL索引管理 四 测试索引 五 正确使用索引 六 查询优化神器-explain 七 慢查询优化的基本步骤 八 慢日志管理 九 参考博客 一 介绍 为何要有索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句的优化显然是重中之重.说起加速查询,就不得不提到索引了. 什么是索引? 索引在MySQL中也叫做"键&quo

mysql基础(四)之索引

索引简介: 1.普通索引 普通索引(由关键字KEY或INDEX定义的索引)的唯一任务是加快对数据的访问速度.因此,应该只为那些最经常出现在查询条件 (WHEREcolumn=)或排序条件(ORDERBYcolumn)中的数据列创建索引.只要有可能,就应该选择一个数据最整齐.最紧凑的数据列(如 一个整数类型的数据列)来创建索引. 2.唯一索引 普通索引允许被索引的数据列包含重复的值.比如说,因为人有可能同名,所以同一个姓名在同一个“员工个人资料”数据表里可能出现两次或更多次. 如果能确定某个数据列

目前线上环境(ubuntu server)终于部署好一个logstash日志收集系统了

断断续续的看了一周logstash的文档,总算在线上ubuntu搭建起来一个logstash环境了.现在分享一下自己的经验 关于logstash 这玩意现在还算是火爆,依托于elasticsearch这棵大树下,logstash的关注度是非常高的,项目目前来说算是活跃.logstash是一个用于日志收集.分析的系统,架构设计非常灵活,几乎可以满足各种规模的需求. logstash的逻辑架构 logstash的逻辑架构其实一点都不复杂,经历收集->过滤->输出三个步骤即可简简单单的筛选与管理日志

代码开发过程中对日志的使用总结

在日常开发过程中,日志是代码的必要组成部分,一个好的代码也必然有一个好的日志输出,优秀的日志不仅可以快速帮助我们分析定位问题还可以在对日志的数据挖掘中产生很大的威力. 1.java在发生异常时可以打印它的堆栈信息以帮助调试,但是java的异常也有下列问题: 1)java出现异常时只能展示静态的调用堆栈信息,对应异常之前的调用参数则无法进行展示,也就是只知道哪里发生了异常,而不知道是哪些数据导致了异常: 2)java的异常堆栈通常是直接定位到某个文件的某一行,在发生异常时,如果不看代码都不知道异常