数据库的数据结构(3)——LSM-Tree与B-Tree.md

基于合并和压缩排序文件原理,以日志结构为主的的存储引擎——LSM引擎。

使用相关算法的数据库:LevelDB、RocksDB、Cassandra、HBase等

  • log写入(追加写入)时,将其添加到内存中的平衡树(内存表)数据结构中。
  • 当内存大于某个阈值(通常为若干MB,如redis自动aof的size是64mb)时,将其作为SSTable文件写入磁盘。由于树已经维护了按key排序的key-value对,写磁盘可以相对高效。新的SSTable已经成为数据库的最新部分。当SSTable写磁盘的时候,写入可以继续添加到一个新的内存表实例。
  • 每次处理读请求,首先常识在内存表中查找key,然后是最新的磁盘段文件,然后是次新的磁盘段文件,以此类推,直到找到目标或者为空。
  • 后台进程周期性地执行合并与压缩的过程,来合并多个段文件(可变大小),并丢弃哪些被覆盖或者被删除的部分。
  • 如果数据库崩溃,在内存表中但是尚未写入磁盘的log将会丢失,为了避免这种情况,可以在磁盘上保存单独的日志,每个写入都会立刻追加到日志。日志文件不需要按键排序,它唯一的目的是在崩溃中恢复内存表,当内存表写入SSTable时,相应的日志就可以被丢弃了。
一些可以优化的点
  • 布隆过滤器,直接判断key是否存在,节省空key的查找
  • 改变段合并和压缩的时机
    • 大小分级,HBase
    • 分层压缩,LevelDB,RockesDB
    • Cassandra支持以上两种
相对于B-tree的优点
  • LSM顺序写入磁盘的效率远高于随机写,并且定期重写SSTable可以去除磁盘碎片化。B-Tree则可能使磁盘空间部分空间无法使用(比如分裂页崩溃时导致的孤儿页)。
  • LSM相对于B-Tree拥有较小的写放大,B-Tree索引需要至少两次写入(一次WAL日志,一次写入树的页),每次更改有都要承受整个页的更改开销。而LSM以顺序方式写入文件,不必重写树中多个页。
相对于B-tree的缺点
  • 压缩过程容易干扰正在进行的读写操作,造成读写等待。B-Tree查询响应则更稳定。
  • 写入吞吐高的情况下,压缩带宽可能被写入带宽占用导致不足,造成磁盘空间有大量未合并段占用空间,因此需要额外的监控来及时发现这种情况。
  • 同一个键可能存在多个位置,B-Tree则每个键都唯一卫浴索引中的某个位置,更适合事务的使用。

最广泛使用的索引——B-Tree

拥有n个分支因子的B-Tree的深度为logn,一般是3-4层,分支因子为500的4kb的页可以存储数据256TB。

  • 将数据库分解为固定大小的页(内部读写最小单元),一般是4kb。每个页使用地址/位置进行标识,可以让一个页引用另一个页,形成一个树状结构。(类似指针,但是指向的是磁盘地址,不是内存)页包含若干键和对子页的引用等内容
  • 指定b树的一页为根,每当查询索引的一个键时候,从根节点开始
  • 键的更新:搜索含此键的叶子页,更改页的值,将页回写到磁盘。
  • 键的新增:类似于更新,如页空间满了,需要分裂成两个页,父页也需要进行更新
  • b树的增删改算法
一些存在的隐患以及可以采取防止手段
  • 键的新增需要更新父页时,数据库崩溃导致索引被破坏
    • 增加WAL(write-ahead log)日志,只支持追加写。在数据库奔溃的时候先用日志恢复B-tree
    • 使用写时复制,修改的页被写入不同的位置,树中的父页的新版本被创建,指向新的位置。(也能解决并发下多线程访问的问题)
  • 节省页的空间,只保存键的缩略信息。B+树
  • 为叶子页添加指向同级别的兄弟页,可以顺序扫描页不同跳回父页
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值