[发明专利]一种面向海量小文件存储系统的Key-Value存储方法

说明书

技术领域

本发明涉及分海量小文件存储领域，具体涉及一种面向海量小文件存储系统的Key-Value存储方法。

背景技术

近年来，社交网站如Facebook、Twitter、人人网和电子商务网站e-Bay、阿里巴巴等网络服务发展迅速，这类服务都需要存储大量图片、短文本等小文件。小文件通常指文件大小小于64M的文件，例如互联网应用经常需要存储的图片、邮件、电子书、音乐文件、微博、文本内容等。

小文件存储逐渐在学术界和工业界引起了一些关注。社交网站Facebook存储了2600亿张图片，容量超过20PB，这些文件绝大部分都小于64MB。在超级计算机领域，例如，ORNL’s CrayXT5集群（18688个节点，每个节点12个处理器）上的应用程序会周期性地将应用状态写入文件，导致系统累积大量的小文件。在具体科研计算环境中，例如某些生物学计算中，可能产生3000万个文件，而其平均大小只有190KB。美国西北太平洋国家实验室发表于2007年的一份研究报告数据表明，该实验室所使用的系统中存储了1200万个文件，其中小于64MB的文件占文件总数的94%，小于64KB的占58%。音乐网站巨鲸网已经收录了360万MP3格式的音乐文件。各种资料都表明，互联网上访问的数据多为高访问频率的小文件。

小文件的检索信息是通过保存Key-Value键值对来实现的，通常使用NoSQL数据库（如Redis和LevelDB）。然而LevelDB和Redis等主流Key-Value存储引擎在存储检索信息时效果不好。原因如下：

1.小文件存储系统记录的value数据格式固定，大小统一，相对于Redis适用于各种数据结构，小文件存储系统可以针对特定应用简化数据结构，减少了对数据结构进行打包和解析的操作，并避免实现通信协议，从而节省CPU开销，降低延迟。

2.Redis系统主要针对将数据缓存在内存中的应用。Redis可以配置持久化功能，但小文件存储系统可以针对其特定应用，能够更好地支持持久化。

3.LevelDB是单机版持久化Key-Value存储引擎，但LevelDB使用内存中的MemTable和磁盘上的Level文件块来降低写入时的延迟，但对于读请求，LevelDB可能需要多次磁盘操作（最多要读6次以上磁盘文件），因此LevelDB非常适合于写多读少的情况。而在真实的互联网应用中，如Facebook网站上的相册或者淘宝网上商品照片，其应用特征为一次写入，多次读取，因此LevelDB也不适合小文件存储系统中保存检索信息。

发明内容

本发明提出了一种面向小文件存储系统的轻量级可持久化的Key-Value存储引擎KVDB。

KVDB结构设计如图1。KVDB包括两个部分，内存中的HashTable结构和磁盘上的持久化存储Store。

HashTable类图如图2。DictEntry用来表示上图中的哈希表的一个条目。使用链表法解决哈希冲突。HashTable保存了用于检索的key和value在Store中的位置。

Store用于存放value内容，Store可以写入一个value内容，并返回该value内容在Store内部的偏移量，或者给定一个起始位置，Store可以读取出一个value内容。Store的类图如图3。在KVDB中，所有要保存的这些数据结构类型，都必须能够进行序列化和反序列化（serialize和deserialize），以便Store类将该数据结构存放在磁盘进行持久化。Store类对应一个磁盘文件，该类包含一个指向该磁盘文件的句柄和一些统计信息，所有要保存的数据结构都写入这个磁盘中，同时Store提供读写接口函数。为提供断电恢复功能，Store还提供了一个从磁盘中加载的接口函数。为提高读取速度，Store中用于存放value内容的文件在加载时，通过mmap函数将文件内容映射到内存中。这样，访问Store对应的磁盘文件时，通常都可以在内存中访问到。

KVDB的类图如图4。KVDB公开的接口包括构造函数，初始化函数init，格式化函数format，写入一条key-value键值对put函数，读取一条key-value键值对get函数。

附图说明

图1是KVDB的结构图

图2是KVDB的HashTable类图

图3是KVDB中的Store类图

图4是KVDB类图

具体实施方式