数据库基础-B+树
查询类型
- 全表扫描,不提供索引,扫描所有集合中的数据。
- 根据指定key值查询指定点
- 范围查询,在指定区间内查询
有很多方法能够进行快速扫面数据,但是再快复杂度也是O(N),我们的目标是想办法将查询复杂度降低到O(logN)。
A range query consists of 2 phases:
- Seek: find the starting key.
- Iterate: find the previous/next key in sorted order.
哈希表
在讨论如何构建哈希表(hashtable),尤其是内存中的哈希表时,确实存在一些挑战。尽管如此,相较于之后会编写的B树,编写哈希表还是相对简单的。以下是一些需要考虑的问题和解决方案:
-
如何扩展哈希表? 当负载因子过高时,意味着当前哈希表的容量不足以有效地处理更多的键值对,这时就需要将键迁移到一个更大的哈希表中。如果一次性移动所有数据,其时间复杂度为Ο(Ν),这在实际应用中是非常不理想的。因此,重新散列(rehashing)必须渐进式地进行,即使是像Redis这样的内存应用程序也应如此。一种常见的做法是在每次插入新键值对时,随机选择一定比例的旧键值对进行重散列,直到所有键都被迁移至新的哈希表。
-
其他提及的事项:
- 就地更新(In-place updates): 这指的是直接在现有存储位置上更新键值对,而不是删除再插入。这对于保持哈希表的性能非常重要。
- 空间复用(Space reuse): 有效管理哈希表的空间使用情况,包括回收被删除键值对占用的空间,以减少内存碎片并提高内存使用效率。
排序数组
讨论完哈希表后,让我们转向最简单的排序数据结构:排序数组(sorted array)。对于如字符串这样的可变长度数据(键值对),可以使用指针(或偏移量)数组来进行二分查找,其时间复杂度为Ο(log Ν)。
然而,更新排序数组的成本是Ο(Ν),无论是否就地更新。这意味着直接在排序数组中进行插入和删除操作并不是非常实用,尤其是在需要频繁更新的场景下。不过,这种结构可以通过一些方式扩展成更复杂的、支持高效更新的数据结构。
一种减少更新成本的方法是将数组分割成几个较小的、互不重叠的数组——即嵌套排序数组。这种扩展最终可以发展为B+树(多级n叉树),但同时也带来了维护这些小数组(即树节点)的额外挑战。
另一种形式的“可更新数组”是日志结构合并树(Log-Structured Merge Tree, LSM树)。在这种结构中,更新首先被缓冲在一个较小的数组(或其他排序数据结构)中,当这个数组变得过大时,再与主数组合并。通过将较小数组逐步合并到较大数组中的方式,摊销了更新成本。
LSM树的设计旨在优化写入密集型应用场景,它通过对数据进行批量处理来提高效率,尽管这可能会以增加读取操作的复杂性为代价。这种方法非常适合于需要处理大量写入操作的应用程序,例如数据库系统。通过这种方式,不仅解决了原始排序数组更新成本高的问题,还提供了一种有效管理大规模数据集的方法。
MVCC也是为了应对写密集型
B树
B树是一种平衡的n叉树,类似于平衡二叉树。每个节点可以存储多达𝑛个键(和分支),其中𝑛大于2。B树的设计主要是为了减少磁盘随机访问次数,从而提高查询效率。
减少随机访问次数
由于磁盘每秒只能执行有限数量的IO操作(IOPS),这是查找操作的主要限制因素。在进行查找时,树的每一层都对应一次磁盘读取。对于相同数量的键,n叉树比二叉树更短(log𝑛 𝑁对比log₂ 𝑁),因此使用n叉树可以减少每次查找所需的磁盘读取次数。
选择𝑛值时存在权衡:
- 较大的𝑛值意味着每次查找需要的磁盘读取次数较少,这能改善延迟和吞吐量。
- 但是,较大的𝑛值也意味着节点更大,更新速度较慢(这将在后面讨论)。
磁盘IO的基本单位是页面
虽然你可以从文件的任意偏移量读取任意数量的字节,但磁盘并不是这样工作的。磁盘IO的基本单位不是字节,而是扇区,在旧的HDD上,扇区是512字节的连续块。
然而,应用程序并不直接关心磁盘扇区,因为常规文件IO不直接与磁盘交互。操作系统会在页缓存中缓存/缓冲磁盘读写,页缓存由称为“页”的4KB内存块组成。
无论如何,存在一个最小的IO单位。数据库也可以定义自己的IO单位(也称为“页”),其大小可能超过操作系统的页大小。
最小IO单位意味着树节点应该以该单位的倍数分配;如果一个单位只使用了一半,则另一半就浪费了IO资源。这也是反对使用较小的𝑛值的另一个原因!
通过确保树节点的大小为IO基本单位的整数倍,可以最大化利用每一次IO操作,减少因未充分利用IO单位而造成的浪费。这对于优化数据库性能至关重要,尤其是在处理大量数据和高并发场景时。此外,考虑到节点大小对更新性能的影响,合理选择𝑛值可以在查询性能和更新成本之间取得平衡。
B+树的优势
在数据库的上下文中,提到的B树通常指的是其一种变体——B+树。B+树的特点是内部节点不存储实际值,只存储键和指向子节点的指针;所有的值仅存在于叶节点中。这种设计使得B+树的内部节点可以容纳更多的分支,从而导致树的高度更矮、结构更扁平。
- 缩短树的高度:由于内部节点无需存储数据值,它们可以使用更多的空间来存储键和指针,这允许每个节点包含更多的子节点,从而降低了树的高度。
- 内存中的B+树:即使作为内存中的数据结构,B+树依然有意义。例如,在RAM与CPU缓存之间,最小的IO单位是64字节(缓存行)。尽管在这种情况下性能提升不如磁盘上的那么显著,因为64字节能容纳的数据量有限,但优化仍然有效。
数据结构的空间开销
二叉树在实际应用中往往不太实用的一个原因是其大量的指针开销。对于每个键,至少需要一个来自父节点的指针。而在B+树中,多个键共享一个来自父节点的指针,这样就大大减少了指针的数量和因此带来的空间开销。
此外,B+树的叶节点中的键还可以以紧凑格式存储或进行压缩,以进一步减少空间占用。这种方式不仅节省了存储空间,也提高了缓存的命中率,进而提升了访问效率。通过这些优化措施,B+树能够在保证高效查询的同时,也能够有效地管理空间使用,使其成为许多数据库系统底层存储结构的首选。
日志结构存储(Log-structured Storage)
Update by merge: amortize cost
日志结构存储的核心思想是通过“合并”操作来摊销更新成本,其中最典型的例子是日志结构合并树(LSM-tree)。尽管名字中包含“日志”和“树”,但其核心机制实际上是合并。
基本原理:双文件系统
我们从两个文件开始:
- 小文件:用于存储最近的更新。
- 大文件:用于存储其余的数据。
更新首先写入小文件,但小文件不能无限增长。当小文件达到某个阈值时,它会被合并到大文件中。
writes => | 新更新 | => | 积累的数据 |file 1 file 2
合并操作会生成一个新的、更大的文件,用以替换旧的大文件,同时清空小文件。合并的时间复杂度为𝑂(𝑁),但由于合并可以与读写操作并发执行,因此不会显著影响性能。
多级合并:减少写放大效应
缓冲更新比每次重写整个数据集更高效,但如果我们将这种机制扩展到多个层级,效果会更好:
| 第1层 |||\/|------第2层------|||\/
|-----------------第3层-----------------|
在两级方案中,每当小文件达到阈值时,大文件都会被重写。这种额外的磁盘写入称为写放大效应(write amplification)。随着大文件的增长,写放大效应会变得更加严重。
通过引入更多层级,我们可以将第2层保持较小规模,将其合并到第3层,类似于如何保持第1层的小规模。直观上,每一层的大小呈指数增长(例如,第2层是第1层的两倍,第3层是第2层的两倍),并且将规模相似的层级进行合并可以最小化写放大效应。
写放大效应与层级数量的权衡
虽然增加层级数量可以有效减少写放大效应,但这也会对查询性能产生负面影响:
- 更多的层级意味着查询时可能需要访问更多的文件,从而增加了查询的复杂性。
- 更少的层级则可能导致更高的写放大效应。
因此,在设计LSM-tree时,需要在写放大效应和查询性能之间找到平衡点。
总结
日志结构存储(如LSM-tree)通过合并操作摊销了更新成本,并通过多级结构进一步优化了写放大效应。其关键特点包括:
- 高效的写入性能:更新被缓冲在小文件中,避免频繁重写整个数据集。
- 可控的写放大效应:通过多级合并,减少不必要的磁盘写入。
- 灵活性:可以根据具体应用场景调整层级数量,权衡写放大效应和查询性能。
LSM-tree 索引
在 LSM-tree 中,每一层都包含索引数据结构。由于除第 1 层外的所有层都不会被直接更新,因此一个简单的选择是使用排序数组作为索引。然而,二分查找在随机访问上的性能优势并不比二叉树显著,因此更合理的做法是在每一层中使用 B 树,这就是 LSM-tree 名字中的“树”部分。
无论如何,由于缺乏直接的更新操作,数据结构的设计变得更加简单。
合并的思想与哈希表的类比
为了更好地理解“合并”的思想,可以尝试将其应用于哈希表。这种设计被称为日志结构哈希表(log-structured hashtable)。尽管实现方式不同,但其核心思想仍然是通过缓冲和合并来优化写入性能。
LSM-tree 查询
在 LSM-tree 中,键可能存在于任何层级中,因此查询时需要将所有层级的结果结合起来:
- 范围查询:采用多路归并(n-way merge)。
- 点查询:可以通过布隆过滤器(Bloom filters)优化,减少需要搜索的层级数量。
由于旧层级不会被更新,因此可能存在旧版本的键,而删除的键会在新层级中标记为特殊标志(称为墓碑,tombstone)。因此,在查询时,新层级具有优先级。
合并过程会自然地回收旧键或已删除键占用的空间,这个过程也被称为压缩(compaction)。
实际应用中的 LSM-tree:SSTable、MemTable 和日志
这些术语描述了 LSM-tree 的实现细节。虽然从原理上构建 LSM-tree 不需要了解它们,但它们确实解决了一些实际问题。
-
SSTable(Sorted String Table)
每一层被分成多个互不重叠的文件,而不是一个大文件。这样做的好处包括:- 合并操作可以逐步进行,避免一次性合并大文件所需的大量空闲空间。
- 合并过程可以分散到时间上,降低峰值资源需求。
-
日志(Log)
第 1 层可以直接更新,但由于其大小有限,使用日志是一个合理的选择。这是 LSM-tree 名字中的“日志”部分,展示了如何将日志与其他索引数据结构结合使用。 -
MemTable
即使日志很小,仍然需要一个适当的索引数据结构来加速查询。日志数据会被复制到内存中的索引结构,称为 MemTable。MemTable 可以是 B 树、跳表(skiplist)或其他结构。它是一个小而有界的内存数据结构,能够加速对最近更新的读取场景。
索引数据结构的总结
目前有两种主要的索引数据结构选择:
-
B+树
B+树适用于需要频繁更新的场景,但在磁盘上的更新效率较低,并且空间复用的问题需要额外处理。 -
LSM-tree
LSM-tree 解决了许多上一章提到的挑战,例如如何高效更新基于磁盘的数据结构以及如何复用空间。虽然这些问题对于 B+树依然存在
总结对比
特性 | B+树 | LSM-tree |
---|---|---|
更新效率 | 较低(每次更新需维护树结构) | 高效(通过合并摊销成本) |
查询效率 | 快速(单次查询即可找到目标) | 较慢(需多层查询与合并) |
空间复用 | 需要额外机制 | 自然支持(通过压缩回收空间) |
适用场景 | 频繁读取与少量更新 | 写密集型工作负载 |
通过理解这两种数据结构的特点,可以根据具体应用场景选择最适合的解决方案。