《数据密集型应用系统设计》笔记三：第三章 数据存储与检索

1. OLTP 与 OLAP

概括来讲，存储引擎分为两大类：针对事务处理（OLTP）优化的架构，以及针对分析（OLAP）优化的架构。他们典型的访问模式存在很大差异：

OLTP系统通常面向用户，这意味着它们可能收到大量的请求。为了处理负载，应用程序通常在每个查询中只涉及少量的记录。应用程序基于某种键来请求记录，而存储引擎使用索引来查找所请求键的数据。磁盘寻道时间往往是瓶颈。

OLAP系统往往并不直接面对最终用户，它们主要由业务分析师来使用。OLAP处理的查询请求数目远低于OLTP系统，但是每个查询通常要求非常苛刻，需要在短时间内扫描数百万条记录（大数据时代，随着数据量的暴增，可能要求更大）。磁盘带宽通常是瓶颈，而面向列的存储对于这种工作负载成为日益流行的解决方案。

2. OLTP系统的存储引擎

在OLTP方面，有两个主要流派的存储引擎：

日志结构流派：它只允许追加式更新文件和删除过时的文件，但不会修改已写入的文件。BitCask、SSTables、LSM-tree、LevelDB、Cassandra、HBase、Lucene等属于此类。日志结构存储引擎是一个相对较新的存储方案，其关键思想是：系统地将磁盘上随机访问写入转为顺序写入，由于磁盘驱动器和SSD的性能特性，可以实现更高的写入吞吐量。

原地更新流派：将磁盘视为可以覆盖一组固定大小的页。B-tree是这一哲学的最典型代表，传统的数据库，无论是关系型还是非关系型，绝大多数都基于此。

下面将分别详解两种存储引擎。在此之前，先让我们了解一下它们赖以存在的基础——key-value存储以及哈希索引。

2.1 键值存储与哈希索引

索引

1. 数据库的核心是数据结构。
2. OLTP系统为了高效地查找数据库特定键的值，需要新的数据结构：索引。
3. 索引是基于原始数据库派生而来的额外数据结构，添加或删除索引不会影响数据库的内容，只会影响查询性能。
4. 索引可以加速读取查询，但是每个索引都会减慢写速度。这涉及一种权衡。

哈希索引

key-value类型并不是唯一可以索引的数据，但它随处可见，是其他更复杂索引的基础构造模块。key-value存储通常采用hash-map（或者hash-table）来实现。

索引策略

假设数据存储全部采用追加式文件组成，以日志文件为例，那么最简单的哈希索引策略是：

（1）保存内存中的hash-map，把每个键一一映射到数据文件中特定的字节偏移量，这样就能很方便的找到每个值的位置。
（2）每当在文件中追加新的key-value对时，则更新hash-map来反映刚刚写入数据的偏移量（包括插入新的键和更新已有的键）
（3）当查找某个值时，使用hash-map来找到文件中的偏移量，即存储位置，然后取其内容。

这就是Bitcask所采用的核心做法。只要所有的key可以放入内存，无论value的数据量有多大，只需一次磁盘寻址，就可以将value从磁盘加载到内存，可以提供高性能的读和写。这种存储引擎非常适合没有太多不同的key，而每个键的值频繁更新的场景，因为在这种场景下，将所有key保存在内存中是可行的。

设计细节

（1）如何避免最终用尽磁盘空间？
将日志分解成一定大小的段，当文件达到一定大小时就关闭它，并将后续写入到新的段文件中。
可以执行段压缩和多个段的合并，压缩合并的段会被写入另一个新文件。在执行压缩合并的过程中，段会被冻结，在后台线程完成压缩合并操作。此时，仍然可以用旧的段文件继续正常读取和写请求。当压缩合并完成后，将读请求切换到新的合并段上，然后旧的段文件可以安全删除。

（2）文件格式
CSV并不是最佳的格式，最快最简单最节省内存的方法是使用二进制格式。

（3）删除记录
如果要删除键和它关联的值，则必须在数据文件中追加一个特殊的删除记录（墓碑）。当合并段时，一旦发现墓碑标记，则会丢弃这个已删除键的所有值。

（4）崩溃恢复
如果数据库重新启动，则内存中的hash-map将丢失。原则上，可以通过从头到尾读取整个段文件，然后记录每个键的最新值的偏移量，来恢复每个段的hash-map。但是，如果分段文件很大，可能扫描需要很长时间，这将使服务器重启变的缓慢。通过将每个段的hash-map的快照存储在磁盘上，可以更快地加载到内存中，从而加快恢复速度。

（5）部分写入的记录