CN112181950B - 一种分布式对象数据库的构建方法 - Google Patents

Abstract

本发明提供了一种应对复杂数据的分布式对象数据库ODB存储系统，单条数据即对象、数据库分片和主备及单条数据均支持弹性扩展、数据索引分离、高效底层存储通讯依赖Apache顶级项目Avro，整体系统包括ODB任务客户端模块、ODB读写服务模块、ODB索引模块和ODB底层存储模块，其中ODB任务客户端模块，用于提交对象查询和对象更新任务给ODB读写服务；ODB读写服务模块,用于接受任务客户端查询和更新请求，并同ODB索引模块及ODB底层存储模块交互；ODB索引模块，用于更新或快速查找单个或批量对象数据索引；ODB底层存储模块，用于接受查询和存储对象实例。

Description

一种分布式对象数据库的构建方法

技术领域

本发明属于计算机技术领域，具体涉及一种应对复杂数据的分布式对象数据库的构建方法。

背景技术

对象数据库(ODB，Object Database)，顾名思义是指面向对象的数据库——以对象和类的形式表示数据的数据库。在面向对象术语中，对象是真实的实体，类是对象的集合。面向对象数据库遵循面向对象编程的基本原则。简单讲，面向对象数据库＝面向对象编程+数据库，其特性如附图1所示，同时满足面向对象编程的继承、封装和多态，也满足基本数据库的读写、完整性和并发。ODB查询和存储更新的每条数据值都是一个完整的对象实例。

目前国内研究对象数据库的还比较少，大部分都是基于健值对存储的各种非关系数据库(NoSQL，Not Only SQL——Structured Query Language)，常用NoSQL有4类代表：

1)以MongoDB为代表的健值对存储的文档格式，查询和存储性能都比较出色，而且查询有多种索引模式支持，非常方便使用，但其单条数据目前最大不超过16M，对于当今一些相对复杂的业务支持有些力不从心。

2)以Hbase为代表的列示存储，存储层面优势明显，但其查询方式支持力度不够友好；

3)以Neo4J为代表的图数据库，存储关系网络，但目前图数据库在分布式方面都做的不太理想，单条数据一般都比较简单，而且查询效率在数据量大时性能大打折扣。

4)以TiDB为代表的NewSQL，提供了与NoSQL相同的可扩展性，而且仍基于关系模型，还保留了成熟的SQL作为查询语言，保证了ACID事务特性。简单讲，NewSQL就是在传统关系型数据库上集成了NoSQL强大的可扩展性。一般单条数据都比较简单。

相比较，对于当前一些需要快捷批量存取单条复杂数据类型的业务，上述各种数据库都存在一些明显的不足。比如，为方便推荐基础用户画像标签更新，往往需要以用户为单位把其指定时间段内的相关行为及访问次数和时间戳等数据聚合，当作一个整体看待。这个指定时间段一般可以设为天、周或月，这样原本在天、周或月时间段内每个用户有多达几十条、数百条、乃至数千条、上万条的散乱行为数据，就聚合为了一条具有密集行为的复杂数据，对于算法训练使用则变得更为方便；但同样，其存储也变得比较复杂，因为单条数据量很容易超过MongoDB单条数据最大16M的上限，如果强行拆分为更细粒度，则数据散乱不易控制，而且其文档结构格式：数据和结构融合在一起，会导致数据存储冗余，且浪费存储空间；如果存在Hbase，则因其本身查询支持不太友好，在多维度查询时不太方便。

目前国外有个开源的面向对象数据库Db4o，其存在如下缺点：

1)其主要为单机嵌入式应用，这就意味着其扩展性不够好，不能支持海量数据存储；

2)其次，其使用层面，在对对象存储时，并没有加入优化序列化存储技术支持，这就意味着其存储和反序列化解析存在一些效率低和数据冗余问题；

3)最近一次更新是2019-9-29，近4年，其官方基本停止更新维护。

发明内容

针对以上不足，本发明提供了一种应对复杂数据的分布式对象数据库存储系统及其构建方法，解决了上述背景技术中存在的问题。

本发明的技术方案为，一种应对复杂数据的分布式对象数据库存储系统，其中，在该存储系统中，单条数据即对象(无缝集成开发)、数据库分片和主备及单条数据均支持弹性扩展、数据索引分离、高效底层存储通讯依赖Apache顶级项目Avro。整体系统包括ODB任务客户端模块、ODB读写服务模块、ODB索引模块和ODB底层存储模块，其中:

ODB任务客户端模块，用于提交对象查询和对象更新任务给ODB读写服务；

ODB读写服务模块,用于接受任务客户端查询和更新请求，并同ODB索引模块及ODB底层存储模块交互；

ODB索引模块，用于更新或快速查找单个或批量对象数据索引；

ODB底层存储模块，用于接受查询和存储对象实例；

进一步地，其中ODB任务客户端模块包括单个对象更新子模块，批量对象更新子模块，单个对象查询子模块，批量对象查询子模块，监听读写服务子模块，批次调整子模块以及更新任务定向分发子模块，其中，在启动之初，通过Zookeeper监听ODB读写服务注册的节点，并定时检测其服务心跳，只有健康节点维持工作；对单个或批量查询任务，根据主键ID和时间范围参数提交给ODB读写服务模块的相应接口；对于数据更新方面，ODB任务客户端模块每次提交新任务给ODB读写服务模块时，都会检测当下可用节点的待计算任务个数，如果待计算任务个数<2的节点不存在，则sleep等待5秒，继续执行下一次请求，直到有空闲节点可用，再继续提交任务。

进一步地，其中ODB读写服务模块基于Thrift实现和ODB任务客户端模块的通讯，用于接受ODB任务客户端模块查询和更新请求，并同ODB索引模块及ODB底层存储模块交互，启动之初，通过Zookeeper监听ODB底层存储节点服务，并同时注册自身服务，供ODB任务客户端模块监听其动态。

进一步地，其中OBD读写服务模块包括第一对象查询子模块和第一对象更新子模块，

其中

第一对象查询子模块，

根据所接受的请求参数主键ID或时间戳范围，首先去ODB索引中查找过滤满足条件的子对象，根据查询规模大小，决定是否采用Fork/Join多线程并发调用，然后再调用基于Avro实现的RPC查询服务，批量获取每个ODB底层存储节点下的对象，再按照主键ID合并各来ODB存储节点下的子对象，再返回给上游调用方；

第一对象更新子模块，

对所接受的添加对象请求，将数据首先缓存到本地队列，同时有一个异步线程任务一直循环执行，如果发现当前节点尚有未执行完的任务处于忙碌状态，则sleep 5秒，跳过继续执行下个循环；如果发现当前服务节点空闲，无正在执行的计算任务，则将当前节点状态改为正在执行的忙碌状态，并立即从本地队列获取数据，完成相应业务逻辑，构建利用Avro设计的序列化对象，根据主键ID散列到指定ODB底层存储节点对应的队列，同时将对象索引更新到MongoDB，并调用Avro RPC批量提交给ODB底层存储，等执行完再更新节点计算状态为空闲。

进一步地，其中，ODB索引模块，其结构是按时间窗口划片，底层存储节点正常稳定运行时，一个对象只会存在一个固定的存储节点，若该节点故障，则会存到另一个存储节点。

进一步地，其中ODB底层存储模块，采用时间段“年周”目录结构，每个对象根据其活动周期，会散落到多个目录下，每个目录为一个独立表，其下就是文件目录，每个节点启动之初即通过Zookeeper注册自身服务节点，方便上游监听存储节点可用状态。

进一步地，其中ODB底层存储模块包括第二对象更新子模块、第二对象查询子模块、RocksDB数据库句柄快照维护子模块。

进一步地，其中第二对象更新子模块，对新添加的数据第一时间放到本地队列，由异步线程任务循环执行将本地队列待添加对象，批量更新到本地磁盘，如果是数据融合任务，则更新前需要对本次批量添加的对象依据其ID要在当前时间片内查询是否存在旧值，如果存在，则需要合并到新添加的对象属性值上；如果是替换任务，直接批量添加，数据就会自动覆盖旧数据，采用JDK自身的Fork/Join框架将大的更新任务拆分；其中第二对象查询子模块，根据上游服务传递的批量查询API所携带的参数：主键ID及时间片范围，到指定目录下获取数据，并反序列化为对象；从节点缓存中查看是否有对应数据，如果有也需要合并。

进一步地，其中，RocksDB数据库句柄快照维护子模块，RocksDB打开句柄有读写两种模式，一个指定时间段内打开一次写句柄；读句柄，如果有新的数据写入，重新打开快照获取最新数据。

本发明的技术方案还包括一种应对复杂数据的分布式对象数据库存储系统的构建方法，用户的读、写请求经过ODB任务客户端模块完成，客户端将用户的请求转发给ODB读写服务模块，读写服务模块根据用户读、写请求参数完成逻辑处理：其中对于查询请求，从ODB索引模块中查找满足要求的对象索引，然后调用ODB底层存储模块的服务API获取数据，然后在ODB读写服务模块合并同一对象ID的子对象为唯一对象，最后返回给ODB任务客户端模块；

对于写入请求，则根据对象ID散列到指定ODB存储节点，并异步小批量写入ODB底层存储，并把这个映射关系更新到ODB索引模块的索引库；

对于修改请求，则首先从ODB索引模块里查找其对应的存储节点，在其对应的底层存储上覆盖该对象信息，同时更新该对象索引变更时间戳；

对于删除请求，则首先从ODB索引模块里查找其对应的存储节点，在其对应的底层存储和索引上删除该对象信息。

本发明的一种应对复杂数据的分布式对象数据库存储系统具有如下几个优点：

1)支持横向Shard弹性扩展，单条数据的索引只有一条，其值会有若干个根据主键ID散列在ODB底层存储节点的独立对象实体组成。这点是开源的Db40所不具备的。

2)数据索引分离，数据的存储和索引部分是分开存放的，索引目前基于MongoDB存储，底层存储借助RocksDB的字节流来满足业务数据非固定大小的弹性扩展。

3)相对于MongoDB单条数据不超过16M，我们单条数据可以无限扩展，对外看作一个整体，内部按时间片或固定数据大小自动切分为一个个独立对象个体。

4)高效存储，对待存储对象使用高效的序列化工具转化。此处主要基于Hadoop底层的标准序列化框架Avro。其存储和MongoDB比较，同等数据规模，YdOdb比MongoDB存储能节省1/3的空间，这点也是Db4o这种没有采用优化的序列化技术，而使用默认普通JavaBean对象所不能比拟。

5)高效通讯，底层通讯传输依赖于高效的RPC——Avro和Thrift，其读写内部每个节点都充分利用CPU多核优势，异步并行批量处理。

6)使用便捷，现有NoSQL存储的只是数据，用到具体业务中，还需要加工成业务所需模式，而YdOdb查询获取的数据本身就已经是业务所需数据对象，可直接应用，更加贴近业务。

7)计算存储一体化整体效率更高效，以计算用户画像标签权重为例，使用仅有4个计算节点的YdOdb，计算一天活跃用户画像权重更新仅耗时46.68分钟，计算3天内活跃用户耗时仅109分钟，而且每个计算节点仅仅消耗2-3G空间。而基于14个计算节点的Spark集群计算一天活跃用户画像权重就要50分钟，而且消耗内存高达上百G，如果连续计算3天的，当下资源支持力度不够，还需要扩展节点。

附图说明

图1为现有技术对象数据库存储系统的特性；

图2为本发明应对复杂数据的分布式对象数据库存储系统架构；

图3为本发明应对复杂数据的分布式对象数据库存储系统功能逻辑架构。

具体实施方式

本发明的一种应对复杂数据的分布式对象数据库存储系统及构建方法，其中数据库存储系统可以简写为YdOdb，其整体系统架构和逻辑功能架构分别如附图2、附图3所示，整个系统自上而下分为4个部分：ODB任务客户端、ODB读写服务、ODB索引——MongoDB和ODB底层存储——RocksDB，其中ODB读写服务和ODB底层存储服务是整体核心。整体看本发明数据库存储系统，用户的任何读、写请求都需要经过ODB任务客户端完成，客户端将用户的请求转发给ODB读写服务模块，读写服务模块根据用户读、写请求参数完成逻辑处理：

如果是查询请求，将首先从ODB索引Mongo中查找满足要求的对像索引，然后调用ODB底层存储服务API获取数据，然后在ODB读写服务模块合并同一对象ID的子对象为唯一对象，最后返回给客户端；

如果是写入请求，则根据对象ID散列到指定ODB存储节点，并异步小批量写入ODB底层存储Rocksdb，并把这个映射关系更新到ODB索引库；

如果是修改请求，则首先从ODB索引里查找其对应的存储节点，在其对应的底层存储Rocksdb上覆盖该对象信息，同时更新该对象索引变更时间戳；

如果是删除请求，则首先从ODB索引里查找其对应的存储节点，在其对应的底层存储Rocksdb和索引MongoDB上删除该对象信息。

在本实施例中，详细介绍本发明所述应对复杂数据的分布式对象数据库存储系统每部分基本构建方法及功能模块：

(1)ODB任务客户端，用于提交对象查询和对象更新任务给ODB读写服务，一般由具体实际业务完成增删盖查操作，其本身功能如附图3中包含的内容：单个/批量对象增删改查接口，客户端监听读写服务等。启动之初，即通过Zookeeper监听ODB读写服务注册的节点，并定时检测其服务心跳，只有健康节点维持工作；对单个或批量查询任务，一般都是根据主键ID和时间范围参数通过Thrift RPC提交给ODB读写服务相应接口；而数据更新方面，为保证整体服务集群稳定运行，客户端每次提交新任务给ODB读写服务时，都会通过ThriftRPC检测当下可用节点的待计算任务个数，如果待计算任务个数<2的节点不存在，则sleep等待5秒，继续执行下一次请求，直到有空闲节点可用，再继续提交任务。

(2)ODB读写服务，基于Thrift实现和ODB任务客户端的通讯，用于接受任务客户端查询和更新请求，实现相应业务逻辑，并同ODB索引及ODB底层存储交互，具体功能如附图3中介绍，其启动之初，即通过Zookeeper监听ODB底层存储节点服务，并同时注册自身服务，供ODB任务客户端监听其动态。

对象查询：根据所接受的请求参数主键ID或时间戳范围，首先去ODB索引中查找过滤满足条件的子对象，根据查询规模大小，决定是否采用Fork/Join多线程并发调用，然后再调用基于Avro实现的RPC查询服务，批量获取每个ODB底层存储节点下的对象，再按照主键ID合并各来ODB存储节点下的子对象，再返回给上游调用方。

对象更新：对所接受的添加对象请求，不管是批量，还是单个，都会将数据首先缓存到本地队列。同时有一个异步线程任务一直循环执行，如果发现当前节点尚有未执行完的任务处于忙碌状态，则sleep 5秒，跳过继续执行下个循环；如果发现当前服务节点空闲，无正在执行的计算任务，则将当前节点状态改为正在执行的忙碌状态，并立即从本地队列获取数据，完成相应业务逻辑，构建利用Avro设计的序列化对象，根据主键ID散列到指定ODB底层存储节点对应的队列，同时将对象索引更新到MongoDB(方便多维度快速查询)，并调用Avro RPC批量提交给ODB底层存储，等执行完再更新节点计算状态为空闲。

(3)ODB索引，用于更新或快速查找单个或批量对象数据索引，此处借助MongoDB完成，其基本结构目前主要是按时间窗口划片，底层存储节点正常稳定运行时，一个对象只会存在一个固定的存储节点，除非该节点故障，则会存到另一个存储节点。

这里之所以使用MongoDB存储对象索引，一方面因为Mongo本身的多维度查询方便，同时其单条数据最大16M，对于存储这些简单索引数据足够用了。

(4)ODB底层存储，用于接受查询和存储对象实例，这里为了方便单条数据的横向扩展，采用时间段“年周”目录结构，类似“202034”表示2020年第34周，每个对象根据其活动周期，会散落到多个目录下，每个目录相当于一个独立表，其下就是RocksDB文件目录。ODB底层存储基本功能如附图3所示，每个节点启动之初即通过Zookeeper注册自身服务节点，方便上游监听存储节点可用状态。

对象更新：添加修改一体化，其单个/批量数据异步更新，对外只提供基础的添加接口，内部依靠异步更新任务来将最新的数据融合或替换已有的数据，不需要上游业务端关心如何更新。具体流程是：对新添加的数据都是第一时间放到本地队列，后续由异步线程任务循环执行将本地队列待添加对象，批量更新到本地磁盘，如果是数据融合任务，则更新前需要对本次批量添加的对象依据其ID要在当前时间片内查询是否存在旧值，如果存在，则需要合并到新添加的对象属性值上，不然老数据就会被覆盖丢失；如果是替换任务，直接批量添加，数据就会自动覆盖旧数据。因为数据更新一般都是批量更新，这里采用JDK自身的Fork/Join框架将大的更新任务拆分，充分使用服务器的多核CPU。

对象查询：根据上游服务传递的批量查询API所携带的参数：主键ID及时间片范围，需要到指定目录下获取数据，并反序列化为对象；同时也需要从节点缓存中查看是否有对应数据，如果有也需要合并，因为缓存队列的数据对象没有更新到磁盘前，从RocksDb快照句柄最新时间段获取的数据并不包含缓存待写入的数据。

RocksDB数据库句柄快照维护：RocksDB打开句柄有读写两种模式，写可以一直追加，一般一个指定时间段内打开一次写句柄就可以；而读句柄，因为每次打开都是当前数据库的一个快照，一旦有新的数据写入，就需要重新打开快照获取最新数据。这就要求存储节点内部需要维护一个根据是否添加新数据而需要是否重新打开数据库句柄的状态。

RocksDB优化配置：其配置项非常多，而且大大影响其效率和性能，关键点在于充分利用当前CPU多核优势和大内存。重点配置项，比如单独memtable大小及最大数量、落盘前需要合并的memtable最小个数、数据块默认4k需要调大也不能过大，并发压缩及落盘线程个数等,都需要根据实际业务和服务其配置做相应调整，以发挥其更优性能。

本发明的一种应对复杂数据的分布式对象数据库存储系统及构建方法，基本特性如下：

(1)服务节点弹性扩展——借助Zookeeper实现服务节点的横向和纵向动态扩容，即数据分片Shard和数据副本replica；

(2)数据索引分离——数据存储和索引独立存储；

(3)单条数据弹性扩展——借助索引单条数据可纵向扩展，不像MongoDB有单条16M限制；

(4)底层高效通讯——借助Thrift、Avro的RPC(Remote Procedure Call)远程过程调用；

(5)高效存储——复杂数据对象基于Hadoop底层的标准序列化框架Avro序列化，解析效率高且节省存储空间，同等数据规模比MongoDB节省1/3。

(6)高效读写——提供批量查询和添加修改一体化的异步更新接口，即无专有更新接口，只提供基础添加接口，内部依靠异步更新任务将最新数据融合或替代已有数据，上游业务端无需关心如何更新。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种应对复杂数据的分布式对象数据库存储系统，其特征在于，包括ODB任务客户端模块、ODB读写服务模块、ODB索引模块和ODB底层存储模块，其中：

ODB任务客户端模块，用于提交对象查询和对象更新任务给ODB读写服务；

ODB读写服务模块,用于接受任务客户端查询和更新请求，并同ODB索引模块及ODB底层存储模块交互；

ODB索引模块，用于更新或快速查找单个或批量对象数据索引；

ODB底层存储模块，用于接受查询和存储对象实例；

其中所述ODB读写服务模块包括第一对象查询子模块和第一对象更新子模块，

其中

第一对象查询子模块，

根据所接受的请求参数主键ID或时间戳范围，首先去ODB索引中查找过滤满足条件的子对象，根据查询规模大小，决定是否采用Fork/Join多线程并发调用，然后再调用基于Avro实现的RPC查询服务，批量获取每个ODB底层存储节点下的对象，再按照主键ID合并各来ODB存储节点下的子对象，再返回给上游调用方；

第一对象更新子模块，

对所接受的添加对象请求，将数据首先缓存到本地队列，同时有一个异步线程任务一直循环执行，如果发现当前节点尚有未执行完的任务处于忙碌状态，则sleep 5秒，跳过继续执行下个循环；如果发现当前服务节点空闲，无正在执行的计算任务，则将当前节点状态改为正在执行的忙碌状态，并立即从本地队列获取数据，完成相应业务逻辑，构建利用Avro设计的序列化对象，根据主键ID散列到指定ODB底层存储节点对应的队列，同时将对象索引更新到MongoDB，并调用Avro RPC批量提交给ODB底层存储，等执行完再更新节点计算状态为空闲；其中，ODB索引模块，其结构是按时间窗口划片，底层存储节点正常稳定运行时，一个对象只会存在一个固定的存储节点，若该节点故障，则会存到另一个存储节点；其中ODB底层存储模块，采用时间段“年周”目录结构，每个对象根据其活动周期，会散落到多个目录下，每个目录为一个独立表，其下就是文件目录，每个节点启动之初即通过Zookeeper注册自身服务节点，方便上游监听存储节点可用状态。

2.根据权利要求1所述的一种应对复杂数据的分布式对象数据库存储系统，其特征在于，其中ODB任务客户端模块包括单个对象更新子模块，批量对象更新子模块，单个对象查询子模块，批量对象查询子模块，监听读写服务子模块，批次调整子模块以及更新任务定向分发子模块，其在启动之初，通过Zookeeper监听ODB读写服务注册的节点，并定时检测其服务心跳，只有健康节点维持工作；对单个或批量查询任务，根据主键ID和时间范围参数提交给ODB读写服务模块的相应接口；对于数据更新方面，ODB任务客户端模块每次提交新任务给ODB读写服务模块时，都会检测当下可用节点的待计算任务个数，如果待计算任务个数<2的节点不存在，则sleep等待5秒，继续执行下一次请求，直到有空闲节点可用，再继续提交任务。

3.根据权利要求1所述的一种应对复杂数据的分布式对象数据库存储系统，其特征在于，其中ODB读写服务模块基于Thrift实现和ODB任务客户端模块的通讯，用于接受ODB任务客户端模块查询和更新请求，并同ODB索引模块及ODB底层存储模块交互，启动之初，通过Zookeeper监听ODB底层存储节点服务，并同时注册自身服务，供ODB任务客户端模块监听其动态。

4.根据权利要求1所述的一种应对复杂数据的分布式对象数据库存储系统，其中ODB底层存储模块包括第二对象更新子模块、第二对象查询子模块、RocksDB数据库句柄快照维护子模块。

5.根据权利要求4所述的一种应对复杂数据的分布式对象数据库存储系统，其特征在于，其中第二对象更新子模块，对新添加的数据第一时间放到本地队列，由异步线程任务循环执行将本地队列待添加对象，批量更新到本地磁盘，如果是数据融合任务，则更新前需要对本次批量添加的对象依据其ID要在当前时间片内查询是否存在旧值，如果存在，则需要合并到新添加的对象属性值上；如果是替换任务，直接批量添加，数据就会自动覆盖旧数据，采用JDK自身的Fork/Join框架将大的更新任务拆分；其中第二对象查询子模块，根据上游服务传递的批量查询API所携带的参数：主键ID及时间片范围，到指定目录下获取数据，并反序列化为对象；从节点缓存中查看是否有对应数据，如果有也需要合并。

6.根据权利要求4所述的一种应对复杂数据的分布式对象数据库存储系统，其特征在于，其中，RocksDB数据库句柄快照维护子模块，RocksDB打开句柄有读写两种模式，一个指定时间段内打开一次写句柄；读句柄，如果有新的数据写入，重新打开快照获取最新数据。

7.根据权利要求1-6任一所述的一种应对复杂数据的分布式对象数据库存储系统的构建方法，其特征在于，用户的读、写请求经过ODB任务客户端模块完成，客户端将用户的请求转发给ODB读写服务模块，读写服务模块根据用户读、写请求参数完成逻辑处理：其中对于查询请求，从ODB索引模块中查找满足要求的对象索引，然后调用ODB底层存储模块的服务API获取数据，然后在ODB读写服务模块合并同一对象ID的子对象为唯一对象，最后返回给ODB任务客户端模块；

对于写入请求，则根据对象ID散列到指定ODB存储节点，并异步小批量写入ODB底层存储，并把这个映射关系更新到ODB索引模块的索引库；

对于修改请求，则首先从ODB索引模块里查找其对应的存储节点，在其对应的底层存储上覆盖该对象信息，同时更新该对象索引变更时间戳；

对于删除请求，则首先从ODB索引模块里查找其对应的存储节点，在其对应的底层存储和索引上删除该对象信息。