ddia/ch3.md

85 KiB
Raw Blame History

第三章:存储与检索

建立秩序,省却搜索

——德国谚语


[TOC]

一个数据库在最基础的层次上需要完成两件事情:当你把数据交给数据库时,它应当把数据存储起来;而后当你向数据库要数据时,它应当把数据返回给你。

第二章中,我们讨论了数据模型和查询语言,即程序员将数据录入数据库的格式,以及再次要回数据的机制。在本章中我们会从数据库的视角来讨论同样的问题:数据库如何存储我们提供的数据,以及如何在我们需要时重新找到数据。

作为程序员,为什么要关心数据库内部存储与检索的机理?你可能不会去从头开始实现自己的存储引擎,但是你确实需要从许多可用的存储引擎中选择一个合适的。而且为了让存储引擎能在你的工作负载类型上运行良好,你也需要大致了解存储引擎在底层究竟做了什么。

特别需要注意,针对事务性负载优化的和针对分析性负载优化的存储引擎之间存在巨大差异。稍后我们将在 “事务处理还是分析?” 一节中探讨这一区别,并在 “列式存储”中讨论一系列针对分析性负载而优化的存储引擎。

但首先我们将从你可能已经很熟悉的两大类数据库传统的关系型数据库和很多所谓的“NoSQL”数据库中使用的存储引擎来开始本章的内容。我们将研究两大类存储引擎:日志结构log-structured 的存储引擎,以及面向页面page-oriented 的存储引擎例如B树

驱动数据库的数据结构

世界上最简单的数据库可以用两个Bash函数实现

#!/bin/bash
db_set () {
  echo "$1,$2" >> database
}

db_get () {
  grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

这两个函数实现了键值存储的功能。执行 db_set key value 会将 keyvalue 存储在数据库中。键和值几乎可以是你喜欢的任何东西例如值可以是JSON文档。然后调用 db_get key 会查找与该键关联的最新值并将其返回。

麻雀虽小,五脏俱全:

$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'

$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}

底层的存储格式非常简单一个文本文件每行包含一条逗号分隔的键值对忽略转义问题的话大致与CSV文件类似。每次对 db_set 的调用都会向文件末尾追加记录,所以更新键的时候旧版本的值不会被覆盖 —— 因而查找最新值的时候,需要找到文件中键最后一次出现的位置(因此 db_get 中使用了 tail -n 1 。)

$ db_set 42 '{"name":"San Francisco","attractions":["Exploratorium"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Exploratorium"]}

$ cat database
123456,{"name":"London","attractions":["Big Ben","London Eye"]}
42,{"name":"San Francisco","attractions":["Golden Gate Bridge"]}
42,{"name":"San Francisco","attractions":["Exploratorium"]}

db_set 函数对于极其简单的场景其实有非常好的性能,因为在文件尾部追加写入通常是非常高效的。与db_set做的事情类似,许多数据库在内部使用了日志log,也就是一个 仅追加append-only 的数据文件。真正的数据库有更多的问题需要处理(如并发控制,回收硬盘空间以避免日志无限增长,处理错误与部分写入的记录),但基本原理是一样的。日志极其有用,我们还将在本书的其它部分重复见到它好几次。

日志log 这个词通常指应用日志:即应用程序输出的描述正在发生的事情的文本。本书在更普遍的意义下使用日志这一词:一个仅追加的记录序列。它可能压根就不是给人类看的,它可以使用二进制格式,并仅能由其他程序读取。

另一方面,如果这个数据库中有着大量记录,则这个db_get 函数的性能会非常糟糕。每次你想查找一个键时,db_get 必须从头到尾扫描整个数据库文件来查找键的出现。用算法的语言来说,查找的开销是 O(n) :如果数据库记录数量 n 翻了一倍,查找时间也要翻一倍。这就不好了。

为了高效查找数据库中特定键的值,我们需要一个数据结构:索引index。本章将介绍一系列的索引结构,并在它们之间进行比较。索引背后的大致思想是通过保存一些额外的元数据作为路标来帮助你找到想要的数据。如果你想以几种不同的方式搜索同一份数据,那么你也许需要在数据的不同部分上建立多个索引。

索引是从主数据衍生的额外的additional 结构。许多数据库允许添加与删除索引,这不会影响数据的内容,而只会影响查询的性能。维护额外的结构会产生开销,特别是在写入时。写入性能很难超过简单地追加写入文件,因为追加写入是最简单的写入操作。任何类型的索引通常都会减慢写入速度,因为每次写入数据时都需要更新索引。

这是存储系统中一个重要的权衡精心选择的索引加快了读查询的速度但是每个索引都会拖慢写入速度。因为这个原因数据库默认并不会索引所有的内容而需要你也就是程序员或数据库管理员DBA基于对应用的典型查询模式的了解来手动选择索引。你可以选择那些能为应用带来最大收益而且又不会引入超出必要开销的索引。

散列索引

让我们从键值数据key-value Data 的索引开始。这不是你可以索引的唯一数据类型,但键值数据是很常见的。对于更复杂的索引来说,这也是一个有用的构建模块。

键值存储与在大多数编程语言中可以找到的字典dictionary 类型非常相似,通常字典都是用散列映射hash map(或散列表hash table实现的。散列映射在许多算法教科书中都有描述【1,2】所以这里我们不会讨论它的工作细节。既然我们已经可以用散列映射来表示内存中的数据结构,为什么不使用它来索引硬盘上的数据呢?

假设我们的数据存储只是一个追加写入的文件,就像前面的例子一样,那么最简单的索引策略就是:保留一个内存中的散列映射,其中每个键都映射到数据文件中的一个字节偏移量,指明了可以找到对应值的位置,如图3-1所示。当你将新的键值对追加写入文件中时,还要更新散列映射,以反映刚刚写入的数据的偏移量(这同时适用于插入新键与更新现有键)。当你想查找一个值时,使用散列映射来查找数据文件中的偏移量,寻找seek 该位置并读取该值即可。

图3-1 以类CSV格式存储键值对的日志并使用内存散列映射进行索引。

听上去简单但这是一个可行的方法。现实中Bitcask实际上就是这么做的Riak中默认的存储引擎【3】。 Bitcask提供高性能的读取和写入操作但要求所有的键必须能放入可用内存中因为散列映射完全保留在内存中。而数据值可以使用比可用内存更多的空间因为可以在硬盘上通过一次硬盘查找操作来加载所需部分如果数据文件的那部分已经在文件系统缓存中则读取根本不需要任何硬盘I/O。

像Bitcask这样的存储引擎非常适合每个键的值经常更新的情况。例如键可能是某个猫咪视频的网址URL而值可能是该视频被播放的次数每次有人点击播放按钮时递增。在这种类型的工作负载中有很多写操作但是没有太多不同的键 —— 每个键有很多的写操作,但是将所有键保存在内存中是可行的。

直到现在,我们只是追加写入一个文件 —— 所以如何避免最终用完硬盘空间一种好的解决方案是将日志分为特定大小的段segment当日志增长到特定尺寸时关闭当前段文件并开始写入一个新的段文件。然后我们就可以对这些段进行压缩compaction,如图3-2所示。这里的压缩意味着在日志中丢弃重复的键,只保留每个键的最近更新。

图3-2 键值更新日志(统计猫咪视频的播放次数)的压缩,只保留每个键的最近值

而且,由于压缩经常会使得段变得很小(假设在一个段内键被平均重写了好几次),我们也可以在执行压缩的同时将多个段合并在一起,如图3-3所示。段被写入后永远不会被修改,所以合并的段被写入一个新的文件。冻结段的合并和压缩可以在后台线程中完成,这个过程进行的同时,我们仍然可以继续使用旧的段文件来正常提供读写请求。合并过程完成后,我们将读取请求转换为使用新合并的段而不是旧的段 —— 然后旧的段文件就可以简单地删除掉了。

图3-3 同时执行压缩和分段合并

每个段现在都有自己的内存散列表,将键映射到文件偏移量。为了找到一个键的值,我们首先检查最近的段的散列映射;如果键不存在,我们就检查第二个最近的段,依此类推。合并过程将保持段的数量足够小,所以查找过程不需要检查太多的散列映射。

要让这个简单的想法在实际中能工作会涉及到大量的细节。简单来说,下面几点都是实现过程中需要认真考虑的问题:

文件格式

CSV不是日志的最佳格式。使用二进制格式更快更简单首先以字节为单位对字符串的长度进行编码然后是原始的字符串不需要转义

删除记录

如果要删除一个键及其关联的值则必须在数据文件中追加一个特殊的删除记录有时称为逻辑删除tombstone。当日志段被合并时逻辑删除告诉合并过程丢弃被删除键的任何以前的值。

崩溃恢复

如果数据库重新启动,则内存散列映射将丢失。原则上,你可以通过从头到尾读取整个段文件并记录下来每个键的最近值来恢复每个段的散列映射。但是,如果段文件很大,可能需要很长时间,这会使服务的重启比较痛苦。 Bitcask 通过将每个段的散列映射的快照存储在硬盘上来加速恢复,可以使散列映射更快地加载到内存中。

部分写入记录

数据库随时可能崩溃,包括在将记录追加到日志的过程中。 Bitcask文件包含校验和允许检测和忽略日志中的这些损坏部分。

并发控制

由于写操作是以严格的顺序追加到日志中的,所以常见的实现是只有一个写入线程。也因为数据文件段是仅追加的或者说是不可变的,所以它们可以被多个线程同时读取。

乍一看,仅追加日志似乎很浪费:为什么不直接在文件里更新,用新值覆盖旧值?仅追加的设计之所以是个好的设计,有如下几个原因:

  • 追加和分段合并都是顺序写入操作,通常比随机写入快得多,尤其是在磁性机械硬盘上。在某种程度上,顺序写入在基于闪存的固态硬盘SSD 上也是好的选择【4】。我们将在“比较B树和LSM树”中进一步讨论这个问题。
  • 如果段文件是仅追加的或不可变的,并发和崩溃恢复就简单多了。例如,当一个数据值被更新的时候发生崩溃,你不用担心文件里将会同时包含旧值和新值各自的一部分。
  • 合并旧段的处理也可以避免数据文件随着时间的推移而碎片化的问题。

但是,散列表索引也有其局限性:

  • 散列表必须能放进内存。如果你有非常多的键那真是倒霉。原则上可以在硬盘上维护一个散列映射不幸的是硬盘散列映射很难表现优秀。它需要大量的随机访问I/O当它用满时想要再增长是很昂贵的并且散列冲突的处理也需要很烦琐的逻辑【5】。
  • 范围查询效率不高。例如你无法轻松扫描kitty00000和kitty99999之间的所有键——你必须在散列映射中单独查找每个键。

在下一节中,我们将看到一个没有这些限制的索引结构。

SSTables和LSM树

图3-3中,每个日志结构存储段都是一系列键值对。这些键值对按照它们写入的顺序排列,日志中稍后的值优先于日志中较早的相同键的值。除此之外,文件中键值对的顺序并不重要。

现在我们可以对段文件的格式做一个简单的改变:要求键值对的序列按键排序。乍一看,这个要求似乎打破了我们使用顺序写入的能力,我们将稍后再回到这个问题。

我们把这个格式称为排序字符串表Sorted String Table简称SSTable。我们还要求每个键只在每个合并的段文件中出现一次压缩过程已经保证。与使用散列索引的日志段相比SSTable有几个大的优势

  1. 即使文件大于可用内存,合并段的操作仍然是简单而高效的。这种方法就像归并排序算法中使用的方法一样,如图3-4所示:你开始并排读取多个输入文件,查看每个文件中的第一个键,复制最低的键(根据排序顺序)到输出文件,不断重复此步骤,将产生一个新的合并段文件,而且它也是也按键排序的。

    图3-4 合并几个SSTable段只保留每个键的最新值

    如果在几个输入段中出现相同的键,该怎么办?请记住,每个段都包含在一段时间内写入数据库的所有值。这意味着一个输入段中的所有值一定比另一个段中的所有值都更近(假设我们总是合并相邻的段)。当多个段包含相同的键时,我们可以保留最近段的值,并丢弃旧段中的值。

  2. 为了在文件中找到一个特定的键,你不再需要在内存中保存所有键的索引。以图3-5为例:假设你正在内存中寻找键 handiwork,但是你不知道这个键在段文件中的确切偏移量。然而,你知道 handbaghandsome 的偏移,而且由于排序特性,你知道 handiwork 必须出现在这两者之间。这意味着你可以跳到 handbag 的偏移位置并从那里扫描,直到你找到 handiwork(或没找到,如果该文件中没有该键)。

    图3-5 具有内存索引的SSTable

    你仍然需要一个内存中的索引来告诉你一些键的偏移量,但它可以是稀疏的:每几千字节的段文件有一个键就足够了,因为几千字节可以很快地被扫描完1

  1. 由于读取请求无论如何都需要扫描所请求范围内的多个键值对因此可以将这些记录分组为块block并在将其写入硬盘之前对其进行压缩图3-5中的阴影区域所示)2 。稀疏内存索引中的每个条目都指向压缩块的开始处。除了节省硬盘空间之外压缩还可以减少对I/O带宽的使用。

构建和维护SSTables

到目前为止还不错,但是如何让你的数据能够预先排好序呢?毕竟我们接收到的写入请求可能以任何顺序发生。

虽然在硬盘上维护有序结构也是可能的(请参阅“B树但在内存保存则要容易得多。有许多可以使用的众所周知的树形数据结构例如红黑树或AVL树【2】。使用这些数据结构你可以按任何顺序插入键并按排序顺序读取它们。

现在我们可以让我们的存储引擎以如下方式工作:

  • 有新写入时,将其添加到内存中的平衡树数据结构(例如红黑树)。这个内存树有时被称为内存表memtable
  • 内存表大于某个阈值通常为几兆字节将其作为SSTable文件写入硬盘。这可以高效地完成因为树已经维护了按键排序的键值对。新的SSTable文件将成为数据库中最新的段。当该SSTable被写入硬盘时新的写入可以在一个新的内存表实例上继续进行。
  • 收到读取请求时,首先尝试在内存表中找到对应的键,如果没有就在最近的硬盘段中寻找,如果还没有就在下一个较旧的段中继续寻找,以此类推。
  • 时不时地,在后台运行一个合并和压缩过程,以合并段文件并将已覆盖或已删除的值丢弃掉。

这个方案效果很好。它只会遇到一个问题如果数据库崩溃则最近的写入在内存表中但尚未写入硬盘将丢失。为了避免这个问题我们可以在硬盘上保存一个单独的日志每个写入都会立即被追加到这个日志上就像在前面的章节中所描述的那样。这个日志没有按排序顺序但这并不重要因为它的唯一目的是在崩溃后恢复内存表。每当内存表写出到SSTable时相应的日志都可以被丢弃。

用SSTables制作LSM树

这里描述的算法本质上是LevelDB【6】和RocksDB【7】这些键值存储引擎库所使用的技术这些存储引擎被设计嵌入到其他应用程序中。除此之外LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中也使用了类似的存储引擎【8】而且他们都受到了Google的Bigtable论文【9】引入了术语 SSTable 和 memtable )的启发。

最初这种索引结构是由Patrick O'Neil等人描述的且被命名为日志结构合并树或LSM树【10】它是基于更早之前的日志结构文件系统【11】来构建的。基于这种合并和压缩排序文件原理的存储引擎通常被称为LSM存储引擎。

Lucene是Elasticsearch和Solr使用的一种全文搜索的索引引擎它使用类似的方法来存储它的关键词词典【12,13】。全文索引比键值索引复杂得多但是基于类似的想法在搜索查询中给出一个单词找到提及单词的所有文档网页产品描述等。这是通过键值结构实现的其中键是单词关键词term值是所有包含该单词的文档的ID列表记录列表。在Lucene中从术语到记录列表的这种映射保存在类似于SSTable的有序文件中并根据需要在后台合并【14】。

性能优化

与往常一样要让存储引擎在实践中表现良好涉及到大量设计细节。例如当查找数据库中不存在的键时LSM树算法可能会很慢你必须先检查内存表然后查看从最近的到最旧的所有的段可能还必须从硬盘读取每一个段文件然后才能确定这个键不存在。为了优化这种访问存储引擎通常使用额外的布隆过滤器Bloom filters【15】。 (布隆过滤器是用于近似集合内容的高效内存数据结构,它可以告诉你数据库中是不是不存在某个键,从而为不存在的键节省掉许多不必要的硬盘读取操作。)

还有一些不同的策略来确定SSTables被压缩和合并的顺序和时间。最常见的选择是size-tiered和leveled compaction。LevelDB和RocksDB使用leveled compactionLevelDB因此得名HBase使用size-tieredCassandra同时支持这两种【16】。对于sized-tiered较新和较小的SSTables相继被合并到较旧的和较大的SSTable中。对于leveled compactionkey范围被拆分到较小的SSTables而较旧的数据被移动到单独的层级level这使得压缩compaction能够更加增量地进行并且使用较少的硬盘空间。

即使有许多微妙的东西LSM树的基本思想 —— 保存一系列在后台合并的SSTables —— 简单而有效。即使数据集比可用内存大得多它仍能继续正常工作。由于数据按排序顺序存储你可以高效地执行范围查询扫描所有从某个最小值到某个最大值之间的所有键并且因为硬盘写入是连续的所以LSM树可以支持非常高的写入吞吐量。

B树

前面讨论的日志结构索引正处在逐渐被接受的阶段但它们并不是最常见的索引类型。使用最广泛的索引结构和日志结构索引相当不同它就是我们接下来要讨论的B树。

从1970年被引入【17】仅不到10年后就变得“无处不在”【18】B树很好地经受了时间的考验。在几乎所有的关系数据库中它们仍然是标准的索引实现许多非关系数据库也会使用到B树。

像SSTables一样B树保持按键排序的键值对这允许高效的键值查找和范围查询。但这也就是所有的相似之处了B树有着非常不同的设计理念。

我们前面看到的日志结构索引将数据库分解为可变大小的段通常是几兆字节或更大的大小并且总是按顺序写入段。相比之下B树将数据库分解成固定大小的块block或页面page传统上大小为4KB有时会更大并且一次只能读取或写入一个页面。这种设计更接近于底层硬件因为硬盘空间也是按固定大小的块来组织的。

每个页面都可以使用地址或位置来标识,这允许一个页面引用另一个页面 —— 类似于指针,但在硬盘而不是在内存中。我们可以使用这些页面引用来构建一个页面树,如图3-6所示。

图3-6 使用B树索引查找一个键

一个页面会被指定为B树的根在索引中查找一个键时就从这里开始。该页面包含几个键和对子页面的引用。每个子页面负责一段连续范围的键引用之间的键指明了引用子页面的键范围。

图3-6的例子中我们正在寻找键251 所以我们知道我们需要跟踪边界200和300之间的页面引用。这将我们带到一个类似的页面进一步将200到300的范围拆分到子范围。

最终我们将到达某个包含单个键的页面叶子页面leaf page该页面或者直接包含每个键的值或者包含了对可以找到值的页面的引用。

在B树的一个页面中对子页面的引用的数量称为分支因子。例如图3-6分支因子是6。在实践中分支因子取决于存储页面引用和范围边界所需的空间量但通常是几百个。

如果要更新B树中现有键的值需要搜索包含该键的叶子页面更改该页面中的值并将该页面写回到硬盘对该页面的任何引用都将保持有效。如果你想添加一个新的键你需要找到其范围能包含新键的页面并将其添加到该页面。如果页面中没有足够的可用空间容纳新键则将其分成两个半满页面并更新父页面以反映新的键范围分区图3-7所示3

图3-7 通过分割页面来生长B树

这个算法可以确保树保持平衡具有n个键的B树总是具有 O(log n) 的深度。大多数数据库可以放入一个三到四层的B树所以你不需要追踪多个页面引用来找到你正在查找的页面。分支因子为500的4KB页面的四层树可以存储多达256TB的数据。

让B树更可靠

B树的基本底层写操作是用新数据覆写硬盘上的页面并假定覆写不改变页面的位置当页面被覆写时对该页面的所有引用保持完整。这与日志结构索引如LSM树形成鲜明对比后者只追加到文件并最终删除过时的文件但从不修改文件中已有的内容。

你可以把覆写硬盘上的页面对应为实际的硬件操作。在磁性硬盘驱动器上这意味着将磁头移动到正确的位置等待旋转盘上的正确位置出现然后用新的数据覆写适当的扇区。在固态硬盘上由于SSD必须一次擦除和重写相当大的存储芯片块所以会发生更复杂的事情【19】。

而且,一些操作需要覆写几个不同的页面。例如,如果因为插入导致页面过满而拆分页面,则需要写入新拆分的两个页面,并覆写其父页面以更新对两个子页面的引用。这是一个危险的操作,因为如果数据库在仅有部分页面被写入时崩溃,那么最终将导致一个损坏的索引(例如,可能有一个孤儿页面不是任何父项的子项) 。

为了使数据库能处理异常崩溃的场景B树实现通常会带有一个额外的硬盘数据结构预写式日志WAL, write-ahead log(也称为重做日志redo log。这是一个仅追加的文件每个B树的修改在其能被应用到树本身的页面之前都必须先写入到该文件。当数据库在崩溃后恢复时这个日志将被用来使B树恢复到一致的状态【5,20】。

另外还有一个更新页面的复杂情况是如果多个线程要同时访问B树则需要仔细的并发控制 —— 否则线程可能会看到树处于不一致的状态。这通常是通过使用锁存器latches(轻量级锁)保护树的数据结构来完成。日志结构化的方法在这方面更简单,因为它们在后台进行所有的合并,而不会干扰新接收到的查询,并且能够时不时地将旧的段原子交换为新的段。

B树的优化

由于B树已经存在了很久所以并不奇怪这么多年下来有很多优化的设计被开发出来仅举几例

  • 一些数据库如LMDB使用写时复制方案【21】而不是覆盖页面并维护WAL以支持崩溃恢复。修改的页面被写入到不同的位置并且还在树中创建了父页面的新版本以指向新的位置。这种方法对于并发控制也很有用我们将在“快照隔离和可重复读”中看到。
  • 我们可以通过不存储整个键,而是缩短其大小,来节省页面空间。特别是在树内部的页面上,键只需要提供足够的信息来充当键范围之间的边界。在页面中包含更多的键允许树具有更高的分支因子,因此也就允许更少的层级4
  • 通常页面可以放置在硬盘上的任何位置没有什么要求相邻键范围的页面也放在硬盘上相邻的区域。如果某个查询需要按照排序顺序扫描大部分的键范围那么这种按页面存储的布局可能会效率低下因为每次页面读取可能都需要进行硬盘查找。因此许多B树的实现在布局树时会尽量使叶子页面按顺序出现在硬盘上。但是随着树的增长要维持这个顺序是很困难的。相比之下由于LSM树在合并过程中一次又一次地重写存储的大部分所以它们更容易使顺序键在硬盘上彼此靠近。
  • 额外的指针已被添加到树中。例如,每个叶子页面可以引用其左边和右边的兄弟页面,使得不用跳回父页面就能按顺序对键进行扫描。
  • B树的变体如分形树fractal tree【22】借用一些日志结构的思想来减少硬盘查找而且它们与分形无关

比较B树和LSM树

尽管B树实现通常比LSM树实现更成熟但LSM树由于其性能特点也非常有趣。根据经验通常LSM树的写入速度更快而B树的读取速度更快【23】。 LSM树上的读取通常比较慢因为它们必须检查几种不同的数据结构和不同压缩Compaction层级的SSTables。

然而,基准测试的结果通常和工作负载的细节相关。你需要用你特有的工作负载来测试系统,以便进行有效的比较。在本节中,我们将简要讨论一些在衡量存储引擎性能时值得考虑的事情。

LSM树的优点

B树索引中的每块数据都必须至少写入两次一次写入预先写入日志WAL一次写入树页面本身如果有分页还需要再写入一次。即使在该页面中只有几个字节发生了变化也需要接受写入整个页面的开销。有些存储引擎甚至会覆写同一个页面两次以免在电源故障的情况下导致页面部分更新【24,25】。

由于反复压缩和合并SSTables日志结构索引也会多次重写数据。这种影响 —— 在数据库的生命周期中每次写入数据库导致对硬盘的多次写入 —— 被称为写放大write amplification。需要特别注意的是固态硬盘,固态硬盘的闪存寿命在覆写有限次数后就会耗尽。

在写入繁重的应用程序中,性能瓶颈可能是数据库可以写入硬盘的速度。在这种情况下,写放大会导致直接的性能代价:存储引擎写入硬盘的次数越多,可用硬盘带宽内它能处理的每秒写入次数就越少。

而且LSM树通常能够比B树支持更高的写入吞吐量部分原因是它们有时具有较低的写放大尽管这取决于存储引擎的配置和工作负载部分是因为它们顺序地写入紧凑的SSTable文件而不是必须覆写树中的几个页面【26】。这种差异在磁性硬盘驱动器上尤其重要其顺序写入比随机写入要快得多。

LSM树可以被压缩得更好因此通常能比B树在硬盘上产生更小的文件。B树存储引擎会由于碎片化fragmentation而留下一些未使用的硬盘空间当页面被拆分或某行不能放入现有页面时页面中的某些空间仍未被使用。由于LSM树不是面向页面的并且会通过定期重写SSTables以去除碎片所以它们具有较低的存储开销特别是当使用分层压缩leveled compaction时【27】。

在许多固态硬盘上固件内部使用了日志结构化算法以将随机写入转变为顺序写入底层存储芯片因此存储引擎写入模式的影响不太明显【19】。但是较低的写入放大率和减少的碎片仍然对固态硬盘更有利更紧凑地表示数据允许在可用的I/O带宽内处理更多的读取和写入请求。

LSM树的缺点

日志结构存储的缺点是压缩过程有时会干扰正在进行的读写操作。尽管存储引擎尝试增量地执行压缩以尽量不影响并发访问,但是硬盘资源有限,所以很容易发生某个请求需要等待硬盘先完成昂贵的压缩操作。对吞吐量和平均响应时间的影响通常很小,但是日志结构化存储引擎在更高百分位的响应时间(请参阅“描述性能有时会相当长而B树的行为则相对更具可预测性【28】。

压缩的另一个问题出现在高写入吞吐量时:硬盘的有限写入带宽需要在初始写入(记录日志和刷新内存表到硬盘)和在后台运行的压缩线程之间共享。写入空数据库时,可以使用全硬盘带宽进行初始写入,但数据库越大,压缩所需的硬盘带宽就越多。

如果写入吞吐量很高并且压缩没有仔细配置好有可能导致压缩跟不上写入速率。在这种情况下硬盘上未合并段的数量不断增加直到硬盘空间用完读取速度也会减慢因为它们需要检查更多的段文件。通常情况下即使压缩无法跟上基于SSTable的存储引擎也不会限制传入写入的速率所以你需要进行明确的监控来检测这种情况【29,30】。

B树的一个优点是每个键只存在于索引中的一个位置而日志结构化的存储引擎可能在不同的段中有相同键的多个副本。这个方面使得B树在想要提供强大的事务语义的数据库中很有吸引力在许多关系数据库中事务隔离是通过在键范围上使用锁来实现的在B树索引中这些锁可以直接附加到树上【5】。在第七章中,我们将更详细地讨论这一点。

B树在数据库架构中是非常根深蒂固的为许多工作负载都提供了始终如一的良好性能所以它们不可能很快就会消失。在新的数据存储中日志结构化索引变得越来越流行。没有快速和容易的规则来确定哪种类型的存储引擎对你的场景更好所以值得去通过一些测试来得到相关的经验。

其他索引结构

到目前为止,我们只讨论了键值索引,它们就像关系模型中的主键primary key 索引。主键唯一标识关系表中的一行或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键或ID引用该行/文档/顶点,索引就被用于解析这样的引用。

次级索引secondary indexes也很常见。在关系数据库中你可以使用 CREATE INDEX 命令在同一个表上创建多个次级索引而且这些索引通常对于有效地执行联接join而言至关重要。例如第二章中的图2-1中,很可能在 user_id 列上有一个次级索引,以便你可以在每个表中找到属于同一用户的所有行。

次级索引可以很容易地从键值索引构建。次级索引主要的不同是键不是唯一的即可能有许多行文档顶点具有相同的键。这可以通过两种方式来解决或者将匹配行标识符的列表作为索引里的值就像全文索引中的记录列表或者通过向每个键添加行标识符来使键唯一。无论哪种方式B树和日志结构索引都可以用作次级索引。

将值存储在索引中

索引中的键是查询要搜索的内容,而其值可以是以下两种情况之一:它可以是实际的行(文档,顶点),也可以是对存储在别处的行的引用。在后一种情况下,行被存储的地方被称为堆文件heap file,并且存储的数据没有特定的顺序(它可以是仅追加的,或者它可以跟踪被删除的行以便后续可以用新的数据进行覆盖)。堆文件方法很常见,因为它避免了在存在多个次级索引时对数据的复制:每个索引只引用堆文件中的一个位置,实际的数据都保存在一个地方。

在不更改键的情况下更新值时堆文件方法可以非常高效只要新值的字节数不大于旧值就可以覆盖该记录。如果新值更大情况会更复杂因为它可能需要移到堆中有足够空间的新位置。在这种情况下要么所有的索引都需要更新以指向记录的新堆位置或者在旧堆位置留下一个转发指针【5】。

在某些情况下从索引到堆文件的额外跳跃对读取来说性能损失太大因此可能希望将被索引的行直接存储在索引中。这被称为聚集索引clustered index。例如在MySQL的InnoDB存储引擎中表的主键总是一个聚集索引次级索引则引用主键而不是堆文件中的位置【31】。在SQL Server中可以为每个表指定一个聚集索引【32】。

聚集索引(在索引中存储所有的行数据)和 非聚集索引(仅在索引中存储对数据的引用)之间的折衷被称为 覆盖索引covering index包含列的索引index with included columns其在索引内存储表的一部分列【33】。这允许通过单独使用索引来处理一些查询这种情况叫做索引 覆盖cover 了查询【32】。

与任何类型的数据重复一样,聚集索引和覆盖索引可以加快读取速度,但是它们需要额外的存储空间,并且会增加写入开销。数据库还需要额外的努力来执行事务保证,因为应用程序不应看到任何因为重复而导致的不一致。

多列索引

至今讨论的索引只是将一个键映射到一个值。如果我们需要同时查询一个表中的多个列(或文档中的多个字段),这显然是不够的。

最常见的多列索引被称为 连接索引concatenated index ,它通过将一列的值追加到另一列后面,简单地将多个字段组合成一个键(索引定义中指定了字段的连接顺序)。这就像一个老式的纸质电话簿,它提供了一个从(姓氏,名字)到电话号码的索引。由于排序顺序,索引可以用来查找所有具有特定姓氏的人,或所有具有特定姓氏-名字组合的人。但如果你想找到所有具有特定名字的人,这个索引是没有用的。

多维索引multi-dimensional index 是一种查询多个列的更一般的方法,这对于地理空间数据尤为重要。例如,餐厅搜索网站可能有一个数据库,其中包含每个餐厅的经度和纬度。当用户在地图上查看餐馆时,网站需要搜索用户正在查看的矩形地图区域内的所有餐馆。这需要一个二维范围查询,如下所示:

SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
                          AND longitude > -0.1162 AND longitude < -0.1004;

一个标准的B树或者LSM树索引不能够高效地处理这种查询它可以返回一个纬度范围内的所有餐馆但经度可能是任意值或者返回在同一个经度范围内的所有餐馆但纬度可能是北极和南极之间的任意地方但不能同时满足两个条件。

一种选择是使用空间填充曲线将二维位置转换为单个数字然后使用常规B树索引【34】。更普遍的是使用特殊化的空间索引例如R树。例如PostGIS使用PostgreSQL的通用GiST工具【35】将地理空间索引实现为R树。这里我们没有足够的地方来描述R树但是有大量的文献可供参考。

有趣的是多维索引不仅可以用于地理位置。例如在电子商务网站上可以使用建立在绿维度上的三维索引来搜索特定颜色范围内的产品也可以在天气观测数据库中建立日期温度的二维索引以便有效地搜索2013年内的温度在25至30°C之间的所有观测资料。如果使用一维索引你将不得不扫描2013年的所有记录不管温度如何然后通过温度进行过滤或者反之亦然。 二维索引可以同时通过时间戳和温度来收窄数据集。这个技术被HyperDex所使用【36】。

全文搜索和模糊索引

到目前为止所讨论的所有索引都假定你有确切的数据,并允许你查询键的确切值或具有排序顺序的键的值范围。他们不允许你做的是搜索类似的键,如拼写错误的单词。这种模糊的查询需要不同的技术。

例如全文搜索引擎通常允许搜索一个单词以扩展为包括该单词的同义词忽略单词的语法变体搜索在相同文档中彼此靠近的单词的出现并且支持各种其他取决于文本的语言分析功能。为了处理文档或查询中的拼写错误Lucene能够在一定的编辑距离编辑距离1意味着添加删除或替换了一个字母内搜索文本【37】。

正如“用SSTables制作LSM树”中所提到的Lucene为其词典使用了一个类似于SSTable的结构。这个结构需要一个小的内存索引告诉查询需要在排序文件中哪个偏移量查找键。在LevelDB中这个内存中的索引是一些键的稀疏集合但在Lucene中内存中的索引是键中字符的有限状态自动机类似于trie 【38】。这个自动机可以转换成Levenshtein自动机它支持在给定的编辑距离内有效地搜索单词【39】。

其他的模糊搜索技术正朝着文档分类和机器学习的方向发展。更多详细信息请参阅信息检索教科书例如【40】。

在内存中存储一切

本章到目前为止讨论的数据结构都是对硬盘限制的应对。与主内存相比硬盘处理起来很麻烦。对于磁性硬盘和固态硬盘如果要在读取和写入时获得良好性能则需要仔细地布置硬盘上的数据。但是我们能容忍这种麻烦因为硬盘有两个显著的优点它们是持久的它们的内容在电源关闭时不会丢失并且每GB的成本比RAM低。

随着RAM变得更便宜每GB成本的论据被侵蚀了。许多数据集不是那么大所以将它们全部保存在内存中是非常可行的包括可能分布在多个机器上。这导致了内存数据库的发展。

某些内存中的键值存储如Memcached仅用于缓存在重新启动计算机时丢失的数据是可以接受的。但其他内存数据库的目标是持久性可以通过特殊的硬件例如电池供电的RAM来实现也可以将更改日志写入硬盘还可以将定时快照写入硬盘或者将内存中的状态复制到其他机器上。

内存数据库重新启动时,需要从硬盘或通过网络从副本重新加载其状态(除非使用特殊的硬件)。尽管写入硬盘,它仍然是一个内存数据库,因为硬盘仅出于持久性目的进行日志追加,读取请求完全由内存来处理。写入硬盘同时还有运维上的好外:硬盘上的文件可以很容易地由外部实用程序进行备份、检查和分析。

诸如VoltDB、MemSQL和Oracle TimesTen等产品是具有关系模型的内存数据库供应商声称通过消除与管理硬盘上的数据结构相关的所有开销他们可以提供巨大的性能改进【41,42】。 RAM Cloud是一个开源的内存键值存储器具有持久性对内存和硬盘上的数据都使用日志结构化方法【43】。 Redis和Couchbase通过异步写入硬盘提供了较弱的持久性。

反直觉的是内存数据库的性能优势并不是因为它们不需要从硬盘读取的事实。只要有足够的内存即使是基于硬盘的存储引擎也可能永远不需要从硬盘读取因为操作系统在内存中缓存了最近使用的硬盘块。相反它们更快的原因在于省去了将内存数据结构编码为硬盘数据结构的开销【44】。

除了性能内存数据库的另一个有趣的地方是提供了难以用基于硬盘的索引实现的数据模型。例如Redis为各种数据结构如优先级队列和集合提供了类似数据库的接口。因为它将所有数据保存在内存中所以它的实现相对简单。

最近的研究表明内存数据库体系结构可以扩展到支持比可用内存更大的数据集而不必重新采用以硬盘为中心的体系结构【45】。所谓的 反缓存anti-caching 方法通过在内存不足的情况下将最近最少使用的数据从内存转移到硬盘并在将来再次访问时将其重新加载到内存中。这与操作系统对虚拟内存和交换文件的操作类似但数据库可以比操作系统更有效地管理内存因为它可以按单个记录的粒度工作而不是整个内存页面。尽管如此这种方法仍然需要索引能完全放入内存中就像本章开头的Bitcask例子

如果 非易失性存储器non-volatile memory, NVM 技术得到更广泛的应用可能还需要进一步改变存储引擎设计【46】。目前这是一个新的研究领域值得关注。

事务处理还是分析?

在早期的业务数据处理过程中,一次典型的数据库写入通常与一笔 商业交易commercial transaction 相对应:卖个货,向供应商下订单,支付员工工资等等。但随着数据库开始应用到那些不涉及到钱的领域,术语交易/事务transaction 仍留了下来,用于指代一组读写操作构成的逻辑单元。

事务不一定具有ACID原子性一致性隔离性和持久性属性。事务处理只是意味着允许客户端进行低延迟的读取和写入 —— 而不是只能定期运行(例如每天一次)的批处理作业。我们在第七章中讨论ACID属性第十章中讨论批处理。

即使数据库开始被用于许多不同类型的数据,比如博客文章的评论,游戏中的动作,地址簿中的联系人等等,基本的访问模式仍然类似于处理商业交易。应用程序通常使用索引通过某个键查找少量记录。根据用户的输入插入或更新记录。由于这些应用程序是交互式的,这种访问模式被称为在线事务处理OLTP, OnLine Transaction Processing

但是,数据库也开始越来越多地用于数据分析,这些数据分析具有非常不同的访问模式。通常,分析查询需要扫描大量记录,每个记录只读取几列,并计算汇总统计信息(如计数、总和或平均值),而不是将原始数据返回给用户。例如,如果你的数据是一个销售交易表,那么分析查询可能是:

  • 一月份每个商店的总收入是多少?
  • 在最近的推广活动中多卖了多少香蕉?
  • 哪个牌子的婴儿食品最常与X品牌的尿布同时购买

这些查询通常由业务分析师编写,并提供报告以帮助公司管理层做出更好的决策(商业智能)。为了将这种使用数据库的模式和事务处理区分开,它被称为在线分析处理OLAP, OnLine Analytice Processing【47】5。OLTP和OLAP之间的区别并不总是清晰的但是一些典型的特征在表3-1中列出。

表3-1 比较事务处理和分析系统的特点

属性 事务处理系统 OLTP 分析系统 OLAP
主要读取模式 查询少量记录,按键读取 在大批量记录上聚合
主要写入模式 随机访问,写入要求低延时 批量导入ETL或者事件流
主要用户 终端用户通过Web应用 内部数据分析师,用于决策支持
处理的数据 数据的最新状态(当前时间点) 随时间推移的历史事件
数据集尺寸 GB ~ TB TB ~ PB

起初,事务处理和分析查询使用了相同的数据库。 SQL在这方面已证明是非常灵活的对于OLTP类型的查询以及OLAP类型的查询来说效果都很好。尽管如此在二十世纪八十年代末和九十年代初期企业有停止使用OLTP系统进行分析的趋势转而在单独的数据库上运行分析。这个单独的数据库被称为数据仓库data warehouse

数据仓库

一个企业可能有几十个不同的交易处理系统:面向终端客户的网站,控制实体商店的收银系统,仓库库存跟踪,车辆路线规划,供应链管理,员工管理等。这些系统中每一个都很复杂,需要专人维护,所以最终这些系统互相之间都是独立运行的。

这些OLTP系统往往对业务运作至关重要因而通常会要求 高可用低延迟。所以DBA会密切关注他们的OLTP数据库他们通常不愿意让业务分析人员在OLTP数据库上运行临时的分析查询因为这些查询通常开销巨大会扫描大部分数据集这会损害同时在执行的事务的性能。

相比之下数据仓库是一个独立的数据库分析人员可以查询他们想要的内容而不影响OLTP操作【48】。数据仓库包含公司各种OLTP系统中所有的只读数据副本。从OLTP数据库中提取数据使用定期的数据转储或连续的更新流转换成适合分析的模式清理并加载到数据仓库中。将数据存入仓库的过程称为“抽取-转换-加载ETL”,如图3-8所示。

图3-8 ETL至数据仓库的简化提纲

几乎所有的大型企业都有数据仓库但在小型企业中几乎闻所未闻。这可能是因为大多数小公司没有这么多不同的OLTP系统大多数小公司只有少量的数据 —— 可以在传统的SQL数据库中查询甚至可以在电子表格中分析。在一家大公司里要做一些在一家小公司很简单的事情需要很多繁重的工作。

使用单独的数据仓库而不是直接查询OLTP系统进行分析的一大优势是数据仓库可针对分析访问模式进行优化。事实证明本章前半部分讨论的索引算法对于OLTP来说工作得很好但对于处理分析查询并不是很好。在本章的其余部分中我们将研究为分析而优化的存储引擎。

OLTP数据库和数据仓库之间的分歧

数据仓库的数据模型通常是关系型的因为SQL通常很适合分析查询。有许多图形数据分析工具可以生成SQL查询可视化结果并允许分析人员探索数据通过下钻、切片和切块等操作

表面上一个数据仓库和一个关系型OLTP数据库看起来很相似因为它们都有一个SQL查询接口。然而系统的内部看起来可能完全不同因为它们针对非常不同的查询模式进行了优化。现在许多数据库供应商都只是重点支持事务处理负载和分析工作负载这两者中的一个而不是都支持。

一些数据库例如Microsoft SQL Server和SAP HANA支持在同一产品中进行事务处理和数据仓库。但是它们也正日益成为两个独立的存储和查询引擎只是这些引擎正好可以通过一个通用的SQL接口访问【49,50,51】。

Teradata、Vertica、SAP HANA和ParAccel等数据仓库供应商通常使用昂贵的商业许可证销售他们的系统。 Amazon RedShift是ParAccel的托管版本。最近大量的开源SQL-on-Hadoop项目已经出现它们还很年轻但是正在与商业数据仓库系统竞争包括Apache Hive、Spark SQL、Cloudera Impala、Facebook Presto、Apache Tajo和Apache Drill【52,53】。其中一些基于了谷歌Dremel的想法【54】。

星型和雪花型:分析的模式

正如第二章所探讨的根据应用程序的需要在事务处理领域中使用了大量不同的数据模型。另一方面在分析型业务中数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用被称为星型模式也称为维度建模【55】

图3-9中的示例模式显示了可能在食品零售商处找到的数据仓库。在模式的中心是一个所谓的事实表(在这个例子中,它被称为 fact_sales)。事实表的每一行代表在特定时间发生的事件(这里,每一行代表客户购买的产品)。如果我们分析的是网站流量而不是零售量,则每行可能代表一个用户的页面浏览或点击。

图3-9 用于数据仓库的星型模式的示例

通常情况下事实被视为单独的事件因为这样可以在以后分析中获得最大的灵活性。但是这意味着事实表可以变得非常大。像苹果沃尔玛或eBay这样的大企业在其数据仓库中可能有几十PB的交易历史其中大部分保存在事实表中【56】。

事实表中的一些列是属性,例如产品销售的价格和从供应商那里购买的成本(可以用来计算利润余额)。事实表中的其他列是对其他表(称为维度表)的外键引用。由于事实表中的每一行都表示一个事件,因此这些维度代表事件发生的对象、内容、地点、时间、方式和原因。

例如,在图3-9中,其中一个维度是已售出的产品。 dim_product 表中的每一行代表一种待售产品包括库存单位SKU、产品描述、品牌名称、类别、脂肪含量、包装尺寸等。fact_sales 表中的每一行都使用外键表明在特定交易中销售了什么产品。 (简单起见,如果客户一次购买了几种不同的产品,则它们在事实表中被表示为单独的行)。

甚至日期和时间也通常使用维度表来表示,因为这允许对日期的附加信息(诸如公共假期)进行编码,从而允许区分假期和非假期的销售查询。

“星型模式”这个名字来源于这样一个事实,即当我们对表之间的关系进行可视化时,事实表在中间,被维度表包围;与这些表的连接就像星星的光芒。

这个模板的变体被称为雪花模式,其中维度被进一步分解为子维度。例如,品牌和产品类别可能有单独的表格,并且 dim_product 表格中的每一行都可以将品牌和类别作为外键引用,而不是将它们作为字符串存储在 dim_product 表格中。雪花模式比星形模式更规范化但是星形模式通常是首选因为分析师使用它更简单【55】。

在典型的数据仓库中表格通常非常宽事实表通常有100列以上有时甚至有数百列【51】。维度表也可以是非常宽的因为它们包括了所有可能与分析相关的元数据——例如dim_store 表可以包括在每个商店提供哪些服务的细节,它是否具有店内面包房,店面面积,商店第一次开张的日期,最近一次改造的时间,离最近的高速公路的距离等等。

列式存储

如果事实表中有万亿行和数PB的数据那么高效地存储和查询它们就成为一个具有挑战性的问题。维度表通常要小得多数百万行所以在本节中我们将主要关注事实表的存储。

尽管事实表通常超过100列但典型的数据仓库查询一次只会访问其中4个或5个列SELECT * ” 查询很少用于分析【51】。以例3-1中的查询为例它访问了大量的行在2013日历年中每次都有人购买水果或糖果但只需访问fact_sales表的三列:date_key, product_sk, quantity。该查询忽略了所有其他的列。

例3-1 分析人们是否更倾向于在一周的某一天购买新鲜水果或糖果

SELECT
  dim_date.weekday,
  dim_product.category,
  SUM(fact_sales.quantity) AS quantity_sold
FROM fact_sales
  JOIN dim_date ON fact_sales.date_key = dim_date.date_key
  JOIN dim_product ON fact_sales.product_sk = dim_product.product_sk
WHERE
  dim_date.year = 2013 AND
  dim_product.category IN ('Fresh fruit', 'Candy')
GROUP BY
  dim_date.weekday, dim_product.category;

我们如何有效地执行这个查询?

在大多数OLTP数据库中存储都是以面向行的方式进行布局的表格的一行中的所有值都相邻存储。文档数据库也是相似的整个文档通常存储为一个连续的字节序列。你可以在图3-1的CSV例子中看到这个。

为了处理像例3-1这样的查询,你可能在 fact_sales.date_keyfact_sales.product_sk上有索引它们告诉存储引擎在哪里查找特定日期或特定产品的所有销售情况。但是面向行的存储引擎仍然需要将所有这些行每个包含超过100个属性从硬盘加载到内存中解析它们并过滤掉那些不符合要求的属性。这可能需要很长时间。

列式存储背后的想法很简单:不要将所有来自一行的值存储在一起,而是将来自每一列的所有值存储在一起。如果每个列式存储在一个单独的文件中,查询只需要读取和解析查询中使用的那些列,这可以节省大量的工作。这个原理如图3-10所示。

图3-10 按列存储关系型数据,而不是行

列式存储在关系数据模型中是最容易理解的但它同样适用于非关系数据。例如Parquet【57】是一种列式存储格式支持基于Google的Dremel的文档数据模型【54】。

列式存储布局依赖于每个列文件包含相同顺序的行。 因此如果你需要重新组装完整的行你可以从每个单独的列文件中获取第23项并将它们放在一起形成表的第23行。

列压缩

除了仅从硬盘加载查询所需的列以外,我们还可以通过压缩数据来进一步降低对硬盘吞吐量的需求。幸运的是,列式存储通常很适合压缩。

看看图3-10中每一列的值序列:它们通常看起来是相当重复的,这是压缩的好兆头。根据列中的数据,可以使用不同的压缩技术。在数据仓库中特别有效的一种技术是位图编码,如图3-11所示。

图3-11 压缩的位图索引存储布局

通常情况下一列中不同值的数量与行数相比要小得多例如零售商可能有数十亿的销售交易但只有100,000个不同的产品。现在我们可以拿一个有 n 个不同值的列,并把它转换成 n 个独立的位图每个不同值对应一个位图每行对应一个比特位。如果该行具有该值则该位为1否则为0。

如果n非常小例如国家/地区列可能有大约200个不同的值则这些位图可以将每行存储成一个比特位。但是如果n更大大部分位图中将会有很多的零我们说它们是稀疏的。在这种情况下位图可以另外再进行游程编码图3-11底部所示。这可以使列的编码非常紧凑。

这些位图索引非常适合数据仓库中常见的各种查询。例如:

WHERE product_sk IN306869

加载product_sk = 30product_sk = 68product_sk = 69这三个位图并计算三个位图的按位或OR这可以非常有效地完成。

WHERE product_sk = 31 AND store_sk = 3

加载product_sk = 31store_sk = 3的位图并计算按位与AND。这是因为列按照相同的顺序包含行因此一列的位图中的第k位和另一列的位图中的第k位对应相同的行。

对于不同种类的数据也有各种不同的压缩方案但我们不会详细讨论它们请参阅【58】的概述。

列式存储和列族

Cassandra和HBase有一个列族column families的概念他们从Bigtable继承【9】。然而把它们称为列式column-oriented是非常具有误导性的在每个列族中它们将一行中的所有列与行键一起存储并且不使用列压缩。因此Bigtable模型仍然主要是面向行的。

内存带宽和矢量化处理

对于需要扫描数百万行的数据仓库查询来说一个巨大的瓶颈是从硬盘获取数据到内存的带宽。但是这不是唯一的瓶颈。分析型数据库的开发人员还需要有效地利用主存储器到CPU缓存的带宽避免CPU指令处理流水线中的分支预测错误和气泡以及在现代CPU上使用单指令多数据SIMD指令【59,60】。

除了减少需要从硬盘加载的数据量以外列式存储布局也可以有效利用CPU周期。例如查询引擎可以将大量压缩的列数据放在CPU的L1缓存中然后在紧密的循环即没有函数调用中遍历。相比较每个记录的处理都需要大量函数调用和条件判断的代码CPU执行这样一个循环要快得多。列压缩允许列中的更多行被放进相同数量的L1缓存。前面描述的按位“与”和“或”运算符可以被设计为直接在这样的压缩列数据块上操作。这种技术被称为矢量化处理【58,49】。

列式存储中的排序顺序

在列式存储中存储行的顺序并不一定很重要。按插入顺序存储它们是最简单的因为插入一个新行只需要追加到每个列文件。但是我们可以选择增加一个特定的顺序就像我们之前对SSTables所做的那样并将其用作索引机制。

注意每列独自排序是没有意义的因为那样我们就没法知道不同列中的哪些项属于同一行。我们只能在知道一列中的第k项与另一列中的第k项属于同一行的情况才能重建出完整的行。

相反,即使按列式存储数据,也需要一次对整行进行排序。数据库的管理员可以根据他们对常用查询的了解来选择表格应该被排序的列。例如,如果查询通常以日期范围为目标,例如上个月,则可以将 date_key 作为第一个排序键。这样查询优化器就可以只扫描上个月的行了,这比扫描所有行要快得多。

对于第一排序列中具有相同值的行,可以用第二排序列来进一步排序。例如,如果 date_key图3-10中的第一个排序关键字,那么 product_sk 可能是第二个排序关键字,以便同一天的同一产品的所有销售都将在存储中组合在一起。这将有助于需要在特定日期范围内按产品对销售进行分组或过滤的查询。

排序顺序的另一个好处是它可以帮助压缩列。如果主要排序列没有太多个不同的值,那么在排序之后,它将具有很长的序列,其中相同的值连续重复多次。一个简单的游程编码(就像我们用于图3-11中的位图一样)可以将该列压缩到几千字节 —— 即使表中有数十亿行。

第一个排序键的压缩效果最强。第二和第三个排序键会更混乱,因此不会有这么长的连续的重复值。排序优先级更低的列以基本上随机的顺序出现,所以它们可能不会被压缩。但前几列排序在整体上仍然是有好处的。

几个不同的排序顺序

C-Store中引入了这个想法的一个巧妙扩展并在商业数据仓库Vertica中被采用【61,62】。不同的查询受益于不同的排序顺序为什么不以几种不同的方式来存储相同的数据呢无论如何数据需要复制到多台机器这样如果一台机器发生故障你不会丢失数据。你可能还需要存储以不同方式排序的冗余数据以便在处理查询时可以使用最适合查询模式的版本。

在一个列式存储中有多个排序顺序有点类似于在一个面向行的存储中有多个次级索引。但最大的区别在于面向行的存储将每一行保存在一个地方(在堆文件或聚集索引中),次级索引只包含指向匹配行的指针。在列式存储中,通常在其他地方没有任何指向数据的指针,只有包含值的列。

写入列式存储

这些优化在数据仓库中是有意义的,因为其负载主要由分析人员运行的大型只读查询组成。列式存储、压缩和排序都有助于更快地读取这些查询。然而,他们的缺点是写入更加困难。

使用B树的就地更新方法对于压缩的列是不可能的。如果你想在排序表的中间插入一行你很可能不得不重写所有的列文件。由于行由列中的位置标识因此插入必须对所有列进行一致地更新。

幸运的是本章前面已经看到了一个很好的解决方案LSM树。所有的写操作首先进入一个内存中的存储在这里它们被添加到一个已排序的结构中并准备写入硬盘。内存中的存储是面向行还是列的并不重要。当已经积累了足够的写入数据时它们将与硬盘上的列文件合并并批量写入新文件。这基本上是Vertica所做的【62】。

查询需要检查硬盘上的列数据和最近在内存中的写入,并将两者结合起来。但是,查询优化器对用户隐藏了这个细节。从分析师的角度来看,通过插入、更新或删除操作进行修改的数据会立即反映在后续的查询中。

聚合:数据立方体和物化视图

并不是每个数据仓库都必定是一个列式存储传统的面向行的数据库和其他一些架构也被使用。然而列式存储可以显著加快专门的分析查询所以它正在迅速变得流行起来【51,63】。

数据仓库的另一个值得一提的方面是物化汇总materialized aggregates。如前所述数据仓库查询通常涉及一个聚合函数如SQL中的COUNT、SUM、AVG、MIN或MAX。如果相同的聚合被许多不同的查询使用那么每次都通过原始数据来处理可能太浪费了。为什么不将一些查询使用最频繁的计数或总和缓存起来

创建这种缓存的一种方式是物化视图Materialized View。在关系数据模型中它通常被定义为一个标准虚拟视图一个类似于表的对象其内容是一些查询的结果。不同的是物化视图是查询结果的实际副本会被写入硬盘而虚拟视图只是编写查询的一个捷径。从虚拟视图读取时SQL引擎会将其展开到视图的底层查询中然后再处理展开的查询。

当底层数据发生变化时物化视图需要更新因为它是数据的非规范化副本。数据库可以自动完成该操作但是这样的更新使得写入成本更高这就是在OLTP数据库中不经常使用物化视图的原因。在读取繁重的数据仓库中它们可能更有意义它们是否实际上改善了读取性能取决于个别情况

物化视图的常见特例称为数据立方体或OLAP立方【64】。它是按不同维度分组的聚合网格。图3-12显示了一个例子。

图3-12 数据立方的两个维度,通过求和聚合

想象一下,现在每个事实都只有两个维度表的外键 —— 在图3-12中分别是日期和产品。你现在可以绘制一个二维表格,一个轴线上是日期,另一个轴线上是产品。每个单元格包含具有该日期-产品组合的所有事实的属性(例如net_price)的聚集(例如SUM)。然后,你可以沿着每行或每列应用相同的汇总,并获得减少了一个维度的汇总(按产品的销售额,无论日期,或者按日期的销售额,无论产品)。

一般来说事实往往有两个以上的维度。在图3-9中有五个维度日期、产品、商店、促销和客户。要想象一个五维超立方体是什么样子是很困难的但是原理是一样的每个单元格都包含特定日期-产品-商店-促销-客户组合的销售额。这些值可以在每个维度上求和汇总。

物化数据立方体的优点是可以让某些查询变得非常快,因为它们已经被有效地预先计算了。例如,如果你想知道每个商店的总销售额,则只需查看合适维度的总计,而无需扫描数百万行的原始数据。

数据立方体的缺点是不具有查询原始数据的灵活性。例如没有办法计算有多少比例的销售来自成本超过100美元的项目因为价格不是其中的一个维度。因此大多数数据仓库试图保留尽可能多的原始数据并将聚合数据如数据立方体仅用作某些查询的性能提升手段。

本章小结

在本章中,我们试图深入了解数据库是如何处理存储和检索的。将数据存储在数据库中会发生什么?稍后再次查询数据时数据库会做什么?

在高层次上,我们看到存储引擎分为两大类:针对事务处理OLTP 优化的存储引擎和针对在线分析OLAP 优化的存储引擎。这两类使用场景的访问模式之间有很大的区别:

  • OLTP系统通常面向最终用户这意味着系统可能会收到大量的请求。为了处理负载应用程序在每个查询中通常只访问少量的记录。应用程序使用某种键来请求记录存储引擎使用索引来查找所请求的键的数据。硬盘查找时间往往是这里的瓶颈。
  • 数据仓库和类似的分析系统会低调一些因为它们主要由业务分析人员使用而不是最终用户。它们的查询量要比OLTP系统少得多但通常每个查询开销高昂需要在短时间内扫描数百万条记录。硬盘带宽而不是查找时间往往是瓶颈列式存储是针对这种工作负载的日益流行的解决方案。

在OLTP这一边我们能看到两派主流的存储引擎

  • 日志结构学派只允许追加到文件和删除过时的文件但不会更新已经写入的文件。Bitcask、SSTables、LSM树、LevelDB、Cassandra、HBase、Lucene等都属于这个类别。
  • 就地更新学派:将硬盘视为一组可以覆写的固定大小的页面。 B树是这种理念的典范用在所有主要的关系数据库和许多非关系型数据库中。

日志结构的存储引擎是相对较新的技术。他们的主要想法是,通过系统性地将随机访问写入转换为硬盘上的顺序写入,由于硬盘驱动器和固态硬盘的性能特点,可以实现更高的写入吞吐量。

关于OLTP我们最后还介绍了一些更复杂的索引结构以及针对所有数据都放在内存里而优化的数据库。

然后我们暂时放下了存储引擎的内部细节查看了典型数据仓库的高级架构并说明了为什么分析工作负载与OLTP差别很大当你的查询需要在大量行中顺序扫描时索引的重要性就会降低很多。相反非常紧凑地编码数据变得非常重要以最大限度地减少查询需要从硬盘读取的数据量。我们讨论了列式存储如何帮助实现这一目标。

作为一名应用程序开发人员,如果你掌握了有关存储引擎内部的知识,那么你就能更好地了解哪种工具最适合你的特定应用程序。如果你需要调整数据库的调整参数,这种理解可以让你设想一个更高或更低的值可能会产生什么效果。

尽管本章不能让你成为一个特定存储引擎的调参专家,但它至少大概率使你有了足够的概念与词汇储备去读懂你所选择的数据库的文档。

参考文献

  1. Alfred V. Aho, John E. Hopcroft, and Jeffrey D. Ullman: Data Structures and Algorithms. Addison-Wesley, 1983. ISBN: 978-0-201-00023-8
  2. Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein: Introduction to Algorithms, 3rd edition. MIT Press, 2009. ISBN: 978-0-262-53305-8
  3. Justin Sheehy and David Smith: “Bitcask: A Log-Structured Hash Table for Fast Key/Value Data,” Basho Technologies, April 2010.
  4. Yinan Li, Bingsheng He, Robin Jun Yang, et al.: “Tree Indexing on Solid State Drives,” Proceedings of the VLDB Endowment, volume 3, number 1, pages 11951206, September 2010.
  5. Goetz Graefe: “Modern B-Tree Techniques,” Foundations and Trends in Databases, volume 3, number 4, pages 203402, August 2011. doi:10.1561/1900000028
  6. Jeffrey Dean and Sanjay Ghemawat: “LevelDB Implementation Notes,” leveldb.googlecode.com.
  7. Dhruba Borthakur: “The History of RocksDB,” rocksdb.blogspot.com, November 24, 2013.
  8. Matteo Bertozzi: “Apache HBase I/O HFile,” blog.cloudera.com, June, 29 2012.
  9. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, et al.: “Bigtable: A Distributed Storage System for Structured Data,” at 7th USENIX Symposium on Operating System Design and Implementation (OSDI), November 2006.
  10. Patrick O'Neil, Edward Cheng, Dieter Gawlick, and Elizabeth O'Neil: “The Log-Structured Merge-Tree (LSM-Tree),” Acta Informatica, volume 33, number 4, pages 351385, June 1996. doi:10.1007/s002360050048
  11. Mendel Rosenblum and John K. Ousterhout: “The Design and Implementation of a Log-Structured File System,” ACM Transactions on Computer Systems, volume 10, number 1, pages 2652, February 1992. doi:10.1145/146941.146943
  12. Adrien Grand: “What Is in a Lucene Index?,” at Lucene/Solr Revolution, November 14, 2013.
  13. Deepak Kandepet: “Hacking Lucene—The Index Format,” hackerlabs.org, October 1, 2011.
  14. Michael McCandless: “Visualizing Lucene's Segment Merges,” blog.mikemccandless.com, February 11, 2011.
  15. Burton H. Bloom: “Space/Time Trade-offs in Hash Coding with Allowable Errors,” Communications of the ACM, volume 13, number 7, pages 422426, July 1970. doi:10.1145/362686.362692
  16. Operating Cassandra: Compaction,” Apache Cassandra Documentation v4.0, 2016.
  17. Rudolf Bayer and Edward M. McCreight: “Organization and Maintenance of Large Ordered Indices,” Boeing Scientific Research Laboratories, Mathematical and Information Sciences Laboratory, report no. 20, July 1970.
  18. Douglas Comer: “The Ubiquitous B-Tree,” ACM Computing Surveys, volume 11, number 2, pages 121137, June 1979. doi:10.1145/356770.356776
  19. Emmanuel Goossaert: “Coding for SSDs,” codecapsule.com, February 12, 2014.
  20. C. Mohan and Frank Levine: “ARIES/IM: An Efficient and High Concurrency Index Management Method Using Write-Ahead Logging,” at ACM International Conference on Management of Data (SIGMOD), June 1992. doi:10.1145/130283.130338
  21. Howard Chu: “LDAP at Lightning Speed,” at Build Stuff '14, November 2014.
  22. Bradley C. Kuszmaul: “A Comparison of Fractal Trees to Log-Structured Merge (LSM) Trees,” tokutek.com, April 22, 2014.
  23. Manos Athanassoulis, Michael S. Kester, Lukas M. Maas, et al.: “Designing Access Methods: The RUM Conjecture,” at 19th International Conference on Extending Database Technology (EDBT), March 2016. doi:10.5441/002/edbt.2016.42
  24. Peter Zaitsev: “Innodb Double Write,” percona.com, August 4, 2006.
  25. Tomas Vondra: “On the Impact of Full-Page Writes,” blog.2ndquadrant.com, November 23, 2016.
  26. Mark Callaghan: “The Advantages of an LSM vs a B-Tree,” smalldatum.blogspot.co.uk, January 19, 2016.
  27. Mark Callaghan: “Choosing Between Efficiency and Performance with RocksDB,” at Code Mesh, November 4, 2016.
  28. Michi Mutsuzaki: “MySQL vs. LevelDB,” github.com, August 2011.
  29. Benjamin Coverston, Jonathan Ellis, et al.: “CASSANDRA-1608: Redesigned Compaction, issues.apache.org, July 2011.
  30. Igor Canadi, Siying Dong, and Mark Callaghan: “RocksDB Tuning Guide,” github.com, 2016.
  31. MySQL 5.7 Reference Manual. Oracle, 2014.
  32. Books Online for SQL Server 2012. Microsoft, 2012.
  33. Joe Webb: “Using Covering Indexes to Improve Query Performance,” simple-talk.com, 29 September 2008.
  34. Frank Ramsak, Volker Markl, Robert Fenk, et al.: “Integrating the UB-Tree into a Database System Kernel,” at 26th International Conference on Very Large Data Bases (VLDB), September 2000.
  35. The PostGIS Development Group: “PostGIS 2.1.2dev Manual,” postgis.net, 2014.
  36. Robert Escriva, Bernard Wong, and Emin Gün Sirer: “HyperDex: A Distributed, Searchable Key-Value Store,” at ACM SIGCOMM Conference, August 2012. doi:10.1145/2377677.2377681
  37. Michael McCandless: “Lucene's FuzzyQuery Is 100 Times Faster in 4.0,” blog.mikemccandless.com, March 24, 2011.
  38. Steffen Heinz, Justin Zobel, and Hugh E. Williams: “Burst Tries: A Fast, Efficient Data Structure for String Keys,” ACM Transactions on Information Systems, volume 20, number 2, pages 192223, April 2002. doi:10.1145/506309.506312
  39. Klaus U. Schulz and Stoyan Mihov: “Fast String Correction with Levenshtein Automata,” International Journal on Document Analysis and Recognition, volume 5, number 1, pages 6785, November 2002. doi:10.1007/s10032-002-0082-8
  40. Christopher D. Manning, Prabhakar Raghavan, and Hinrich Schütze: Introduction to Information Retrieval. Cambridge University Press, 2008. ISBN: 978-0-521-86571-5, available online at nlp.stanford.edu/IR-book
  41. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, et al.: “The End of an Architectural Era (Its Time for a Complete Rewrite),” at 33rd International Conference on Very Large Data Bases (VLDB), September 2007.
  42. VoltDB Technical Overview White Paper,” VoltDB, 2014.
  43. Stephen M. Rumble, Ankita Kejriwal, and John K. Ousterhout: “Log-Structured Memory for DRAM-Based Storage,” at 12th USENIX Conference on File and Storage Technologies (FAST), February 2014.
  44. Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, and Michael Stonebraker: “OLTP Through the Looking Glass, and What We Found There,” at ACM International Conference on Management of Data (SIGMOD), June 2008. doi:10.1145/1376616.1376713
  45. Justin DeBrabant, Andrew Pavlo, Stephen Tu, et al.: “Anti-Caching: A New Approach to Database Management System Architecture,” Proceedings of the VLDB Endowment, volume 6, number 14, pages 19421953, September 2013.
  46. Joy Arulraj, Andrew Pavlo, and Subramanya R. Dulloor: “Let's Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems,” at ACM International Conference on Management of Data (SIGMOD), June 2015. doi:10.1145/2723372.2749441
  47. Edgar F. Codd, S. B. Codd, and C. T. Salley: “Providing OLAP to User-Analysts: An IT Mandate,” E. F. Codd Associates, 1993.
  48. Surajit Chaudhuri and Umeshwar Dayal: “An Overview of Data Warehousing and OLAP Technology,” ACM SIGMOD Record, volume 26, number 1, pages 6574, March 1997. doi:10.1145/248603.248616
  49. Per-Åke Larson, Cipri Clinciu, Campbell Fraser, et al.: “Enhancements to SQL Server Column Stores,” at ACM International Conference on Management of Data (SIGMOD), June 2013.
  50. Franz Färber, Norman May, Wolfgang Lehner, et al.: “The SAP HANA Database An Architecture Overview,” IEEE Data Engineering Bulletin, volume 35, number 1, pages 2833, March 2012.
  51. Michael Stonebraker: “The Traditional RDBMS Wisdom Is (Almost Certainly) All Wrong,” presentation at EPFL, May 2013.
  52. Daniel J. Abadi: “Classifying the SQL-on-Hadoop Solutions,” hadapt.com, October 2, 2013.
  53. Marcel Kornacker, Alexander Behm, Victor Bittorf, et al.: “Impala: A Modern, Open-Source SQL Engine for Hadoop,” at 7th Biennial Conference on Innovative Data Systems Research (CIDR), January 2015.
  54. Sergey Melnik, Andrey Gubarev, Jing Jing Long, et al.: “Dremel: Interactive Analysis of Web-Scale Datasets,” at 36th International Conference on Very Large Data Bases (VLDB), pages 330339, September 2010.
  55. Ralph Kimball and Margy Ross: The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd edition. John Wiley & Sons, July 2013. ISBN: 978-1-118-53080-1
  56. Derrick Harris: “Why Apple, eBay, and Walmart Have Some of the Biggest Data Warehouses Youve Ever Seen,” gigaom.com, March 27, 2013.
  57. Julien Le Dem: “Dremel Made Simple with Parquet,” blog.twitter.com, September 11, 2013.
  58. Daniel J. Abadi, Peter Boncz, Stavros Harizopoulos, et al.: “The Design and Implementation of Modern Column-Oriented Database Systems,” Foundations and Trends in Databases, volume 5, number 3, pages 197280, December 2013. doi:10.1561/1900000024
  59. Peter Boncz, Marcin Zukowski, and Niels Nes: “MonetDB/X100: Hyper-Pipelining Query Execution,” at 2nd Biennial Conference on Innovative Data Systems Research (CIDR), January 2005.
  60. Jingren Zhou and Kenneth A. Ross: “Implementing Database Operations Using SIMD Instructions,” at ACM International Conference on Management of Data (SIGMOD), pages 145156, June 2002. doi:10.1145/564691.564709
  61. Michael Stonebraker, Daniel J. Abadi, Adam Batkin, et al.: “C-Store: A Column-oriented DBMS,” at 31st International Conference on Very Large Data Bases (VLDB), pages 553564, September 2005.
  62. Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan, et al.: “The Vertica Analytic Database: C-Store 7 Years Later,” Proceedings of the VLDB Endowment, volume 5, number 12, pages 17901801, August 2012.
  63. Julien Le Dem and Nong Li: “Efficient Data Storage for Analytics with Apache Parquet 2.0,” at Hadoop Summit, San Jose, June 2014.
  64. Jim Gray, Surajit Chaudhuri, Adam Bosworth, et al.: “Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals,” Data Mining and Knowledge Discovery, volume 1, number 1, pages 2953, March 2007. doi:10.1023/A:1009726021843

上一章 目录 下一章
第二章:数据模型与查询语言 设计数据密集型应用 第四章:编码与演化

  1. 如果所有的键与值都是定长的,你可以使用段文件上的二分查找并完全避免使用内存索引。然而实践中的键和值通常都是变长的,因此如果没有索引,就很难知道记录的分界点(前一条记录结束以及后一条记录开始的地方)。 ↩︎

  2. 这里的压缩是compression不是前文的compaction请注意区分。 ↩︎

  3. 向B树中插入一个新的键是相当符合直觉的但删除一个键同时保持树平衡就会牵扯很多其他东西了【2】。 ↩︎

  4. 这个变种有时被称为B+树但因为这个优化已被广泛使用所以经常无法区分于其它的B树变种。 ↩︎

  5. OLAP中的首字母Oonline的含义并不明确它可能是指查询并不是用来生成预定义好的报告的事实也可能是指分析师通常是交互式地使用OLAP系统来进行探索式的查询。 ↩︎