Jes*_*sse 10
我将指出您在LevelDB上的一些文章及其底层存储结构的方向.
这些合并具有使用批量读取和写入(即,最小化昂贵的搜索)逐步将新更新从年轻级别迁移到最大级别的效果.
LevelDB在结构上类似于Log Structured Merge Trees.如果您对分析感兴趣,本文将讨论不同的层次.如果你能通过数学,那么理解数据结构似乎是你最好的选择.
更容易阅读的levelDB 分析讨论了数据存储区与LSM树的关系,但就你所说的关于水平的问题而言,它是:
最后,拥有数百个磁盘上的SSTable也不是一个好主意,因此我们会定期运行一个进程来合并磁盘上的SSTable.
LevelDB文档可能提供了最佳答案:(最大化写入和读取的大小,因为LevelDB是磁盘上(慢速搜索)数据存储).
祝好运!
我认为这主要与简单快速合并关卡有关.
在Leveldb中,level-(i + 1)大约有.与level-i相比数据的10倍.这更类似于多级缓存结构,其中如果数据库在密钥x1到x2之间有1000条记录,那么该范围内最常访问的10条记录将处于级别1,而相同范围内的100条记录将位于在第2级并在第3级休息(这不是确切的,只是为了直观地了解关卡).在这个设置中,要合并level-i中的文件,我们需要在level-(i + 1)中查看最多10个文件,它们都可以被带入内存,快速合并并写回.这导致为每个压缩/合并操作读取相对小的数据块.
另一方面,如果您只有2个级别,则一个0级文件中的键范围可能与级别1中的1000个文件匹配,并且所有这些文件都需要打开以进行合并,这将非常慢.请注意,这里一个重要的假设是我们有固定大小的文件(比如说2MB).对于级别为1的可变长度文件,您的想法仍然可以工作,我认为其中的变体用于HBase和Cassandra等系统.
现在,如果你关注的是关于多层次的查找延迟,那么这就像一个多级缓存结构,最近写入的数据将在更高级别来帮助典型的引用局部性.