文件
leveldb是根据单机版bigtable来实现的，但是文件的组织方式却有以下几点不同。
每一个数据库是由存储在文件夹下面的一系列文件集合来实现的，有很多不同类型的文件：
log files：log文件(*.log) 存储了一系列最近的更新。每一个更新都会追加到当前的log文件中。当一个log文件到达一个预设阈值(默认是4mb)，它将会转变成一个有序表，并且为以后的更新操作生成一个新的log文件。
sorted tables一个 sorted tables （*.sst） 存储一系列有序的key。每一个entry是一个key的value或者一个删除的key。
sorted tables 由多级的方式组成。sorted table 由一个特殊的更新的层级生成（也叫做level-0）。当更新的文件超过某一阈值（通常是4个），所有更新的文件会一起与level-1层的文件进行合并产生一个新的leve-1文件（我们为每2m的数据建立一个level-1层的文件）
更新层的文件可能会包含重复的key，然而在其他层级的文件有着有序不相同的key。加入第l层，l>=1。当在l层文件的大小超过10^l mb 时，一个在l层的文件以及所有在l+1层的文件会形成一个新的文件集合。这些合并操作会逐渐的从level-0到最后一层。
mainifest一个manifest文件列出了所有sorted tables的集合，key的序列，一起他重要的元数据。一个新的manifest文件，会在一个数据库重新打开时生成。这个manifest文件以一个log文件的格式，服务的一些更新信息会追加到这个log文件中。
currentcurrent是一个简单的文本文件包含最新的一个manifest文件的名字
info logs数据信息会打印在log和log.old文件中
others其他文件用来生成其他的用处，比如lock，*.dbtmp等等
level 0当一个log文件增长到超过阈值时（默认为1mb）：
建立一个新的内存表和log文件用于写入以后的更新
在后台：
将之前内存表中的内存写到一个sstable中
丢掉这个内存表
删除旧的log文件和旧的内存表
向level-0层中增加新的sstable
compactions当l层的大小超过它的界限，我们在后台的进程中对它进行压缩。压缩操作从l层和所有l+1层之间选择一个文件。注意如果一个l层的文件只与一个l+1层的文件重叠，，全部的l+1层的文件被用来做压缩的输出文件并且压缩后将会被删除。一方面：因为level-0的特殊性，我们特殊对待从level-0到level-1的压缩：一个level-0的压缩可能会选择超过一个level-0文件因为这些文件会与其他文件有重叠。
一个压缩会合并选择的文件的内存来生成一个l+1文件序列。我们会生成一个新的l+1层的文件在当前输出文件达到文件的大小（2mb）。我们也会生成一个新的输出文件当这些key超过是个l+2文件。最后的规则保证了后续的l+1层文件的压缩不会从l+2层选择过多的数据
老文件会被删除，新文件会被添加到服务的状态中。
一个典型的压缩会通过key空间进行旋转，更多的细节是，对于没一个l层我们记住最后一个key。下一个l层的压缩会从这个key开始选择第一个文件。
合并会丢弃掉重复的值。我们也会丢弃标记删除的key，如果编号更高的层数中包含覆盖当前key的文件。
timinglevel-0 压缩会根据从level0中取的四个1mb的文件，并且最坏情况所有的level-1（10m）。。。我们将会读14mb写14mb。
除了level0的特殊压缩，我们会从l层选择一个2mb的文件。在最坏情况，这个会与其他l+1中的12个文件重叠。压缩过程会读26mb，写26mb。假设一个磁盘的io速度为100mb最坏情况的压缩会花费0.5秒
如果我们限制后台写的速度，假如100mb的10%,一个压缩过程会花费5秒。如果用户以10mb的速度写，我们可能会建立很多level-0文件。这样在每次合并的过程中花费会上升。
solution 1： 减少这类问题，当level-0的文件数量足够大时我们可能会增加log文件转换的阈值。阈值下降的趋势越大，内存表需要的内存就越大。
solution 2： 当level0文件数量上升的时候认为降低写的速率
solution 3：降低大量合并操作的花费。大部分level-0的文件不进行压缩，而我们只在合并时考虑o(n)复杂度的算法。
number of files不是只生成2mb的文件，而是对于更大的层级我们可以生成更大的文件以减少文件总数，尽管这样会增加合并的花费。我们可以在多个文件夹中共享文件集合。