码迷,mamicode.com
首页 > 数据库 > 详细

数据库从0到0.1 (一): LSM-Tree VS B-Tree

时间:2019-06-16 00:28:41      阅读:138      评论:0      收藏:0      [点我收藏+]

标签:grep   缺陷   为什么   sign   一个个   bsp   net   接口   最新   

文章转自:https://blog.bcmeng.com/post/lsm-tree-vs-b-tree.html

数据库最基本两个功能:数据的存储和数据的查询。 当我们写入数据时,数据库可以存储数据;当我们需要访问数据时,数据库可以给我们想要的数据。 数据库会通过特定的数据模型和数据结构存储数据,并支持通过特定的查询语言访问数据。本文将从最简单的数据库开始,讨论数据库如何存储数据,如何查询数据。本文将讨论两种存储引擎:log-structured 存储引擎和以B+树为代表的page-oriented存储引擎。

1 最简单的数据库

#!/bin/bash

#key,value对追加写入文件的最后一行
db_set () {    
    echo "$1,$2" >> database
}

#查找指定key的最后一行的最新的value
db_get () {    
    grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

上面两个Shell函数实现了最简单的Key-Value数据库。 调用db_set可以写入数据,调用db_get可以查询数据,数据的物理存储格式是逗号分隔的普通文本文件。

bash-3.2$ db_set 1 kks
bash-3.2$ db_get 1
kks
bash-3.2$ db_set 2 kangkaisen
bash-3.2$ db_get 2
kangkaisen
bash-3.2$ db_set 1 KKS
bash-3.2$ db_get 1
KKS
bash-3.2$ cat database
1,kks
2,kangkaisen
1,KKS

其中db_set函数拥有很好的写入性能,因为是追加写;但是db_get函数的性能十分糟糕,其时间复杂度是O(n),我们每次必须全表Scan。

2 Index

为了能够快速找到特定Key对应的Value, 我们需要引入一个数据结构:Index。 所谓Index,就是我们在数据库中增加额外的元数据,然后Index像路标一样可以快速知道我们需要访问数据的位置和偏移量。 Index类似汉语字典中的索引和一般书籍中的目录。如果我们需要按照不同的方式访问相同的数据,我们有可能需要多种不同的索引,比如按照Key查询和按照Value查询,我们会分别需要针对Key的索引和针对Value的索引。

Index是基于原始数据衍生的附加的数据结构,增加索引必然意味着降低数据写入速度,增大存储空间,所以Index是以数据写入时的处理成本和存储的空间成本来换取查询的加速。这也是数据库设计的一个trade-off,不同索引的查询加速比,写入时的处理成本,存储的空间成本往往是不同的,所以在设计数据库时选择何种索引是一个很重要的点。

3 Hash Index

下面就让我们用Index加速之前最简单的Key-Value DB。之前我们db_get方法查询特定Key必须全表Scan的原因,是因为我们不知道特定Key在文件中的Offset,假如我们知道了每个Key的Offset,我们就可以直接Seek到Key对应的Offset,直接读取Key对应的Value。而Key到Offset的映射我们自然会想起到我们熟悉的数据结构HashMap,我们可以在内存中维护一个HashMap,HashMap的Key就是Key-Value DB的每一条记录的Key,HashMap的Value就是每一条记录在文件中的Offset。

技术图片

有了HashMap后,我们每次写数据后就必须要更新HashMap,查询数据时先从HashMap获取特定Key的Offset,再直接Seek到文件对应Offset的位置,读取数据。 事实上Bitcask(Riak的默认存储引擎)就是这样做的。

不过显然Hash Index有两个缺陷:

  1. 内存的大小必须可以放下Hash Table
  2. Range Scan的效率十分低下

4 Segment

目前为止,我们都是把数据写到一个文件中,这显然是不合理的。 一个常见的做法就是将文件按照大小拆为为Segment,每个Segment是不可变的。 Segment的概念很常见,比如Kylin和Druid中都有Segment的概念,指一定大小或者一定时间内不可变的文件。

第1部分我们知道,我们同一个Key的Value的更新只是追加写入,并没有删除旧的Value。 当我们有了多个Segment后,我们自然就可以定期在后台执行Compaction操作,将同一个Key的旧Value删除,更进一步,如果我们数据库支持delete的话,我们可以在一开始只进行标记,并不实际删除,等到Compaction的时候,我们再进行实际删除。 总之一句话,基于log-structured的存储引擎,我们可以通过后台的Compaction来实现update和delete,Compaction时依然可以进行数据的写入和查询。

技术图片

至此,每个Segment文件都在内存中有了对应的Hash table。 我们查询时为了找到特定Key对应的Value,我们依次查询每个Segment文件即可,查询每个Segment文件的过程和之前一样。

这种Append-only Log-structured的存储引擎的优点:

  1. 顺序写的效率远高于随机写
  2. 并发控制和故障恢复十分简单,因为Segment文件是不可变的,且是Append-only的,

为什么不再对Segment文件做索引呢?

这样我们就不需要顺序遍历每个Segment文件了,有了索引我们就只需要访问包含特定Key的Segment文件。

5 SSTables and LSM-Trees

现在对Segment文件的格式做个简单的改变:我们要求所有的 key-value对必须按照Key排序。 这种格式我们称之为Sorted String Table, 简称为SSTable。 我们也要求在每个已经Merged的Segment文件中1个Key只会出现一次,Compaction过程保证了这一点。

SSTable相比Log Segments + Hash Indexes 有以下几个明显的优势:

  1. Segment的Merge会更加简单和高效,即使合并的所有文件比内存还大。 因为每个Segment是有序的,Sort Merge的成本比较低。
  2. 为了查找特定Key,我们不再需要在内存中维护一个很大的Hash Map。因为所有的key-value对是按照Key排序的,所以我们可以维护一个Segment文件的稀疏索引,索引的Key是每个Segment文件的Start Key,Value就是每个Segment文件的位置。 其次,在Segment内部,由于Segment有序,我们不再需要针对每个key-value对都构建索引,我们可以针对Block(几百或者几千行数据)粒度做稀疏索引,Block内存则进行二次查询。
  3. 由于我们的读取的最小粒度是Block,我们也可以基于Blcok粒度做压缩,减小磁盘空间和IO。
  4. SSTable不仅可以较好的支持Point Query,也可以很好的支持Range Scan。

技术图片

那么我们如何保证Segment文件有序呢? 因为数据写入一般都要经过内存,在内存中我们可以利用Red-black tree 或者AVL tree保证有序。

至此,我们基于SSTable的存储引擎可以这样Run起来:

  1. 当一条数据写入时,我们将其插入到基于内存的平衡树中(Red-black tree)。 内存中的树我们称之为Memtable。
  2. 当Memtable的大小超过一定阈值时,我们将Memtable Flush到磁盘,转为SSTable。
  3. 当我们查询时,需要同时查询内存中的Memtable和磁盘中的SSTable。
  4. 周期性的在后台进行异步的Merge和Compaction操作。
  5. 为了防止Memtable在Flush到磁盘前机器故障导致数据丢失,我们可以在磁盘上维护一个只追加写的log文件,称之为Write-Ahead-Log,当集群故障后可以从log中恢复出Memtable。 所以我们在每次写入Memtable,需要先写入WAL。当Memtable flush到磁盘后,对应的WAL文件就可以删除。

至此,LSM-Tree(Log-Structured Merge-Tree)的3个组件:SSTable,Memtable,Write-Ahead-Log终于全了。 从开始最简单的Key-Value 数据库 讲到现在,我相信你已经理解了LSM-Tree的核心思想。

LSM-Tree 已经被广泛使用,比如LevelDB,RocksDB,Cassandra,HBase等,其中的SSTable也是被广泛借鉴,比如ClickHouse,Palo等。

6 磁盘简介

技术图片

如图,一个磁盘由多个盘片组成。

技术图片

如图,1个盘片由一个个的同心圆组成,一个同心圆就是一个磁道,每个磁道由多个扇区组成,每个磁道的扇区数量是一个常量,每个扇区的大小一般是4KB,扇区是磁盘基本的物理单元。

一次磁盘IO的耗时主要由三部分组成:寻道时间 + 旋转延迟 + 数据传输时间。

  1. 寻道时间: 将读写磁头移动至正确的磁道上所需要的时间。 目前磁盘的平均寻道时间一般在3-15ms。
  2. 旋转延迟: 盘片旋转将请求数据所在的扇区移动到读写磁盘下方所需要的时间。旋转延迟取决于磁盘转速,转速为15000rpm的磁盘其平均旋转延迟为2ms。
  3. 数据传输时间:传输实际数据所需要的时间,它取决于数据传输率,其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/s,SATA II可达到300MB/s的接口数据传输率,数据传输时间通常远小于前两部分消耗时间。

提高磁盘读写速度方法就是尽量减小寻道时间和旋转延迟,而减少寻道时间和旋转延迟的方法就是减少磁盘的随机IO,这就是为什么磁盘顺序读写的性能远高于随机读写的原因。

7 B-Trees

前面我们从零开始了解了LSM-Tree的核心原理,但是在数据库领域使用最广泛的索引结构是B-tree及其变种。

其实之前我们为最简单的数据库增加索引的时候,如果我们同时希望提高查询性能,支持原地更新和删除,支持Point query和Scan query, 保持高效的插入性能,我们就会比较自然的想到二叉查找树, 平衡二叉查找树,红黑树,B-Tree 及其最常见的变种B+Tree等树结构, 如果再考虑到面向磁盘,以及更好地支持Scan query,我们就会选择B+Tree。B+Tree具有较低的深度,这样就减少了磁盘 Seek操作的次数。

类似LSM-Tree,B-Tree也可以提供高效地Point query和Scan query。 但是两者的设计哲学是完全不同的:LSM-Tree是将数据拆分为几百M大小的Segments,并是顺序写入;B-Tree则是面向磁盘,将数据拆分为固定大小的Block或Page, 一般是4KB大小,和磁盘一个扇区的大小对应,Page是读写的最小单位。

技术图片

在数据的更新和删除方面,B-Tree可以做到原地更新和删除,但由于LSM-Tree只能追加写,所以只能在Segment Compaction的时候进行真正地更新和删除。

大家可以通过B+Tree 可视化理解B+Tree的插入,查找,更新和删除过程。

关于B+Tree更详细的原理可以参考此文MySQL索引背后的数据结构及算法原理

8 B-Tree VS LSM-Tree

一般而言, LSM-tree的写更加高效(追加顺序写),B-tree的读更加高效(LSM-tree需要访问几个不同的数据结构)。

LSM-Tree的优点:

  1. 高吞吐的写
  2. 可以高效的压缩,更节省磁盘(B-Tree一般会为Page的分裂预留一些空间)

LSM-Tree的缺点:

  1. Compaction会影响正常数据的读写。 阿里为了优化这个问题,X-DB的Compaction使用了FPGA来进行。
  2. 数据量越大,Compaction需要的磁盘带宽就越多。
  3. B-Tree中一个Key只会出现在一个Page,但是LSM-tree中一个key可能出现在多个Segment,所以B-Tree实现事务更加简单。

9 参考资料

1《Designing-Data-Intensive-Applications》第3章的第一部分《Data Structures That Power Your Database》

计算机底层知识拾遗(三)理解磁盘的机制 第6部分磁盘简介参考

磁盘I/O那些事 第6部分磁盘简介参考

数据库从0到0.1 (一): LSM-Tree VS B-Tree

标签:grep   缺陷   为什么   sign   一个个   bsp   net   接口   最新   

原文地址:https://www.cnblogs.com/zgzf/p/11029367.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!