深入了解 HyperLevelDB 已翻译 100%

常用的LeveDB是良好的基础，我们对HyperDex的经验使我们看到了几个进一步提高LevelDB性能的机会。这篇文章阐述了我们对LevelDB所作的更改满足了HyperDex客户端的高标准的需求。
尤其是我们在两个方面的更改提高了LevelDB性能:

• 通过细致的所管理机制增加了并行性
• 通过改进压缩过程增加了吞吐量

这篇文章详细的描述了这些更改，以给你这样的直觉：为什么因更改而产生的HyperLeveDB分支如此之快。

改进并行

保持Stock LevelDB的互斥锁特性，确保能同时多线程安全的写入数据库。类似Python的全局解释锁，

这种简单的单线程互斥锁进行多任务处理时很耗性能。现在的CPU都有多个核心，它的优点就是利用多核心高效的执行指令。所以，我们首先要做的就是解锁。

当然，做的时候要小心谨慎以避免数据错乱。简单地检查Stock LevelDB的并行事件然后重新认识的HyperLevelDB。

常见的LeveDB提供了内部同步机制，这样就允许多个线程并行地访问数据存储。在内部，写是按照FIFO顺序进行的：处于FIFO最先位置的写线程是唯一一个可以写入数据库的线程，而且所有正在排队的其他线程必须等待。每次写都向磁盘的备份日志和内存的备份“内存表”里插入数据。这个日志是只增加的文件，他可以为崩溃恢复提供持久性支持，而这个内存表是已经排序的跳跃表，它能够使读线程快速地查找存储在日志里的数据。在向FIFO里的下一个写线程发送信号之前，当前写线程必须向日志和内存表里写入数据。

为了克服排队所造成的影响，常见的LevelDB分批写FIFO最开始部分所包含的数据，在一个分批处理里有许多写线程在写入数据。这样的分批处理提高了性能，尤其是提高了同步写的性能，不过从根本上来说，没有更改顺序写这个特性。还可能花费更多资源，因为做分批处理的线程必须读，并且可能拷贝其他线程写入的数据。只要FIFO的最先位置的线程正在做任何真正的写工作的话，内核就阻塞其他写线程，以等待最先位置的写线程所发送信号。

HyperLeveDB并行性

HyperLevelDB改进了写线程的并发性：允许多个写线程独立地插入自身要写的内容到日志和内存表里，同时仅仅为了维护写的顺序而使用同步机制。为了了解HyperLevelDB是如何做这些工作的，理解LevelDB里读和写交互的方式就特别重要。

HyperLevelDB保持这样一个不变的事实：读线程选择的序号从不取决于任何仍然未完成的写线程。写线程可以以任何顺序更新日志和内存表，而且从不关心写线程各自的序号。写完后，每个写线程使用同步机制去更新全局序号，这样写线程看起来是按照FIFO的顺序来执行的，这保持了所要求的顺序不变。每个写线程负责独立地更新日志和内存表-这导致了大量的工作，并且只有使用同步机制递增便于即将到来的读线程使用的序号才能解决这个问题。

为了充分利用这个新发现的并发特性，HyperLevelDGB修改了LevelDB的日志和内存表的实现，以达到允许安全地并发插入。

改进了压缩

LevelDB这个名字源于它使用了层级性的存储结构。数据是存储在每个层级里的，每个层级比下面层级存储更多数据。在每个层级内部，数据是排序的，并且存储在称作排序字符串表或者SST的文件里，这儿每个排序字符串表也进行了排序，并且排序字符串表是非重叠的，因此每个关键字最多存储在一个字符串表里。写的内容将合并这棵层级树的底部，然后名字为压缩的进程将透过层级把数据上移，同时在每个层级内部保持排序。

•  使用经验性分析方法调整压缩相关的常量以减少写入放大。
•  在低层级里保持数据无序，以避免线性合并所带来的资源使用，减少读延迟
•  选择可明显地使写放大减小到最小的压缩目标（即排序字符串表）

降低写放大的压缩器

HyperLevelDB更改了压缩算法，明显地选择在两个级别直接产生最小写放大的一组字符串排序表。一个后台压缩线程监控每个层级  的大小，并且对最适合压缩的一组字符串排序表进行压缩。第二个后台线程在第一个线程无法承受更多负载的时候触发，它执行  全局优化以选择可降低写放大的压缩目标，而且并不关心每个层级的大小。典型的情况是，第二个线程将在不做任何写放大的情况下  从下层级移动文件。对上面的层级来说，第二个线程抢先压缩数据，这经常足以使得高层级的大小比第一个线程所使用的限制大小的启发法所得的结果要小，同时确保第一个后台线程不和高级别的压缩紧密相连。