CN104408091A - 分布式文件系统的数据存储方法及系统 - Google Patents

Abstract

本发明公开了一种分布式文件系统的数据存储方法，包括以下步骤：接收用户发送的数据文件；判断数据文件的大小；如果数据文件的大小小于预设值，则将数据文件通过基于日志格式的归并树LSM-Tree的KV存储方法存储至云端服务器的key-value数据库；如果数据文件的大小大于预设值，则将数据文件切分为多个子数据文件，并存储至本地文件系统。本发明实施例的方法通过将数据文件按照文件的大小进行区分，从而提高分布式文件系统的效率，实现整体性能的提升。本发明实施例还公开了一种分布式文件系统的数据存储系统。

Description

分布式文件系统的数据存储方法及系统

技术领域

本发明涉及文件系统技术领域，特别涉及一种分布式文件系统的数据存储方法及系统。

背景技术

目前，分布式文件系统如GFS(Google File System，存储数据的文件系统)、MooseFS、Lusture等都是以建立在单机文件系统的基础上的。分布式层负责组织逻辑文件到逻辑数据块列表的映射，而本地文件系统则负责从逻辑数据块到硬盘数据的映射。两层各司其职共同完成了数据的寻址与读写操作。

其中，本地文件系统通常使用多层索引来组织磁盘上的数据。如Ext系列的文件系统，在访问数据块之前必须通过元数据索引找到对应的元数据，而找到该元数据之前必须找到其父目录的元数据。在进行数据读写之前需先经历一个沿着目录树寻找元数据的过程。然而，这样的访问模式直接导致了小文件的低读写效率。对于大文件来说，这些开销可以均摊到数据读写，配合系统缓存的设计可以将对性能的影响降到极小，但是对于小文件来说，这部分开销占据了整个访问时间的绝大部分。因此，本地文件系统对于小文件的性能往往会很差，与大小文件读写性能相比会相差一个数量级，并且由于分布式文件系统使用本地文件系统作为后端存储，文件的读写过程相比本地读写多了几次网络交互，导致在分布式环境下同样面临着更加严重的小文件读写性能较低的问题。

另外，由于分布式文件系统仅使用本地文件系统基本的存储服务，本地文件系统保留的元数据很多都是不必要的。分布式文件的命名空间组织方式与本地文件系统并不相同，而且是独立于本地文件系统的，因此为优化小文件读写性，相关技术中的分布式系统有待改进。

发明内容

本发明旨在至少在一定程度上解决上述相关技术中的技术问题之一。

为此，本发明的一个目的在于提出一种能够提高系统效率和性能，简单方便的分布式文件系统的数据存储方法。

本发明的另一个目的在于提出一种分布式文件系统的数据存储系统。

为达到上述目的，本发明一方面实施例提出了一种分布式文件系统的数据存储方法，包括以下步骤：接收用户发送的数据文件；判断所述数据文件的大小；如果所述数据文件的大小小于预设值，则将所述数据文件通过基于日志格式的归并树LSM-Tree(Log-Structured Merge-Tree，基于日志格式的归并树)的KV(key-value，键值对)存储方法存储至云端服务器的key-value数据库；以及如果所述数据文件的大小大于所述预设值，则将所述数据文件切分为多个子数据文件，并存储至本地文件系统。

根据本发明实施例提出的分布式文件系统的数据存储方法，通过将数据文件按照大小进行区分，如果数据文件的大小小于一定值，则将数据文件通过基于LSMTree的KV存储方法存储至云端服务器的key-value数据库，并且如果数据文件的大小大于一定值，则将数据文件切分为多个子数据文件，并存储至本地文件系统，从而提高分布式文件系统的效率，实现整体性能的提升。

另外，根据本发明上述实施例的布式文件系统的数据存储方法还可以具有如下附加的技术特征：

进一步地，在本发明的一个实施例中，在所述将所述数据文件通过LSM-Tree的KV存储方式至云端服务器的key-value数据库中之后，还包括：根据所述数据文件的数据块ID(identity，身份标识号码)、数据块版本、数据块序号生成所述数据文件的Key。

进一步地，在本发明的一个实施例中，在所述将所述数据文件切分为多个子数据文件，并存储至本地文件系统之后，还包括：根据每个子数据文件的数据块ID和数据块版本生成所述多个子数据文件对应的本地文件系统的文件名。

进一步地，在本发明的一个实施例中，上述方法还包括：根据所述每个子数据文件中数据块生成对应的校验码，以维护子数据文件。

优选地，在本发明的一个实施例中，所述预设值可以为64MB。

本发明另一方面实施例提出了一种分布式文件系统的数据存储系统，包括：接收模块，用于接收用户发送的数据文件；判断模块，用于判断所述数据文件的大小；第一存储模块，如果所述数据文件的大小小于预设值，用于将所述数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库；以及第二存储模块，如果所述数据文件的大小大于所述预设值，用于将所述数据文件切分为多个子数据文件，并存储至本地文件系统。

根据本发明实施例提出的分布式文件系统的数据存储系统，通过将数据文件按照大小进行区分，如果数据文件的大小小于一定值，则将数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库，并且如果数据文件的大小大于一定值，则将数据文件切分为多个子数据文件，并存储至本地文件系统，从而提高分布式文件系统的效率，实现整体性能的提升。

另外，根据本发明上述实施例的分布式文件系统的数据存储系统还可以具有如下附加的技术特征：

进一步地，在本发明的一个实施例中，上述系统还包括：Key生成模块，用于根据所述数据文件的数据块ID、数据块版本、数据块序号生成所述数据文件的Key。

进一步地，在本发明的一个实施例中，上述系统还包括：文件名生成模块，用于根据每个子数据文件的数据块ID和数据块版本生成所述多个子数据文件对应的本地文件系统的文件名。

进一步地，在本发明的一个实施例中，上述系统还包括：校验码生成模块，用于根据所述每个子数据文件中数据块生成对应的校验码，以维护子数据文件。

优选地，在本发明的一个实施例中，所述预设值可以为64MB。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本发明实施例的分布式文件系统的数据存储方法的流程图；

图2为根据本发明一个实施例的使用的MooseFS的结构示意图；

图3为根据本发明一个实施例的数据服务器的结构示意图；

图4为根据本发明一个实施例的Key的结构示意图；

图5为根据本发明一个实施例的File Region中chunk对应的文件名结构示意图；

图6为根据本发明一个实施例的SepStore写操作的流程图；

图7为根据本发明实施例的分布式文件系统的数据存储系统的结构示意图；以及

图8为根据本发明一个实施例的分布式文件系统的数据存储系统的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本发明中，除非另有明确的规定和限定，第一特征在第二特征之“上”或之“下”可以包括第一和第二特征直接接触，也可以包括第一和第二特征不是直接接触而是通过它们之间的另外的特征接触。而且，第一特征在第二特征“之上”、“上方”和“上面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度小于第二特征。

下面在描述根据本发明实施例提出的分布式文件系统的数据存储方法及系统之前，先来简单描述一下本发明实施例提出的原因。

·从整个分布式文件系统的读写流程来看，客户端与数据服务器的数据交互过程是影响读写性能的重要部分，而数据服务器上由于文件系统结构和磁盘寻道等原因导致小文件的读写性能很差。

·分布式文件系统有单独的元数据管理服务，本地文件系统保存的很多元数据如修改时间、等待时间、硬连接数等多是不必要的。

·分布式文件系统中文件的概念与本地文件系统的文件概念并不是一一对应的，实际上大文件往往会被切分成多个本地文件系统的文件以实现并行。而小文件也可以聚合成本地文件系统上较大的以减少元读写过程中的元数据开销。

·本地文件系统的open、close开销是不必要的，而鉴于本地文件系统的设计，完全消除open、close开销并不可能，但是通过将小文件打包成大文件可将这部分开销降到最低。

·从数据服务器上的数据读写流程来看，随机读写造成的磁盘寻道是影响文件系统性能最重要的因素。对于随机写，可以通过采用log-structured的磁盘布局可以将写性能大幅度提高。而对于随机读操作，可以通过利用内存索引技术减少读写过程中的IO次数。

·优化了小文件读写后，特别是减少了大量的磁盘寻道操作后，整个文件系统的性能都会有提升。

本发明正是基于上述问题，而提出了一种分布式文件系统的数据存储方法和一种分布式文件系统的数据存储系统。

下面参照附图描述根据本发明实施例提出的分布式文件系统的数据存储方法及系统，首先将参照附图描述根据本发明实施例提出的分布式文件系统的数据存储方法。参照图1所示，该方法包括以下步骤：

S101，接收用户发送的数据文件。

首先，参照图2所示，本发明实施例保留了MooseFS的整体架构、元数据服务器MooseFS中称为Master，或为Metadata Server)和客户端的大部分代码，实现了一个新的数据服务器。其中，MooseFS的结构与GFS类似，由多个客户端10(Clients)、元数据管理服务器20(Master)和多个数据服务器30(Chunkserver)构成，每个部分承担的功能也与GFS类似。

具体地，在本发明的实施例中，每个部分承担的功能如下：

·多个客户端10中的客户端负责将整个分布式文件系统的资源虚拟化，利用FUSE对外提供POSIX接口。一旦使用客户端挂载后，应用可以像使用本地磁盘一样使用MooseFS。

·元数据管理服务器20负责管理元数据信息，决定数据的放置策略，维护整个系统的运行。其中，一旦Master宕机后整个服务也将停止。为了保护元数据的可靠性，MooseFS还设计了一个Metadatalogger(元数据日志服务器)，从而对元数据的操作进行实时备份。

·多个数据服务器30中的Chunkserver负责数据在磁盘上的存储。其中，Chunkserver的实现依赖于一个用户态的进程，底层的存储则依赖本地文件系统。

S102，判断数据文件的大小。

S103，如果数据文件的大小小于预设值，则将数据文件通过基于日志格式的归并树LSM-Tree的KV存储方法存储至云端服务器的key-value数据库。

优选地，在本发明的一个实施例中，预设值可以为64MB。需要说明的是，改预设值仅是出于示例的目的，预设值即预设大小并不限定于此。

进一步地，在本发明的一个实施例中，在将数据文件通过LSM-Tree的KV存储方式至云端服务器的key-value数据库中之后，还包括：根据数据文件的数据块ID、数据块版本、数据块序号生成数据文件的Key。

S104，如果数据文件的大小大于预设值，则将数据文件切分为多个子数据文件，并存储至本地文件系统。

进一步地，在本发明的一个实施例中，在将数据文件切分为多个子数据文件，并存储至本地文件系统之后，还包括：根据每个子数据文件的数据块ID和数据块版本生成多个子数据文件对应的本地文件系统的文件名。

具体地，在本发明的一个实施例中，MooseFS的数据读写流程和存储方案也与GFS类似。对于大文件MooseFS将按照64M(编译时决定，默认64MB)大小进行切块，分成多个chunk(数据块，相当于分成多个子数据文件)存到不同的Chunkserver上。对于小文件MooseFS则当做一个单独的Chunk存放到Chunkserver上。每个chunk都对应着Chunkserver上文件系统的一个实际文件。元数据管理服务器20维护了从文件名到chunk列表的对应关系，chunk的标识是一个64位的chunkID(数据块ID)。在进行数据读写的时候，客户端会先向元数据管理服务器20请求文件对应的chunk的chunid和chunk所在的Chunkserver的IP和端口号。客户端拿到这些信息后会向指定的Chunkserver发出数据读写请求。如果是读操作，客户端从指定的Chunkserver完成数据读取即可。如果是写操作，客户端需要将待写数据传给一个Chunkserver，该Chunkserver在完成本地磁盘的读写的同时会将数据转发给其它副本所在数据服务器。当客户端收到Chunkserver传来的写操作的结果后需要到Master确认元数据信息的更改或者写操作的失败。

进一步地，在本发明的一个实施例中，参照图3所示，本发明实施例的数据文件按照不同的大小提供不同的存储方案，并针对小文件提供LSM技术配合key-value数据库的方案，从而带来整体效能的提升。具体地，在SepStore中，对于大文件将按照固定的大小例如64MB进行切分并将chunk放在不同的服务器上，而小文件则被认为一个单独的chunk。最终Chunkserver上存在三种大小的文件，一种是小于大小预设值T的被认为是小文件，一种是介于T和64MB之间的，最后一种则是64MB的文件。T的选择是一个关键问题，本发明实施例根据实验选取64KB作为T的大小，但是在实际应用中，应当根据应用场景来选择。SepStore中的Chunkserver将分别为第一种文件和第二、第三文件提供有针对性的存储方案。本发明实施例通过基于LSM(Log-Structure Merge)Tree的KV存储技术和本地文件系统相结合，从而优化分布式文件系统数据访问效率。

具体地，SepStore的Chunkserver结构如图3所示。其中，SepStore的Chunkserver分为三部分：一部分是File Region，其用于存储较大的文件即大于T(即T用来区分文件是放到File Region还是KV Region的界限值，在SepSotre中T默认为64KB，接下来提到的T若无特殊说明一律为64KB)小于64MB的文件；另一部分则是KV Region，其主要用于存储小文件即小于T的文件；最后一部分则是Metadata Region，其用于存储数据服务器上的chunkid、version(数据块版本)等元数据信息。本发明实施例将大于T的文件存入Fileregion，小于T的文件存入KV region，但是这种划分并不是绝对的，例如存放于KV Region的小文件可能在一次写操作后体积变得大于T，当出现这种情况时，数据并不会立即被迁移而是会被暂时切分成多个KV对，真正的迁移操作则由后台线程异步完成。

进一步地，Chunkserver对外提供统一的访问接口，主要包括read、write和delete。具体地，在接到客户端请求后，Chunkserver会生成任务放入到任务池中，任务队列是一个先进先出的队列，任务之间并没有优先级差别。Chunkserver维护了一个线程池来处理任务池中的任务，读写任务都是异步完成的。其中，在运行时，所有的元数据都会被加载到内存当中，并被组织成一个巨大的哈希表，chunkid则是哈希表的输入值。Chunkserver除了响应客户端的数据请求外，还会定时向Master汇报本地的磁盘使用情况、错误情况等信息。

进一步地，在本发明的一个实施例中，参照图4所示，与本地文件系统不同，KV Region提供的是一个扁平化的命名空间。其中，每个key-value对都有唯一的Key，数据库利用Key来实现数据的定位。在KV Region的设计中，本发明实施例并没有保存Key值，而是设计了一种简单的算法来生成Key。具体地，每个chunk的Key组成如图所示，由chunkid(数据块ID)，version(数据块版本)和blocknum(数据块序号)共同构成。其中chunkid和version都是由客户端直接传过来的信息，blocknum则用来当前的key-value对在整个chunk中的位置。每个block的大小是固定例如为64KB，故blocknum可以通过下列公式blocknum＝offset％64KB得到。

进一步地，在本发明的一个实施例中，参照图5所示，在分布式环境下，为了实现基于本地文件系统的数据读写功能，SepStore需要维护一些额外的元数据信息来实现从chunkid到系统文件的映射。与KVRegion的设计一样，在File Region中，本发明实施例并没有直接将chunkid到本地文件的映射信息保存，而是采用了一个简单的算法来实现数据的寻址功能。具体地，每个chunk对应的本地文件系统的文件名是由chunid，version构成，其结构如图所示，这种将元数据信息隐含在文件名字中的做法有两个好处：

·可以实现从chunkid到数据的快速定位。

·SepStore开启了一个后台线程定期对所有File Region所有文件进行扫描，并利用文件名包含的信息来验证数据的一致性。

为了提高文件的读取性能，File Region采取了以下优化措施：

(1)相较于本地文件系统更加有效的缓存策略，SepStore在文件系统之上维护了对于block的数据缓存并实现了LRU(Least Recently Used，最少使用页面置换算法)策略。

(2)目录间的数据负载均衡。大多数文件系统都使用B+树或者其变种来维护数据的索引，这些索引结构的均衡性较好，但不能很好的处理同一目录下文件过多的情况。同时，如果目录深度过多则会增加chunkserver的元数据负担。因此希望能保证目录层数尽量少的前提下尽量将文件均衡分布。SepStore采用了一个简单的策略来实现文件的均衡分布。在根目录下，SepStore将默认创建256个子目录，chunk的位置则通过chunkid％256来决定文件的子目录位置。

其中，在本发明的一个实施例中，上述方法还包括：根据每个子数据文件中数据块生成对应的校验码，以维护子数据文件。即言，File Region与KV Region的一个不同在于FileRegion为每个chunk维护了一个校验码，每4KB有一个字节的校验数据。

进一步地，在本发明的一个实施例中，参照图6所示，通过利用KV存储配合LSM技术，本发明实施例设计并实现了一个对于大小文件均有较好性能的Chunkserver。在SepStore中，大文件将被存储成本地文件以充分利用本地文件系统对于顺序写的特点，而小文件将被存储在一个采用了LSM的KV数据库中以提高读写性能。鉴于写流程较为复杂，将以写流程为例说明整个系统的读写流程，改进之后整个系统的写流程包括以下步骤：

S1，客户端发起写请求，并将相关参数(文件名，位移等)发给元数据管理服务器20。

S2，如果文件不存在，则意味着这是一个新建操作。元数据管理服务器20会给文件分配fileid(SepStore使用了一个全局递增的64位整数来分配该值)，chunkid，并综合考虑现有Chunkserver的数量、使用情况等决定数据放置位置，最后将相关信息返回客户端。否则，Meta Server(Master)会将根据chunkid查到chunk server的IP、port直接返回给客户端。

S3，客户端将数据发送给Chunkserver。如果文件已经存在则直接生成一个任务放入工作池当中，否则，则意味着这是一个新建的chunk操作，Chunkserver需要决定文件的放置位置，即放在KV Region中还是直接存储在文件系统上。在决定了放置位置后，Chunkserver会给文件分配相应的元数据信息。

S4，Chunkserver维护了一个线程池来完成工作池里面的工作。工作池里面有两种工作，一种是对于File Region的写操作，另一种则是对于KV Region的写操作。

S5，Chunkserver将处理结果返回客户端。客户端会根据结果决定重试或者通知元数据管理服务器20修改相关元数据。

需要说明的是，读流程与写流程非常相似，区别在于步骤S3可以直接查找数据位置，并在步骤S4完成数据读取，为了减小冗余，在此不做详细赘述。

当今分布式文件系统大多直接依赖于本地文件系统提高磁盘管理功能。然而，在分布式文件系统中，数据服务器上的数据访问过程存在着不少不必要的开销，例如数据块存放地址的定位开销。本发明实施例将key-value数据库、LSM技术和本地文件系统结合起来，对文件按照大小进行区分，并特别针对小文件的读写进行优化，减少全局的随机读写，从而实现整体性能的提升。其中，小文件将会被存储在采用LSM技术的key-value数据中，而大文件将被切分成固定大小的数据块以普通文件的方式存放在本地文件系统上，实现了一个分布式文件系统原型SepStore，并通过实验验证了优化方案的有效性。实验结果显示，SepStore对于小文件的写操作速度可提高210％。在大小文件混合的负载下，整体吞吐可以提升78％，整体IOPS(Input/Output Operations Per Second，每秒进行读写(I/O)操作的次数)可以提升37％。

根据本发明实施例提出的分布式文件系统的数据存储方法，通过将数据文件按照大小进行区分，如果数据文件的大小小于一定值，则将数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库，并且如果数据文件的大小大于一定值，则将数据文件切分为多个子数据文件，并存储至本地文件系统，以及特别针对小文件的读写进行优化，从而提高分布式文件系统的效率，优化分布式文件系统的数据访问效率，实现整体性能的提升。

其次参照附图描述根据本发明实施例提出的分布式文件系统的数据存储系统。参照图7所示，该系统1000包括：接收模块100、判断模块200、第一存储模块300和第二存储模块400。

其中，接收模块100用于接收用户发送的数据文件。判断模块200用于判断数据文件的大小。如果数据文件的大小小于预设值，第一存储模块300用于将数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库。如果数据文件的大小大于预设值，第二存储模块400用于将数据文件切分为多个子数据文件，并存储至本地文件系统。本发明实施例的存储系统1000将基于LSM(Log-Structure Merge)Tree的KV存储技术和本地文件系统结合起来，实现对于分布式文件系统数据访问效率的提升。

优选地，在本发明的一个实施例中，预设值可以为64MB。需要说明的是，改预设值仅是出于示例的目的，预设值即预设大小并不限定于此。

首先，参照图2所示，本发明实施例保留了MooseFS的整体架构、元数据服务器MooseFS中称为Master，或为Metadata Server)和客户端的大部分代码，实现了一个新的数据服务器。其中，MooseFS的结构与GFS类似，由多个客户端10(Clients)、元数据管理服务器20(Master)和多个数据服务器30(Chunkserver)构成，每个部分承担的功能也与GFS类似。

具体地，在本发明的实施例中，每个部分承担的功能如下：

·多个客户端10中的客户端负责将整个分布式文件系统的资源虚拟化，利用FUSE对外提供POSIX接口。一旦使用客户端挂载后，应用可以像使用本地磁盘一样使用MooseFS。

·元数据管理服务器20负责管理元数据信息，决定数据的放置策略，维护整个系统的运行。其中，一旦Master宕机后整个服务也将停止。为了保护元数据的可靠性，MooseFS还设计了一个Metadatalogger(元数据日志服务器)，从而对元数据的操作进行实时备份。

·多个数据服务器30中的Chunkserver负责数据在磁盘上的存储。其中，Chunkserver的实现依赖于一个用户态的进程，底层的存储则依赖本地文件系统。

进一步地，在本发明的一个实施例中，参照图8所示，上述存储系统1000还包括：Key生成模块500。其中，Key生成模块500用于根据数据文件的数据块ID、数据块版本、数据块序号生成数据文件的Key。

进一步地，在本发明的一个实施例中，参照图8所示，上述存储系统1000还包括：文件名生成模块600。文件名生成模块600用于根据每个子数据文件的数据块ID和数据块版本生成多个子数据文件对应的本地文件系统的文件名。

具体地，在本发明的一个实施例中，MooseFS的数据读写流程和存储方案也与GFS类似。对于大文件MooseFS将按照64M(编译时决定，默认64MB)大小进行切块，分成多个chunk(数据块，相当于分成多个子数据文件)存到不同的Chunkserver上。对于小文件MooseFS则当做一个单独的Chunk存放到Chunkserver上。每个chunk都对应着Chunkserver上文件系统的一个实际文件。元数据管理服务器20维护了从文件名到chunk列表的对应关系，chunk的标识是一个64位的chunkID(数据块ID)。在进行数据读写的时候，客户端会先向元数据管理服务器20请求文件对应的chunk的chunid和chunk所在的Chunkserver的IP和端口号。客户端拿到这些信息后会向指定的Chunkserver发出数据读写请求。如果是读操作，客户端从指定的Chunkserver完成数据读取即可。如果是写操作，客户端需要将待写数据传给一个Chunkserver，该Chunkserver在完成本地磁盘的读写的同时会将数据转发给其它副本所在数据服务器。当客户端收到Chunkserver传来的写操作的结果后需要到Master确认元数据信息的更改或者写操作的失败。

进一步地，在本发明的一个实施例中，参照图3所示，本发明实施例的数据文件按照不同的大小提供不同的存储方案，并针对小文件提供LSM技术配合key-value数据库的方案，从而带来整体效能的提升。具体地，在SepStore中，对于大文件将按照固定的大小例如64MB进行切分并将chunk放在不同的服务器上，而小文件则被认为一个单独的chunk。最终Chunkserver上存在三种大小的文件，一种是小于大小预设值T的被认为是小文件，一种是介于T和64MB之间的，最后一种则是64MB的文件。T的选择是一个关键问题，本发明实施例根据实验选取64KB作为T的大小，但是在实际应用中，应当根据应用场景来选择。SepStore中的Chunkserver将分别为第一种文件和第二、第三文件提供有针对性的存储方案。本发明实施例通过基于LSM(Log-Structure Merge)Tree的KV存储技术和本地文件系统相结合，从而优化分布式文件系统数据访问效率。

具体地，SepStore的Chunkserver结构如图3所示。其中，SepStore的Chunkserver分为三部分：一部分是File Region，其用于存储较大的文件即大于T(即T用来区分文件是放到File Region还是KV Region的界限值，在SepSotre中T默认为64KB，接下来提到的T若无特殊说明一律为64KB)小于64MB的文件；另一部分则是KV Region，其主要用于存储小文件即小于T的文件；最后一部分则是Metadata Region，其用于存储数据服务器上的chunkid、version(数据块版本)等元数据信息。本发明实施例将大于T的文件存入Fileregion，小于T的文件存入KV region，但是这种划分并不是绝对的，例如存放于KV Region的小文件可能在一次写操作后体积变得大于T，当出现这种情况时，数据并不会立即被迁移而是会被暂时切分成多个KV对，真正的迁移操作则由后台线程异步完成。

进一步地，Chunkserver对外提供统一的访问接口，主要包括read、write和delete。具体地，在接到客户端请求后，Chunkserver会生成任务放入到任务池中，任务队列是一个先进先出的队列，任务之间并没有优先级差别。Chunkserver维护了一个线程池来处理任务池中的任务，读写任务都是异步完成的。其中，在运行时，所有的元数据都会被加载到内存当中，并被组织成一个巨大的哈希表，chunkid则是哈希表的输入值。Chunkserver除了响应客户端的数据请求外，还会定时向Master汇报本地的磁盘使用情况、错误情况等信息。

进一步地，在本发明的一个实施例中，参照图4所示，与本地文件系统不同，KV Region提供的是一个扁平化的命名空间。其中，每个key-value对都有唯一的Key，数据库利用Key来实现数据的定位。在KV Region的设计中，本发明实施例并没有保存Key值，而是设计了一种简单的算法来生成Key。具体地，每个chunk的Key组成如图所示，由chunkid(数据块ID)，version(数据块版本)和blocknum(数据块序号)共同构成。其中chunkid和version都是由客户端直接传过来的信息，blocknum则用来当前的key-value对在整个chunk中的位置。每个block的大小是固定例如为64KB，故blocknum可以通过下列公式blocknum＝offset％64KB得到。

进一步地，在本发明的一个实施例中，参照图5所示，在分布式环境下，为了实现基于本地文件系统的数据读写功能，SepStore需要维护一些额外的元数据信息来实现从chunkid到系统文件的映射。与KVRegion的设计一样，在File Region中，本发明实施例并没有直接将chunkid到本地文件的映射信息保存，而是采用了一个简单的算法来实现数据的寻址功能。具体地，每个chunk对应的本地文件系统的文件名是由chunid，version构成，其结构如图所示，这种将元数据信息隐含在文件名字中的做法有两个好处：

·可以实现从chunkid到数据的快速定位。

·SepStore开启了一个后台线程定期对所有File Region所有文件进行扫描，并利用文件名包含的信息来验证数据的一致性。

为了提高文件的读取性能，File Region采取了以下优化措施：

(1)相较于本地文件系统更加有效的缓存策略，SepStore在文件系统之上维护了对于block的数据缓存并实现了LRU(Least Recently Used，最少使用页面置换算法)策略。

(2)目录间的数据负载均衡。大多数文件系统都使用B+树或者其变种来维护数据的索引，这些索引结构的均衡性较好，但不能很好的处理同一目录下文件过多的情况。同时，如果目录深度过多则会增加chunkserver的元数据负担。因此希望能保证目录层数尽量少的前提下尽量将文件均衡分布。SepStore采用了一个简单的策略来实现文件的均衡分布。在根目录下，SepStore将默认创建256个子目录，chunk的位置则通过chunkid％256来决定文件的子目录位置。

其中，在本发明的一个实施例中，参照图8所示，上述存储系统1000还包括：校验码生成模块700。其中，校验码生成模块700用于根据每个子数据文件中数据块生成对应的校验码，以维护子数据文件。即言，File Region与KV Region的一个不同在于File Region为每个chunk维护了一个校验码，每4KB有一个字节的校验数据。

进一步地，在本发明的一个实施例中，参照图6所示，通过利用KV存储配合LSM技术，本发明实施例设计并实现了一个对于大小文件均有较好性能的Chunkserver。在SepStore中，大文件将被存储成本地文件以充分利用本地文件系统对于顺序写的特点，而小文件将被存储在一个采用了LSM的KV数据库中以提高读写性能。鉴于写流程较为复杂，将以写流程为例说明整个系统的读写流程，改进之后整个系统的写流程包括以下步骤：

S1，客户端发起写请求，并将相关参数(文件名，位移等)发给元数据管理服务器20。

S2，如果文件不存在，则意味着这是一个新建操作。元数据管理服务器20会给文件分配fileid(SepStore使用了一个全局递增的64位整数来分配该值)，chunkid，并综合考虑现有Chunkserver的数量、使用情况等决定数据放置位置，最后将相关信息返回客户端。否则，Meta Server(Master)会将根据chunkid查到chunk server的IP、port直接返回给客户端。

S3，客户端将数据发送给Chunkserver。如果文件已经存在则直接生成一个任务放入工作池当中，否则，则意味着这是一个新建的chunk操作，Chunkserver需要决定文件的放置位置，即放在KV Region中还是直接存储在文件系统上。在决定了放置位置后，Chunkserver会给文件分配相应的元数据信息。

S4，Chunkserver维护了一个线程池来完成工作池里面的工作。工作池里面有两种工作，一种是对于File Region的写操作，另一种则是对于KV Region的写操作。

S5，Chunkserver将处理结果返回客户端。客户端会根据结果决定重试或者通知元数据管理服务器20修改相关元数据。

需要说明的是，读流程与写流程非常相似，区别在于步骤S3可以直接查找数据位置，并在步骤S4完成数据读取，为了减小冗余，在此不做详细赘述。

当今分布式文件系统大多直接依赖于本地文件系统提高磁盘管理功能。然而，在分布式文件系统中，数据服务器上的数据访问过程存在着不少不必要的开销，例如数据块存放地址的定位开销。本发明实施例将key-value数据库、LSM技术和本地文件系统结合起来，对文件按照大小进行区分，并特别针对小文件的读写进行优化，减少全局的随机读写，从而实现整体性能的提升。其中，小文件将会被存储在采用LSM技术的key-value数据中，而大文件将被切分成固定大小的数据块以普通文件的方式存放在本地文件系统上，实现了一个分布式文件系统原型SepStore，并通过实验验证了优化方案的有效性。实验结果显示，SepStore对于小文件的写操作速度可提高210％。在大小文件混合的负载下，整体吞吐可以提升78％，整体IOPS可以提升37％。

根据本发明实施例提出的分布式文件系统的数据存储系统，通过将数据文件按照大小进行区分，如果数据文件的大小小于一定值，则将数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库，并且如果数据文件的大小大于一定值，则将数据文件切分为多个子数据文件，并存储至本地文件系统，以及特别针对小文件的读写进行优化，从而提高分布式文件系统的效率，优化分布式文件系统的数据访问效率，实现整体性能的提升。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在不脱离本发明的原理和宗旨的情况下在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种分布式文件系统的数据存储方法，其特征在于，包括以下步骤：

接收用户发送的数据文件；

判断所述数据文件的大小；

如果所述数据文件的大小小于预设值，则将所述数据文件通过基于日志格式的归并树LSM-Tree的KV存储方法存储至云端服务器的key-value数据库；以及

如果所述数据文件的大小大于所述预设值，则将所述数据文件切分为多个子数据文件，并存储至本地文件系统。

2.根据权利要求1所述的分布式文件系统的数据存储方法，其特征在于，在所述将所述数据文件通过LSM-Tree的KV存储方式至云端服务器的key-value数据库中之后，还包括：

根据所述数据文件的数据块ID、数据块版本、数据块序号生成所述数据文件的Key。

3.根据权利要求1所述的分布式文件系统的数据存储方法，其特征在于，在所述将所述数据文件切分为多个子数据文件，并存储至本地文件系统之后，还包括：

根据每个子数据文件的数据块ID和数据块版本生成所述多个子数据文件对应的本地文件系统的文件名。

4.根据权利要求3所述的分布式文件系统的数据存储方法，其特征在于，还包括：根据所述每个子数据文件中数据块生成对应的校验码，以维护子数据文件。

5.根据权利要求1所述的分布式文件系统的数据存储方法，其特征在于，所述预设值为64MB。

6.一种分布式文件系统的数据存储系统，其特征在于，包括：

接收模块，用于接收用户发送的数据文件；

判断模块，用于判断所述数据文件的大小；

第一存储模块，如果所述数据文件的大小小于预设值，用于将所述数据文件通过基于LSM-Tree的KV存储方法存储至云端服务器的key-value数据库；以及

第二存储模块，如果所述数据文件的大小大于所述预设值，用于将所述数据文件切分为多个子数据文件，并存储至本地文件系统。

7.根据权利要求6所述的分布式文件系统的数据存储系统，其特征在于，还包括：

Key生成模块，用于根据所述数据文件的数据块ID、数据块版本、数据块序号生成所述数据文件的Key。

8.根据权利要求6所述的分布式文件系统的数据存储系统，其特征在于，还包括：

文件名生成模块，用于根据每个子数据文件的数据块ID和数据块版本生成所述多个子数据文件对应的本地文件系统的文件名。

9.根据权利要求8所述的分布式文件系统的数据存储系统，其特征在于，还包括：

校验码生成模块，用于根据所述每个子数据文件中数据块生成对应的校验码，以维护子数据文件。

10.根据权利要求6所述的分布式文件系统的数据存储系统，其特征在于，所述预设值为64MB。