存储引擎

存储引擎位于ArangoDB数据库的最底层。存储引擎负责将文档保存在磁盘上，在内存中保存副本，提供索引和缓存以加快查询速度。

3.1版本之前，ArangoDB仅支持内存映射文件（MMFiles）作为唯一的存储引擎。从3.2之后，ArangoDB开始支持可插拔的存储引擎。第二个支持的引擎是来自Facebook的RocksDB。

RocksDB是一个可嵌入的持久性key-value存储。它是一个日志结构的数据库，并针对快速存储进行了优化。

MMFiles引擎针对数据放入主内存的用例进行了优化。它允许非常快速的并发读取。但是，写操作会阻塞读操作，并且锁定是在集合级别上的。索引始终在内存中，并在启动时重建。这样可以获得更好的性能，但导致启动时间更长。

RocksDB引擎针对大型数据集进行了优化，即使数据集比主内存大得多，也可以确保稳定的插入性能。索引始终存储在磁盘上，但缓存用于加速性能。RocksDB使用文档级别的锁来允许并发写入。写入不会阻止读取。读取不会阻止写入。

必须为整个服务器/集群选择引擎，不可以混合使用。事务处理和预写日志格式在各个引擎中是不同的，因此不能混合使用。

RocksDB

RocksDB是一个非常灵活的引擎，可以配置为各种使用情况。

RocksDB的主要优点是

文档级锁
支持大型数据集
持久性索引
注意事项

RocksDB允许并发写入。但是，当写入相同的文档时会产生写入冲突。MMFiles引擎不会发生这种情况，因此将引擎切换为RocksDB要做好出现这种异常的准备。执行AQL时可以专门锁定集合。这将避免写入冲突，但也阻止了并发写入。

目前，另一个限制是由于RocksDB中的事务处理。事务总数是有限制的。如果你有一个修改大量文档的语句，则需要在中间提交数据。这将在默认情况下自动完成AQL。

RocksDB是基于日志结构的合并树。下面是一些很好的介绍：

http://www.benstopford.com/2015/02/14/log-structured-merge-trees/
https://blog.acolyer.org/2014/11/26/the-log-structured-merge-tree-lsm-tree/
其基本思想是数据是按层次组织的，每个层次都比前一个要素要大。新的数据将驻留在较小的级别，而旧的数据将下移到较大的级别。这允许在较长时间内支持高速插入。原则上不同的级别可能驻留在不同的存储介质上。较小的放在快速的固态硬盘，大的级别就放在较大的机械硬盘。

RocksDB本身提供了许多不同的旋钮来根据您的使用情况微调存储引擎。ArangoDB支持使用下面的选项最常见的。

存储引擎的性能报告可以在这里找到：

ArangoDB拥有一个用于RocksDB中持久索引的缓存。该缓存的总大小通过该选项控制
--cache.size

RocksDB也有一个存储在磁盘上的块缓存。该缓存的大小由该选项控制
--rocksdb.block-cache-size

ArangoDB默认在两个缓存之间平均分配可用内存。
ArangoDB为RocksDB中的各个级别选择适合于通用应用程序的大小。
RocksDB日志结构化的数据级别越来越大

MEM: --
L0:  --
L1:  -- --
L2:  -- -- -- --
...

新的或更新的文档首先存储在内存中。如果这个memtable达到了给定的限制
--rocksdb.write-buffer-size
它将转换为SST文件并插入0级。

以下选项控制每个级别的大小和深度。

--rocksdb.num-levels N
将等级数限制为N.默认情况下，等于7，很少有理由改变这个。只有前一个数据太多才会打开一个新的级别。

--rocksdb.max-bytes-for-level-base B
L0最多可以容纳B字节。

--rocksdb.max-bytes-for-level-multiplier M
每个级别最多是前一个字节的M倍。因此，L级的最大字节数可以计算为
max-bytes-for-level-base * (max-bytes-for-level-multiplier ^ (L-1))

RocksDB对事务规模施加了限制。它经过优化，能够非常有效地处理小型交易，但却有效地限制了交易的总规模。

ArangoDB目前使用RocksDB的事务来实现ArangoDB事务处理。因此，在使用RocksDB引擎时，ArangoDB交易也有相同的限制。

我们将通过在未来版本的ArangoDB中引入分布式事务来改善这一点。这将允许处理大型交易作为一系列小型RocksDB交易，从而消除尺寸限制。