RocksDB简介
1、RocksDB简介
RocksDB项目起源于Facebook的一个实验项目,该项目旨在开发一个与快速存储器（尤其是闪存）存储数据性能相当的数据库软件，以应对高负载服务。
这是一个c++库,可用于存储键和值,可以是任意大小的字节流。它支持原子读和写。
RocksDB具有高度灵活的配置功能,可以通过配置使其运行在各种各样的生产环境,包括纯内存,Flash,硬盘或HDFS。它支持各种压缩算法，并提供了便捷的生产环境维护和调试工具。
2、假设和目标
性能:
RocksDB的主要设计目标是保证存取快速存储器和高负载服务器更高效，保证充分利用Flash或RAM子系统提供的高速率读写，支持高效的查找和范围scan，支持高负载的随机读、高负载的更新操作或两者的结合。其架构应该支持高并发读写和容量大增时系统的一致性。
向后兼容性:
这个软件的新版本应该是向后兼容的,因此,当升级到新版本时现有的应用程序不需要改变。
3、高级体系结构
RocksDB是一个嵌入式键值存储器，其中键和值是任意的字节流。RocksDB中的所有数据是按序存放的。常见操作包括Get(key), Put(key), Delete(key) and Scan(key)。
RocksDB有三个基本结构：RocksDB memtable,sstfile和logfile。memtable是一个内存数据结构——新数据会插入到memtable和日志文件（可选）。日志文件是顺序写入的，位于磁盘。当memtable写满后,数据会被刷新到磁盘上的sstfile文件，同时相应的日志文件可以安全地删除。sstfile中的数据经过排序的,目的是为了加快键查找。
4、特性
Gets,迭代器和快照
键和值被视为纯字节流，没有大小的限制。
Get接口允许应用程序从数据库中获取一个键值。MultiGet接口允许应用程序从数据库中检索多个键值。MultiGet接口返回的key-value对都是相互匹配的。所有数据库中的数据都按顺序存放。应用程序可以指定一个key比较方法来定义key的排序顺序。迭代器允许应用程序对数据库进行RangeScan。
迭代器可以先定位一个指定的键,然后应用程序就可以从这个定位点开始一个一个扫描key。迭代器还可以用来对key做反向迭代。创建迭代器是会创建当前数据库的一个快照视图，因此,通过迭代器返回的所有键都来自同一个数据库视图。
Snapshot允许应用程序创建一个快照视图。Get和迭代器可以从一个指定的快照读取数据。在某种意义上,Snapshot和迭代器都提供了某个时间点上数据库的快照视图,但两者的实现是不同的。
短暂的扫描最好通过迭代器而耗时较长的扫描最好通过快照。迭代器记录了数据库当前视图对应文件，直到迭代器被释放才删除这些。而快照并不能阻止文件删除;相反,compaction流程知道当前的快照并且不会删除任何现有快照中的key。数据库重启后，快照将丢失。重载RocksDB(通过服务器重启)会释放所有先前的快照。
前缀迭代器
大多数LSM引擎无法支持一个高效RangeScan,因为它需要查找每一个数据文件。但大多数应用程序不会对key进行随机扫描,而更多的是扫描给定前缀的key。
RocksDB利用了这种优势。应用程序可以通过prefix_extractor指定一个key的前缀。RocksDB用此来保存每个key前缀的bloom，指定了前缀(通过ReadOptions)
的迭代器将使用bloom二进制位来避免查找不包含指定key前缀的文件。
更新
Put操作向数据库插入单个key-value。如果键已经存在,旧值将被覆盖。Writer操作允许将多个keys-values原子地插入到数据库中。数据库保证同一个Writer操作
中的所有keys-values要么全部插入，要么都不插入。如果其中任何一个键已经存在于数据库中,旧值将被覆盖。
持久性
Put操作数据会存储在内存中的缓冲区称为memtable，也会选择性地插入到事务日志。每一个Put操作都有一组标志(通过WriteOptions设置),这些标志指定Put操作数据是否应该插入到事务日志。WriteOptions也可以指定在put操作提交前一个同步调用是否写入事务日志。在内部,RocksDB使用batch-commit机制批量写入事务日志,这样它可以使用一个同步调用提交多个事务。
容错
RocksDB使用校验和检测数据是否正确。每个块(通常是4k到128k大小)都有自己的校验和。一块数据一旦写入将不会修改。RocksDB通过硬件支持动态获取校验和的计算结果，以避免需要是自己计算校验和。
多线程Compaction
Compactions可以删除同一key的多个副本,副本是应用程序覆盖现有key是产生的，可以删除key。通过配置可以让Compaction以多线程方式运行。
LSM的写数据的整体吞吐量直接取决于Compaction的速度,特别是当数据存储在SSD或RAM这种存储器中。RocksDB可以处理多个线程并发的Comopaction请求。多线程Compaction场景下写数据的速率比单线程场景下的速率快10倍。
整个数据库存储在一组sstfiles。memtable写满时,它的内容会被写入Level-0层的一个文件中，在此过程中，重复和被覆盖的key会被删除。
一些文件被定期压缩合并形成更大的文件——这就是所谓的compaction。
RocksDB支持两种不同形式的compaction。普遍的做法是将所有文件按时间顺序保存在L0。compaction选择几个彼此相邻的文件并将它们合并成一个新文件L0。所有文件可以有重叠的key。分层形式的compaction将数据存储在数据库中的多个层中。最新的数据存储在L0和最旧的数据存储在Lmax。L0层中的文件可以有重叠的key,但其他层中文件的key不能重叠。一次compaction过程就是选择Ln层的一个文件及它在Ln+1层的所有重叠文件进行压缩合并形成Ln+1层的新文件。相比层形式的compaction方法，普遍的compaction方法写数据性能较低，但空间利用率较高。
MANIFEST文件记录了数据库的状态。compaction在添加新文件和从数据库删除现有的文件后，会将这些操作记录到MANIFEST文件。事务日志是被批量提交到MANIFEST文件中的，目的是为了减少对MANIFEST文件的重复同步访问。
Compaction过滤器
一些应用程序可能需要在Compaction过程中处理某些key。例如,一个支持TTL的数据库可能删除过期的key，这可以通过定义一个Compaction过滤器完成。
如果应用程序想要不断删除旧数据,可以使用Compaction过滤掉丢弃过期的记录。RocksDB Compaction过滤器可以允许应用程序去修改对应key的value或作为Compaction过程的一部分直接丢弃key。
只读的模式
数据库可以在只读的模式下打开。只读模式下应用程序不能修改任何数据。这可以保证更高的读取性能,因为避免了代码执行路径的切换和锁的使用。
数据库调试日志
RocksDB的详细日志被写入到名为LOG*的文件中。这些日志用于调试和分析运行中的系统。可以按配置的指定周期记录日志。
数据压缩
RocksDB支持snappy,zlib,bzip2 lz4和lz4_hc压缩算法。对不同层的数据可以配置不同的压缩算法。一般来说,90%的数据保存在Lmax层。
一个典型的安装可能是L0-L2层不配置压缩算法,中间层用snappy压缩算法，而Lmax层采用zlib压缩。
事务日志
RocksDB将事务日志保存在logfile文件中以防止系统崩溃。系统启动时会重新处理日志文件。logfile和_sstfile_s可以存放在不同目录下，比如下面的场景，
当你希望将所有数据文件存储在非持久但快速的存储设备中，同时把事务日志保存在存取速度慢但持久的存储设备中。
