zoukankan      html  css  js  c++  java

  • leveldb原理和使用

    LevelDB是一个基于本地文件的存储引擎，非分布式存储引擎，原理基于BigTable（LSM文件树），无索引机制，存储条目为Key-value。适用于保存数据缓存、日志存储、高速缓存等应用，主要是避免RPC请求带来的延迟问题。在存取模型上，顺序读取性能极高，但是对于随机读取的情况延迟较大（但性能也不是特别低），比较适合顺序写入（key），随机的key写入也不会带来问题。数据存量通常为物理内存的3~5倍，不建议存储过大的数据，在这个数据量级上，leveldb的性能比那些“分布式存储”要高（即本地磁盘存取延迟小于RPC网络延迟）。

        1）如果你的log日志或者视频片段需要暂存在本地，稍后再批量发给远端的数据中心，那么这种需求非常适合使用leveldb做数据缓冲。（这些缓存的数据被切分成多个小的chunks，以key-value的方式保存在leveldb中）

        2）如果你希望构建一个本地cache组件，但是cache的数据可能比内存容量要大，此时我们就可以使用leveldb做支撑，leveldb将一部分热区数据保存在内存，其他数据保存在磁盘上，可以并发的、随机读取key-value。但是数据不能太大，否则磁盘读取的延迟将很大，此时应该使用分布式缓存。（当然，分布式缓存是用于解决分布式环境中数据同步、一致性的问题，不仅仅是数据量过大的问题）

     

    一、原理

    1、Files

        leveldb的实现类似于Bigtable中的一个tablet（Google），只不过底层的文件组织形式稍有不同。

        每个Database有一系列本地文件组成，这些文件有不同的类型：

        Log文件

        log文件存储了一序列的最近更新操作，每个更新（update）都会append到当前log文件的尾部，当log文件的尺寸达到预设定的大小时，将会把此log文件转换成一个sorted table（.sst）文件，然后滚动创建一个新的log文件来保存此后的updates操作，主要是用于数据恢复。

     

        当前log文件的数据copy被保存在一个内存结构中，称为memtable，任何update首先会被写入到memtable中，然后在写入log文件。每个read操作都会首先访问memtable，如果memtable中没有的话再触发磁盘检索（如果开启了cacheSize，则在磁盘检索之前会查看cache），因此这些update数据都可以在read操作中反应出来。

     

        memtable中的数据按照key顺序存储，即有序存储（基于跳跃表实现）。默认memtable的大小为4M，由参数“writeBufferSize”决定，需要在leveldb打开db文件时指定。

     

        Sorted tables（简称SST）

        当memtable的数据量达到阀值时，则会被刷新写入到磁盘，生成一个Sorted table（.sst）文件，此文件存储了一序列按照key排序的entries，每个entry可以是key-value，或者是一个key的删除标记（marker），文件和memtable一样也是根据key排序的。（删除标记可以屏蔽掉先前sst文件中保存的较旧的数据，即如果一个key被标记为删除，那么先前的sst文件中关于此key的数据，将不会被read到）

     

        Sorted tables按照层次（level）进行组织，由log文件生成的SST将会放置在一个特殊的young level中--即level-0，当young level中SST文件的个数超过一个阀值（4个），这些young文件将会与level-1中的那些有数据重叠的文件合并，并生成一序列新的level-1文件（每个新文件大小位2M）。

     

        备注：“重叠”意义为key区间在两个文件中都存在。keys在SST文件中保存是严格排序的。同时需要注意，sst文件中还包含BloomFilter内容，bloomFilter可以快速判断key是否存在于此sst文件，有效的提高了read的效率。

     

        young level中的文件可能包含重叠的keys，不过其他level中的SST文件只会包含不同的“非重叠”的keys区间。假如level-L，其中L >= 1，当level-L中SST文件的总大小达到(10^L)MB时（例如level-1位10MB，level-2位100MB），那么level-L中的一个文件，将会和level-(L+1)中那些有keys重叠（覆盖）的文件merged，并生成一组新的level-(L+1)文件。这些merge，只通过批量的文件读写操作，即可将最新的updates数据从young level迁移到最高的level。同一个level中，不会有key重叠的sst文件；但是不同level可能会有！

       level的级别越低，数据新鲜程度越高。遍历数据时，从level 0开始向高level推进。

     

        Manifest（清单）

        manifest文件中列举了构成每个level的SST文件列表，以及相应的key区间，还包括一些重要的metadata。当database被reopened时，都会创建一个新的manifest文件（文件命中包含一个新的number序列号）。manifest文件的格式像log，“serving data”的变更（比如SST文件的创建、删除）操作都会被append到此log中。

     

        Current

        CURRENT文件是一个简单的文本文件，保存了当前最新的manifest文件的名称。

     

        其他：略

     

    2、Level 0

        当log文件的尺寸增长到一定的大小（默认1M）：

    • 创建一个新的memtable和log文件，用来保存此后的updates操作。
    • 在后台：将旧的memtable写入到文件生成新的SST文件，然后销毁此memtable。删除旧的log文件，然后将此新的SST文件添加到young level组织中。

    3、Compactions

        当level-L的尺寸达到了它的限制，我们将使用一个后台线程对它进行Compaction。压缩时，将会从level-L中选择一个文件，同时选择level-(L+1)中所有与此文件key有重叠的文件。如果level-L中一个文件只与level-(L+1)中某个文件的一部分重叠，那么level-(L+1)中的此文件作为压缩时的输入，在压缩结束后，此文件将被抛弃。不过，level-0比较特殊（文件中的keys可能互相重叠），对于level-0到level-1的压缩我们需要特殊处理：level-0中文件中互相重叠的话，那么将可能一次选择多个level-0的文件作为输入。

     

        压缩将选择的文件内容重新输出到一序列新的level-(L+1)文件中（多路合并），当每个输出文件达到2M时将会切换一个新的文件，或者当新输出的文件中key区间覆盖了level-(L+2)中多于10个文件时，也会切换生成新文件；第二个规则保证此后level-(L+1)的压缩时无需选择太多的文件。

     

        当level-(L+1)中的新文件加入到“serving state”时，那么旧的文件将会被删除（包括level-L和level-(L+1)）。

     

        压缩时，将会抛弃那些“overwritten”的值；如果遇到删除标记，且对应的key在更高的level中不存在，也会直接抛弃。

     

        Timing

        level-0将会读取4个1M的文件（每个1M，level-0最多4个文件），最坏的情况是读取level-1的所有文件（10M），即我们读写各10MB。

        和level-0不同，对于其他level-L，我们将读取2M的一个文件，最坏的情况是它与level-(L+1)中12文件有重叠（10个文件，同时还有2个处于边界的文件）；那么一次压缩将读写26MB数据。假定磁盘IO速率位100M/S，那么一次压缩耗时大约0.5秒。

     

        如果我们对磁盘速率受限，比如10M/S，那么压缩可能耗时达到5秒。

     

        文件个数

        每个SST文件的大小为2M（level-0的除外），事实上我们可以通过增大此值（需要重新编译源文件），来减少文件的总数，不过这会导致压缩更加耗时（读取的文件尺寸更大，磁盘密集操作）；另外，我们可以将不同的文件放在多个目录中。

     

    4、数据恢复

        1）从CURRENT中读取最新的manifest文件的名字。

        2）读取manifest文件。

        3）清理那么过期的文件。

        4）我们可以打开所有的SST文件，不过通常lazy更好。

        5）将log存留文件转存成新的level-0中的SST文件。

        6）引导write操作到新的log文件中。

        7）回收垃圾文件。

     

        每次压缩和recovery操作后，将会调用DeleteObsoleteFiles()：从database中查询出所有的file的名字，然后将当前log文件之外的其他log文件全出删除，删除那些所有level中都不包含的、以及压缩操作没有引用的SST文件。

     

    二、使用

        leveldb为一个本地化的K-V存储数据库，设计思想类似于Bigtable，将key按照顺序在底层文件中存储，同时为了加快读取操作，内存中有一个memtable来缓存数据。

        根据leveldb官网的性能基准测试，我们大概得出其特性：

        1）leveldb的顺序读（遍历）的效率极高，几乎接近文件系统的文件顺序读。比BTree数据库要快多倍。

        2）其随机读性能较高，但和顺序读仍有几个量级上的差距。leveldb的随机读，和基于BTree的数据库仍有较大差距。（个人亲测，其随机读的效率并不像官网所说的如此之高，可能与cache的配置有关）随机读，要比BTree慢上一倍左右。

        3）顺序写，性能极高（无强制sync），受限于磁盘速率；随机写，性能稍差，不过性能相对于其他DB而言，仍有极大的优势。无论是顺序写还是随机写，性能都比BTree要快多倍。

        4）leveldb为K-V存储结构，字节存储。属于NoSql数据库的一种，不支持事务，只能通过KEY查询数据；支持批量读写操作。

        5）leveldb中key和value数据尺寸不能太大，在KB级别，如果存储较大的key或者value，将对leveld的读写性能都有较大的影响。

        6）leveldb本身没有提供索引机制，所以随机读性能稍差。它存储的key、value可以为任意字节数组。

     

        因为leveldb本身尚不具备“分布式”集群架构能力，所以，我们将有限的数据基于leveldb存储（受限于本地磁盘）。

        

        案例推演：

        1）leveldb具备“cache + 磁盘持久存储”特性，且不支持RPC调用，那么leveldb需要和application部署在同一宿主机器上。类似于“嵌入式”K-V存储系统。

        2）如果存储数据较少，3~5G，且“读写比”（R:W）较高，我们可以让leveldb作为本地cache来使用，比如Guava cache + leveldb，这种结合，可以实现类似于轻量级redis。即作为本地缓存使用。通常LevelDB存储的数据是内存大小的3~5倍（现代的操作系统配置），不建议用leveldb存储过大的数据，否则性能将下降很大。

        3）如果数据较多，通常为“顺序读”或者“顺序写”，我们可以将leveldb作为Hadoop HDFS的“微缩版”，可以用来缓存高峰期的消息、日志存储的缓冲区。比如我们将用户操作日志暂且存储在leveldb中，而不是直接将日志发送给remote端的Hadoop（因为每次都直接调用RPC，将会对系统的吞吐能力带来极大的影响），而是将这些频繁写入的日志数据存储在本地的leveldb中，然后使用后台线程以“均衡”的速度发送出去。起到了“Flow Control”（流量控制）的作用。

     

        其中ActiveMQ即采用leveldb作为底层的消息数据存储，性能和容错能力很强。在很多情况下，leveldb可以作为本地log、IO缓冲文件的存储方案。

     

    三、API简析（JAVA版）

        原生leveldb是基于C++开发，java语言无法直接使用；iq80对leveldb使用JAVA语言进行了“逐句”重开发，经过很多大型项目的验证（比如ActiveMQ），iq80开发的JAVA版leveldb在性能上损失极少（10%）。对于JAVA开发人员来说，我们直接使用即可，无需额外的安装其他lib。

        1、pom.xml

    Java代码  收藏代码
    1. <dependency>  
    2.     <groupId>org.iq80.leveldb</groupId>  
    3.     <artifactId>leveldb</artifactId>  
    4.     <version>0.7</version>  
    5. </dependency>  
    6. <dependency>  
    7.     <groupId>org.iq80.leveldb</groupId>  
    8.     <artifactId>leveldb-api</artifactId>  
    9.     <version>0.7</version>  
    10. </dependency>  

     

        2、代码样例

    Java代码  收藏代码
    1. boolean cleanup = true;  
    2. Charset charset = Charset.forName("utf-8");  
    3. String path = "/data/leveldb";  
    4.   
    5. //init  
    6. DBFactory factory = Iq80DBFactory.factory;  
    7. File dir = new File(path);  
    8. //如果数据不需要reload，则每次重启，尝试清理磁盘中path下的旧数据。  
    9. if(cleanup) {  
    10.     factory.destroy(dir,null);//清除文件夹内的所有文件。  
    11. }  
    12. Options options = new Options().createIfMissing(true);  
    13. //重新open新的db  
    14. DB db = factory.open(dir,options);  
    15.   
    16. //write  
    17. db.put("key-01".getBytes(charset),"value-01".getBytes(charset));  
    18.   
    19. //write后立即进行磁盘同步写  
    20. WriteOptions writeOptions = new WriteOptions().sync(true);//线程安全  
    21. db.put("key-02".getBytes(charset),"value-02".getBytes(charset),writeOptions);  
    22.   
    23.   
    24. //batch write；  
    25. WriteBatch writeBatch = db.createWriteBatch();  
    26. writeBatch.put("key-03".getBytes(charset),"value-03".getBytes(charset));  
    27. writeBatch.put("key-04".getBytes(charset),"value-04".getBytes(charset));  
    28. writeBatch.delete("key-01".getBytes(charset));  
    29. db.write(writeBatch);  
    30. writeBatch.close();  
    31.   
    32. //read  
    33. byte[] bv = db.get("key-02".getBytes(charset));  
    34. if(bv != null && bv.length > 0) {  
    35.     String value = new String(bv,charset);  
    36.     System.out.println(value);  
    37. }  
    38.   
    39. //iterator，遍历，顺序读  
    40.   
    41. //读取当前snapshot，快照，读取期间数据的变更，不会反应出来  
    42. Snapshot snapshot = db.getSnapshot();  
    43. //读选项  
    44. ReadOptions readOptions = new ReadOptions();  
    45. readOptions.fillCache(false);//遍历中swap出来的数据，不应该保存在memtable中。  
    46. readOptions.snapshot(snapshot);//默认snapshot为当前。  
    47. DBIterator iterator = db.iterator(readOptions);  
    48. while (iterator.hasNext()) {  
    49.     Map.Entry<byte[],byte[]> item = iterator.next();  
    50.     String key = new String(item.getKey(),charset);  
    51.     String value = new String(item.getValue(),charset);//null,check.  
    52.     System.out.println(key + ":" + value);  
    53. }  
    54. iterator.close();//must be  
    55.   
    56. //delete  
    57. db.delete("key-01".getBytes(charset));  
    58.   
    59. //compaction，手动  
    60.   
    61. db.compactRange("key-".getBytes(charset),null);  
    62.   
    63. //  
    64. db.close();  

      

        LevelDB是google的实现，官方只提供了C++版的客户端，java客户端比如上述的iq80（还有fusesource 项目的leveldbjni）是来自社区的。不过BigTable的设计思想和LevelDB的特性被社区延续了下去，比如相对比较完善和性能更加优秀的RocksDB，我们建议在实际的开发工作中采用它。

     

    参考文献：

    1、LevelDB实现原理：http://leveldb.googlecode.com/git-history/1.17/doc/impl.html

    2、LevelDB性能测试：http://leveldb.googlecode.com/git-history/1.17/doc/benchmark.html?r=1.17
  • 相关阅读:
    XSS 1
    KALI修改密码
    bugku web4
    16进制 32进制 base64之间的区别
    buuctf
    buuctf wireshark
    buuctf 变异凯撒
    2016集训测试赛（二十）Problem A: Y队列
    USACO 4.1.1 麦香牛块 Beef McNuggets
    2016集训测试赛（十八）Problem C: 集串雷 既分数规划学习笔记
  • 原文地址：https://www.cnblogs.com/mtcnn/p/9410037.html
Copyright © 2011-2022 走看看