CN113377868A - 一种基于分布式kv数据库的离线存储系统 - Google Patents

Abstract

本发明公开了一种基于分布式KV数据库的离线存储系统，本发明包括客户端和服务端，所述服务端包括元数据中心和离线存储中心，所述离线存储中心包括若干数据节点。本发明提供了一种基于固态硬盘存储的分布式KV数据库的离线存储系统，本发明系统实现了高性能的数据查询和写入，提供了分片式的存储机制，可以自适应的负载均衡数据迁移，对运维的压力较小，数据库扩容时几乎可以不需人力介入，大大降低了后期的数据库的改造成本。

Description

一种基于分布式KV数据库的离线存储系统

技术领域

本发明涉及数据库技术领域，具体地说是一种分布式KV数据库系统。

背景技术

随着互联网的发展，互联网数据规模的不断扩大，很多情况下传统的数据库已经无法满足互联网企业的需求，Hadoop HDFS的出现以及一些NoSQL数据库的诞生等解决了海量数据存储查询的需求，但是失眠上大部分NoSQL数据库，如Redis、MongoDB数据库因为内存依赖比较严重，无法做到底成本的快速扩容，随着固态硬盘技术的成熟，在随机IO读写能力上大幅度提升，因此一些基于固定硬盘的存储引擎出现了，Google的LevelDB和FaceBook的RockSDB，还有AeroSpike等以SSD存放数据为主的存储引擎出现了，因为固定硬盘作为存储相对于内存存储成本更低，因此可以通过固态硬盘较小的IO延迟来做到更廉价的扩容。Mola一个分布式存储引擎采用Key-Value存储形式，适用于可扩展性强、访问并发性强的业务，如果使用Mola进行存储，由于底层采取comdb进行存储造成资源浪费严重，另外mola的组件过于复杂，相关依赖的模块有十几个组件，因此给数据库运维工程师们造成了极大的运维压力与运维困难。因此在现有环境下需要一个低成本的基于固态硬盘存储的分布式KV数据库进行离线存储。

发明内容

本发明的目的是针对以上不足，提供一种基于分布式KV数据库的离线存储系统，采用低成本的固态硬盘的存储的方式，降低数据库的复杂程度，降低运维困难程度。

本发明所采用技术方案是：

一种基于分布式KV数据库的离线存储系统，包括客户端和服务端，所述服务端包括元数据中心和离线存储中心，所述离线存储中心包括若干数据节点，其中：

所述元数据中心用于保存集群的元数据，且提供集群元数据管理分发；

所述离线存储中心用于集群数据的离线存储，且通过分布式存储的方式存储在每个数据节点中；

元数据中心和离线存储中心均与客户端建立通讯链接，客户端先从元数据中心获取访问数据库所需的元数据，再通过获取的元数据与离线存储中心进行通信，访问数据，离线存储中心之间的数据节点之间也存在通讯连接；

所述离线存储中心与Hadoop的HDFS之间建立有通讯链接，通过数据下载器定时监听HDFS的数据目录，下载最新的数据文件到离线存储中心的数据库中。

作为进一步的优化，本发明所述数据节点的存储架构包括接口层、缓存层和存储层，其中：

所述接口层用于建立外部连接，包括与客户端的连接、与其他数据节点之间的连接和与原数据中心的连接；

所述缓存层用于数据库的读取缓存，提升数据返回速度，降低磁盘读盘次数；

所述存储层用于进行数据离线存储。

作为进一步的优化，本发明还配置有离线存储检索引擎，所述离线存储检索引擎的离线存储的只读索引在外部对key进行排序，组织成树形索引，树形索引中叶子节点为内容，索引文件通过4K进行内存对齐。

作为进一步的优化，本发明所述数据下载器监听HDFS目录下是否有新版本数据，如果有就新建一个数据对象并且设置为等待下载的状态并且进入到下载阶段，提交到任务队列中，在数据下载阶段会检测当前数据是否为正在下载的状态，如果正在下载或时当前数据以下载完毕会跳过当前任务重新进行扫描；如果没有新版本数据就结束流程；数据下载器下载的数据通过数据导入期从临时目录移动到装载目录中，进行等待数据装载，在正式进行数据装载之前，首先会通过当前的元数据来判断当前分区是否在自身节点上以及该数据的版本是否是元数据中的目标版本，如果不在说明在下载的过程中可能发生了rebalance或者当前数据是一个过期的数据，这个时候就会停止装载数据，把数据状态设置为等待卸载状态等待后续的数据删除，如果是一个符合版本的数据，那么会通过连接请求使执行数据装载，当数据装载成功之后进入已装载状态，当检测到新版本数据装载到服务组件中，此时会通知服务组件卸载数据进入等待卸载状态等待后续的数据删除操作。

作为进一步的优化，本发明数据导入器通知服务组件的卸载数据，服务组件不会立即卸载数据，服务组件需要等待数据库分片占用的共享锁释放后才会返回给数据导入器，同时把数据对象设置为卸载状态此时数据处于一种等待删除的状态，此时会需要重新确认分区和版本信息，并且进入到等待删除的状态，当磁盘空间不足或超过一段时间，数据将会被删除。

作为进一步的优化，本发明所述缓存层采用LRU缓存策略，每次查询数据库之前都会有限查询LRU缓存，当查询到对应的数据时就不再需要执行后续的查询逻辑，直接返回给调用方，且将所述LRU缓存采用哈希表和链表结构的方式。

作为进一步的优化，本发明所述存储层的数据文件拍列表包括文件头、协议层、数据长度、解压层和数据内容，所述协议层中引入数据压缩功能，并配置有数据压缩算法，且所述解压层与协议层所配置的数据压缩算法为相匹配的解压算法。

作为进一步的优化，本发明所述存储层包括DataBlock、Index、IndexTree、SDBPartition和SDBTable，所述DataBlock是数据文件类，根据索引查到的偏移量进行具体的值的查询，IndexTree是索引层，是多个Index的聚合，SDBTable是表类，跟SDBPartition是聚合关系，多个分区聚合成了一个表，且设置有SDBTableManager用于管理SDBTable的类，负责SDBTable整个生命周期的管理。

本发明具有以下优点：

1、本发明提供了一种基于固态硬盘存储的分布式KV数据库的离线存储系统，本发明系统实现了高性能的数据查询和写入，提供了分片式的存储机制，可以自适应的负载均衡数据迁移，对运维的压力较小，数据库扩容时几乎可以不需人力介入，大大降低了后期的数据库的改造成本；

2、本发明采用大数据Lambda架构，且采用离线存储的方式，其离线存储与Hadoop生态异常密切，可以从Hadoop HDFS中导入，生成数据库文件，通过监听HDFS的新版本数据，宝胜数据及时的更新；

3、本发明使用brpc提供对外服务，通过多副本冗余存储来提高系统的可靠性，可以实现海量数据下较低成本的数据库扩缩容。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

下面结合附图对本发明进一步说明：

图1为本发明系统的主体架构示意图；

图2为检索引擎的树形图；

图3为本发明离线存储的关于表和分区的类架构图；

图4为本发明离线存储对外接口的架构图；

图5为Reducer处理单个分区数据的示意图；

图6为MapReduce相关类架构图；

图7为本发明系统的主题架构的细化架构图；

图8为离线存储下载器数据下载的流程示意图；

图9为离线存储数据下载器的UML类的架构图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好地理解本发明并能予以实施，但所举实施例不作为对本发明的限定，在不冲突的情况下，本发明实施例以及实施例中的技术特征可以相互结合。

需要理解的是，在本发明实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。在本发明实施例中的“多个”，是指两个或两个以上。

本发明实施例中的属于“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”关系。

本实施例提供一种基于分布式KV数据库的离线存储系统，如图1所示，包括客户端和服务端，所述服务端包括元数据中心Master和离线存储中心DateNote，所述离线存储中心包括若干数据节点，其中：

所述元数据中心用于保存集群的元数据，且提供集群元数据管理分发；

所述离线存储中心用于存储离线数据，具体的，海量的离线数据均存储在每个DataNode中，DataNode根据具体部署的存储类型离线存储；

元数据中心和数据节点均与客户端建立通讯链接，客户端先从元数据中心获取访问数据库所需的元数据，再通过获取的元数据与数据节点进行通信，访问数据；

所述数据节点与Hadoop的HDFS之间建立有通讯链接，通过数据下载器定时监听HDFS的数据目录，下载最新的数据文件到数据库中。

本实施例所述离线存储中心包括接口层、缓存层和存储层，其中接口层对接提供接口，包含了对客户端的RPC接口和与Master或其他DataNode进行通信的接口，缓存层是数据库的缓存，可以有效降低数据库读盘次数，存储层是数据存储的离线存储地址。

作为相应的配套，本实施例的离心存储配置的离线存储检索引擎，现有的单机引擎不能完全满足离线存储的要求，本实施例的离线存储只读索引需要在外部对key进行排序，，然后组织呈树形索引，树形索引中的叶子节点为内容。可以配置最后一级索引、数据文件是否强制放置在内存，并且保证最后一级索引数的一个树节点落在同一个内存分页中。保证进行最后一级检索时最多访问一次磁盘。利用mmap返回数据指针，进行数据读取过程(不包括查找)最多访问一次磁盘，中间不存在内存拷贝。

离线存储因为是只读的所以在检索过程中不会涉及索引变更，在BS存储引擎中，每个分区是一个数据目录，数据目录中是分为数据文件和索引文件，每个数据目录包括data、mem.index、ssd.index三个文件，data是数据文件DataFile，mem.index是内存索引，图2中MEMIndexlevel_0，里面存储的数据主要是hash之后的key到ssd索引的一个映射值；ssd.index是ssd索引，里面存储的数据主要是hash之后的key到数据文件偏移量的一个映射值，无论是mem.index还是ssd.index里面所有的key都是有序的，目的是为了二分查找。

本实施例的SSD(固态硬盘)索引参照内存索引还是采用4k对其的方式，这样做的好处是让每次查询的时候可以减少跨页读取，减少读取长尾问题。内存索引会对自身建立层级索引，同样采取4k对齐的方式。

查询的流程类似B+树，每4k大小可以看成一个B+树的节点，最开始从第n层内存索引开始查询，查询开始的时候从顶层的索引开始查询，每一层索引都会通过二分查找找到最后一个不大于需要查询的key，然后通过offset查找n-1层的索引，依此类推，最终就可以通过在SSD的偏移量就可以查询到在DataFile中的具体数据。

对数据文件产生的B+树索引是通过Hash紧密的排列在SSD文件，索引在内存不存在空闲内存碎片，因此索引占用内存比较小。数据文件紧密排列，数据膨胀率约等于1，最坏情况下的访问时延可控，平均访问时延较低。

离线存储引擎主要是检索历史数据，只提供读操作，不提供写操作，这样在实现查询的时候基本都是读操作不需要获取额外的锁，因此查询操作性能非常高

离线存储由于是只读的，因此在查询过程中没有锁竞争，因此查询效率很高，另外索引文件和数据文件会通过磁盘映射文件进行查询，因为索引文件通过4k进行内存对齐，最好和最坏都是两次读取SSD，一次是查询SSD索引文件获取value在数据文件的偏移位置，一次是查询数据文件获取数据的值。

本实施例的数据排列表如下表所示，文件头为8bytes，用于程序判断数据文件版本，Protocol Mask主要是为了引入数据压缩功能，这样可以配置不同的数据压缩算法。之后接着每一个Data Length代表接下来的数据长度，然后是具体的数据内容。

离线存储的部分关于表和分区的类设计如图3所示，SDBTable是表类，跟SDBPartition是聚合关系，多个分区聚合成了一个表。IndexTree是索引层，是多个Index的聚合，IndexTree的vector是多层Index，DataBlock是数据文件类，根据索引查到的偏移量进行具体的值的查询。

离线存储对外接口的类以及相关实现如图4所示，其中QueryService为对用户和对数据下载器的接口。其中对用户提供了get/set方法，对数据下载器提供数据卸载，数据装载的方法。QueryServiceImpl是QueryService的具体实现，由SDBTableManager组合。SDBTableManager是管理SDBTable的类，负责SDBTable整个生命周期的管理。

离线存储中心的数据导入接口是Hadoop SequenceFile文件，输入是需要灌库的Key和Value，本实施例中关于离线存储数据文件MapReduce中Map任务负责把数据从SequenceFile格式的KV读取，然后把Key进行哈希。并且把哈希之后的key和读入的value输出到中间结果。MapReduce中需要进行自定义的排序和自定义分区把数据的结果传递给Reducer进行处理Reducer的数量需要跟分区数量相同。这是因为每个Reducer只处理单个分区的数据，如图5所示，MapReduce的分区方法需要使用自定义分区方式，采取murmurhash再对分区数量取模运算，保证跟查询时分区相同。

MapReduce相关类设计如图6所示，SDBMapper和SDBReducer分别是MapReduer中主要实现。SDBWritter主要负责数据写入到HDFS具体的相关操作。

本实施例的离线存储中心的数据都是从HDFS上导入的，离线存储服务需要把数据从Hadoop HDFS下载到本地的数据目录，因此需要对离线存储设计数据导入器。由于Java对Hadoop提供相关API支持较好，因此使用异构多进程模块的方式来设计离线存储。即使用C++模块用于处理查询相关的逻辑，Java模块用于从Hadoop HDFS下载由MapReduce生成的数据库相关文件。进程之间用RPC进行通信，这样做的好处是可以充分利用Java对接HadoopHDFS接口的原生优势，又不需要承担客户端查询过程中需要承担垃圾回收造成的时停影响。

如图7所示，作为对图1系统的进一步的优化，。客户端直接请求的服务称为queryservice，由C++编写。数据导入器在本文中称为importer，主要负责跟Master进行通信，从HDFS中下载数据，数据验证，以及通知QueryService进行数据装载，importer和queryserver同样使用brpc进行通信，一些元数据会持久化到磁盘目录中，方便重启时恢复元数据。

因为数据下载涉及到数据状态跟踪，因此使用有限状态机来描述整个数据下载流程，状态机整体流程如图8所示，对于每一个需要下载的数据，设计成有限状态机处理，方便追踪数据在每一阶段需要执行什么样的逻辑，主要将数据流分为三个阶段，第一个阶段是任务扫描阶段，通过监听HDFS目录下是否有新版本数据，如果有就新建一个数据对象并且设置为等待下载(wait_download)的状态并且进入到下载阶段，提交到任务队列中，如果没有就结束流程，在数据下载阶段会检测当前数据是否是正在下载的状态，如果正在下载或者是当前数据会跳过当前任务(skip_download)等待重新扫描，当数据任务下载好并且进行通过校验，数据导入器会把数据从临时目录移动到装载目录，就会设置为下载完成状态(downloaded)进入第三阶段等待进行数据装载，在正式进行数据装载之前，首先会先通过当前的元数据来判断当前分区是否在自身节点上以及该数据的版本是否是元数据中的目标版本，如果不在说明在下载的过程中可能发生了rebalance或者当前数据是一个过期的数据，这个时候就会停止装载数据，把数据状态设置为等待卸载状态(WAIT_UNLOADED)等待后续的数据删除，如果是一个符合版本的数据，那么会通过rpc请求使queryservice执行数据装载，当数据装载成功之后进入已装载状态(loaded)，当检测到新版本数据装载到queryservice中，此时会通知queryservice卸载数据进入等待卸载状态(wait_unload)等待后续的数据删除操作，通常情况下数据导入器通知queryservice的卸载数据，queryservice不会立即卸载数据，此时queryservice需要等待数据库分片占用的共享锁释放(实际实现中采取RAII+shared_ptr，智能指针也可以看作是一种共享锁)才能释放才会返回给数据导入器，同时把数据对象设置为卸载状态(unload)此时数据处于一种等待删除的状态，此时会需要重新确认分区/版本信息，并且进入到等待删除的状态，当磁盘空间不足或超过一段时间，数据将会被删除。

针对于上述流程，本实施例离线存储数据下载器的UML类图9所示，其中ImporterController为下载器的控制器，syncMeta是提供给Master调用的元数据同步接口，dumpMeta是把元数据保存到磁盘中，handle方法是处理离线数据下载状态机的逻辑。采取策略模式，分别调用三个阶段的策略处理数据下载流程的状态机；DataScaner是HDFS的包装类，主要负责扫描HDFS目录下是否有新数据目录产生，并加到ImporterController中TableContext列表。

缓存在数据库重有着非常重要的作用，经过综合考虑，因此引入LRU缓存，采用哈希表+链表的方式。LRU是一种缓存淘汰策略。由于计算机的缓存容量有限的，因此当缓存容量满足就需要淘汰一些内容，给新加入的数据提供容量空间。LRU的全称是Least RecentlyUsed，也就是说我们认为最近使用过的数据应该是最有可能在以后命中的，很久都没用过的数据在以后访问的概率较低，因此当内存满了就需要优先删那些很久没用过的数据。

离线存储引擎引入LRU缓存，每次在查询数据库之前都会先查询LRU缓存，如果查询到对应的数据就不需要执行后续的查询逻辑，直接返回给调用方。每次在更新缓存的时候会把数据插入到缓存中。每个分区只需要持有一个缓存即可，缓存的并发保证可以采用分区锁来控制，每次访问缓存需要获取分区锁。

为了验证本实施例所提供离线存储服务系统的实用效果性，对其进行离线存储服务测试，主要测试离线服务下载性能、grt功能的完善性以及分布式存储的容错性，离线存储服务器的测试环境如下：

1.测试环境1

测试环境：内存*40G,CPU*100归一化核，NVME-SSD独占，NET-IO IN/OUT300MB/s实例数目*3。

测试数据：value：5KB读写比例为5：1，数据量100W。

2.测试环境2

测试环境：内存*4G,CPU*50归一化核，NVME-SSD独占，NET-IO IN/OUT300MB/s实例数目*10

测试方法：

测试数据：数据量100W，value：5KB读写比例为5：1，使用压力测试工具进行压测，分别使用定量压测和极限压测，直到出现性能瓶颈持续10分钟。

针对上述三种测试环境，所测试的内容如下：

测试结果如下：

性能表现原因分析：

测试数据为5K大小，单磁盘最大的极限写入量为qps*value_size＝150MB/S,远远低于NVME的IO能力。数据量使用率低于50％，没有达到SimpleDB RS的GC标准，几乎没有磁盘GC的IO压力。

离线存储的性能对比测试如下表所示：

过协程优化和锁粒度优化，平均响应时延明显降低。

离线存储保证了数据库中数据的最终一致性，由于是使用多副本进行存储，数据库的可用性，可靠性都由良好的保证。支持自动化故障转移和负载平衡。作为一种海量数据的KV存储系统，无论是存储存储成本还是访问延时对比基于LSM数据库来说都是有更好的解决方案。对于纯内存的数据库来说访问延迟会更高但存储成本和服务器资源消耗都低很多。

以上所述实施例仅是为充分说明本发明而所举的较佳的实施例，本发明的保护范围不限于此。本技术领域的技术人员在本发明基础上所作的等同替代或变换，均在本发明的保护范围之内。本发明的保护范围以权利要求书为准。

Claims (8)

1.一种基于分布式KV数据库的离线存储系统，其特征在于：包括客户端和服务端，所述服务端包括元数据中心和离线存储中心，所述离线存储中心包括若干数据节点，其中：

所述元数据中心用于保存集群的元数据，且提供集群元数据管理分发；

所述离线存储中心用于集群数据的离线存储，且通过分布式存储的方式存储在每个数据节点中；

元数据中心和离线存储中心均与客户端建立通讯链接，客户端先从元数据中心获取访问数据库所需的元数据，再通过获取的元数据与离线存储中心进行通信，访问数据，离线存储中心之间的数据节点之间也存在通讯连接；

所述离线存储中心与Hadoop的HDFS之间建立有通讯链接，通过数据下载器定时监听HDFS的数据目录，下载最新的数据文件到离线存储中心的数据库中。

2.根据权利要求1所述的系统，其特征在于：所述数据节点的存储架构包括接口层、缓存层和存储层，其中：

所述接口层用于建立外部连接，包括与客户端的连接、与其他数据节点之间的连接和与原数据中心的连接；

所述缓存层用于数据库的读取缓存，提升数据返回速度，降低磁盘读盘次数；

所述存储层用于进行数据离线存储。

3.根据权利要求2所述的系统，其特征在于：还配置有离线存储检索引擎，所述离线存储检索引擎的离线存储的只读索引在外部对key进行排序，组织成树形索引，树形索引中叶子节点为内容，索引文件通过4K进行内存对齐。

4.根据权利要求3所述的系统，其特征在于：所述数据下载器监听HDFS目录下是否有新版本数据，如果有就新建一个数据对象并且设置为等待下载的状态并且进入到下载阶段，提交到任务队列中，在数据下载阶段会检测当前数据是否为正在下载的状态，如果正在下载或时当前数据以下载完毕会跳过当前任务重新进行扫描；如果没有新版本数据就结束流程；数据下载器下载的数据通过数据导入期从临时目录移动到装载目录中，进行等待数据装载，在正式进行数据装载之前，首先会通过当前的元数据来判断当前分区是否在自身节点上以及该数据的版本是否是元数据中的目标版本，如果不在说明在下载的过程中可能发生了rebalance或者当前数据是一个过期的数据，这个时候就会停止装载数据，把数据状态设置为等待卸载状态等待后续的数据删除，如果是一个符合版本的数据，那么会通过连接请求使执行数据装载，当数据装载成功之后进入已装载状态，当检测到新版本数据装载到服务组件中，此时会通知服务组件卸载数据进入等待卸载状态等待后续的数据删除操作。

5.根据权利要求4所述的系统，其特征在于：数据导入器通知服务组件的卸载数据，服务组件不会立即卸载数据，服务组件需要等待数据库分片占用的共享锁释放后才会返回给数据导入器，同时把数据对象设置为卸载状态此时数据处于一种等待删除的状态，此时会需要重新确认分区和版本信息，并且进入到等待删除的状态，当磁盘空间不足或超过一段时间，数据将会被删除。

6.根据权利要求5所述的系统，其特征在于：所述缓存层采用LRU缓存策略，每次查询数据库之前都会有限查询LRU缓存，当查询到对应的数据时就不再需要执行后续的查询逻辑，直接返回给调用方，且将所述LRU缓存采用哈希表和链表结构的方式。

7.根据权利要求6所述的系统，其特征在于：所述存储层的数据文件拍列表包括文件头、协议层、数据长度、解压层和数据内容，所述协议层中引入数据压缩功能，并配置有数据压缩算法，且所述解压层与协议层所配置的数据压缩算法为相匹配的解压算法。

8.根据权利要求7所述的系统，其特征在于：所述存储层包括DataBlock、Index、IndexTree、SDBPartition和SDBTable，所述DataBlock是数据文件类，根据索引查到的偏移量进行具体的值的查询，IndexTree是索引层，是多个Index的聚合，SDBTable是表类，跟SDBPartition是聚合关系，多个分区聚合成了一个表，且设置有SDBTableManager用于管理SDBTable的类，负责SDBTable整个生命周期的管理。

Images