CN112445770A

CN112445770A - 多维乱序存储的超大规模高性能数据库引擎及云服务平台

Info

Publication number: CN112445770A
Application number: CN202011377866.6A
Authority: CN
Inventors: 许建; 李果; 刘启良; 林昆
Original assignee: Qingyuan Polytechnic
Current assignee: Qingyuan Polytechnic
Priority date: 2020-11-30
Filing date: 2020-11-30
Publication date: 2021-03-05

Abstract

本发明公开了多维乱序存储的超大规模高性能数据库引擎及云服务平台，所述数据库引擎，包括以下功能模块：Block B：数据块；Fragment：数据片，所述数据库引擎包括多个数据片，每个数据片包含4个来源于不同的物理服务器的数据块；Address server：地址服务器，所述数据库引擎包括多台地址服务器；Cache：存储Address server的数据地址列表；Processing Unit：数据库的处理单元，每个处理单元都可以处理一个或多个客户端的服务请求；Client：客户端。所述数据库引擎采用三级结构组织数据库，以BSON格式存储小型数据，使用LargeFS文件系统存储大型文件。所述数据库引擎采用Fragment集群，可以动态扩展数据库。本发明中的数据库引擎能够超大规模地存储数据，并且支持高并发读写，提供建立云服务平台的技术服务。

Description

多维乱序存储的超大规模高性能数据库引擎及云服务平台

技术领域

本发明涉及数据库技术领域，尤其涉及多维乱序存储的超大规模高性能数据库引擎及云服务平台。

背景技术

随着互联网web2.0的兴起，传统的关系数据库，如MySQL、DB2、SQL SERVER等，在应付web2.0网站，特别是超大规模和高并发的微博、博客、社交网络等网站，已经显得力不从心，曝露了许多难以克服的问题：首先， web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以很大程度上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库可以勉强支持上万次的SQL查询，但是却不能够应付上万次SQL写数据请求。其次，在海量数据的查询中，SQL查询的效率会很低，例如在当前网络上的一些社交网站，如Friendfeed，一个月就达到2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再次就是在基于web的架构当中，关系数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，关系数据库没有办法像web server和appserver那样通过简单地添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对关系数据库系统进行升级和扩展是非常困难的事情，往往需要停机维护和数据迁移。

发明内容

针对上述存在的问题，本发明旨在提供一种多维乱序存储的超大规模高性能数据库引擎及云服务平台，该数据库引擎为非关系型数据库引擎，能够超大规模地存储数据，并且支持高并发读写，提供建立云服务平台的技术服务。

为了实现上述目的，本发明所采用的技术方案如下：

多维乱序存储的超大规模高性能数据库引擎，其特征在于，包括以下功能模块：

Block B：数据块，在服务器上用于保存数据的物理空间；

Fragment：数据片，所述数据库引擎包括多个数据片，每个数据片包含4个数据块，四个所述数据块来源于不同的物理服务器；

Address server：地址服务器，所述数据库引擎包括多台地址服务器，其中每台地址服务器都记录了数据存储的地址信息；各种维度的数据可以随机地存储在其中一个分布式服务器的某一数据片上，但需要在地址服务器上记录下相关信息；

Cache：存储Address server 的数据地址列表，Cache的地址列表和Address Server的保持一致；

Processing Unit：数据库的处理单元，每个处理单元都可以处理一个或多个客户端的服务请求；

Client：客户端，客户端是用户应用程序的一部分，它使用自身语言的多维数据引擎客户端驱动向Processing Unit发起请求。

进一步的，所述数据库引擎采用三级结构组织数据库，以BSON格式存储小型数据，使用LargeFS 文件系统存储大型文件。

进一步的，所述LargeFS包括调度模块、逻辑处理模块、底层存储模块、以及后台清理模块；

调度模块，它是LargeFS缓存层次数据入口，所有到达逻辑设备的读写请求，最终都会经过Device Mapper层的处理，通过LargeFS缓存层进入调度模块；

逻辑处理模块，它在调度模块通过底层存储模块执行数据读写操作完成后回调执行，它是采用状态机实现的，根据调度模块中的读写类型进行后续的处理，如读未命中情况下，磁盘读完成后，回调到逻辑处理模块，由它负责将从磁盘读取的数据写回到高效存储硬件，或者写未命中情况下，写高效存储硬件完成后，回调到逻辑处理模块执行元数据的更新，再有就是对调度模块中读写操作的错误进行处理；

底层存储模块，主要提供了两种方式来完成真实的数据读写，一是由linux内核DeviceMapper层提供的dm_io函数，它最终还是通过submit_bio的方式，将由调度模块处理过的请求提交到通用块层，进行转发到真实的设备驱动，完成数据读写；另外由linux内核提供的一种底层拷贝函数，主要负责旧数据块的写回，会引起元数据的更新；

后台清理模块，是针对每个缓存块进行数据清理，它会基于两种策略对旧数据块做回收：FIFO和LRU。

进一步的，所述数据库引擎采用Fragment集群，可以动态扩展数据库。

进一步的，利用所述多维乱序存储的超大规模高性能数据库引擎搭建而成的服务平台。

本发明的有益效果是：与现有技术相比，本发明的改进之处在于，

1、本发明中的数据库引擎是一个基于多维乱序存储的数据库引擎，能够超大规模地存储数据，并且支持高并发读写，提供建立云服务平台的技术服务。该数据库引擎既可以满足web2.0的架构，又可以满足当前互联网海量实时数据交互，应用到新型搜索引擎、城市安防监控网络、网络微博、购物网站以及社交网络等具有超大规模数据环境下的高并发读写需求网站。

2、本发明中的数据库引擎可以整合成为一个云服务平台，它可以与硬件设备结合起来，为不同的客户公司提供计算能力、存储空间、数据库、资源监控、网络等一体化服务。

3、本发明中的数据库引擎是一个分布式文档存储的数据库，并且是一个支持超大规模存储数据和高并发读写的下一代数据库，由C++语言编写，旨在为web应用提供可扩展的高性能数据存储解决方案。

4、本发明中的数据库引擎支持的数据结构非常松散，类似json的bjson格式，可以存储多维的复杂的数据类型。

5、本发明中的数据库引擎支持强大的查询语言，语法类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，并且支持对数据建立索引。

附图说明

图1为本发明数据库引擎的架构图。

图2为本发明一个简单的多维数据库引擎document的结构示意图。

图3为本发明多维数据库引擎的嵌入式文档结构示意图。

图4为本发明多维数据库引擎的Collection结构示意图。

图5为本发明多维数据库引擎的存储结构示意图。

图6为本发明LargeFS文件系统的工作流程图。

图7为本发明多维数据库引擎的乱序存储与Cache阵列关系示意图。

图8为本发明多维数据库引擎的Fragment 集群示意图。

图9为本发明中MASTER—REPLICA的模式图。

图10为利用本发明中的数据库引擎建立的云服务平台。

具体实施方式

为了使本领域的普通技术人员能更好的理解本发明的技术方案，下面结合附图和实施例对本发明的技术方案做进一步的描述。

如附图1所示，多维乱序存储的超大规模高性能数据库引擎，包括以下功能模块：

Block B：数据块，在服务器上用于保存数据的物理空间，一个物理服务器可以划分很多的数据块；

Fragment：数据片，所述数据库引擎包括多个数据片，每个数据片包含4个数据块，四个所述数据块来源于不同的物理服务器；在这四个数据块中，其中一个为主数据块MASTER，另外三个数据块从主数据块上复制数据，为REPLICA。同一时间，只有MASTER具备读和写的功能，而REPLICA只负责读取数据，这样就可以实现了读写分离，并且保持读写的一致性。在一个Fragment中，MASTER为主节点，如果主节点死掉了，其中一台从节点REPLICA自动接管为主节点MASTER。

Address server：地址服务器，所述数据库引擎包括多台地址服务器，其中每台地址服务器都记录了数据存储的地址信息；各种维度的数据（二维、三维、四维等等）可以随机地存储在其中一个分布式服务器的某一数据片上，但需要在地址服务器上记录下相关信息；在数据库运行之初，Address server要把自己所有记录的地址列表复制到Cache 里面，当数据在服务器的存储位置发生变化后，Address server 要修改地址列表，并且更新Cache的地址列表。地址服务器的工作还包括对节点健康的心跳检查。如果节点down或是有新节点加入，Address server 要经行数据的迁移，或是对block块进行重新选举MASTER。

Cache：存储Address server 的数据地址列表，Cache的地址列表和AddressServer 的保持一致；

Processing Unit：数据库的处理单元，每个处理单元都可以处理一个或多个客户端的服务请求；客户端向Processing Unit发起查询和更新，Processing Unit根据Cache记录的地址信息将请求分发到合适的服务器上。

具体的，多维数据引擎是一种面向集合（collection）的，模式自由的文档（document）数据库引擎。各种数据结构（二维、三维、四维等）的数据记录均以不同结构的文档的形式表示，若干个文档组成一个集合。每个集合在数据库中有惟一的名称，集合可以包含不限数目的文档。除了模式不是预先定义好的，集合与RDBMS中的表概念类似，但二者并不完全对等。数据库和集合的创建是“lazy”的，即只有在第一个document被插入时集合和数据库才真正创建——这时在磁盘的文件系统里才能看见。

模式自由是指存放集合中的文档结构对数据库是透明的，同一个集合中可以存放不同结构的文档，并且文档也支持嵌入子文档。

多维数据库引擎的最小存储单位就是文档对象，各种维度的数据在多维数据引擎中以BSON（Binary-JSON）文档的格式存储在磁盘上。BSON（Binary JSON）是对JSON-like文档的二进制编码序列化，是一种基于JSON（JavaScript Object Notation）存储格式的改进存储格式。

每一个文档对象，多维数据引擎都会为它分配一个唯一的id号，名为“_id”，可以把文档视作关系型数据库中的行，如附图2所示。

如附图3所示，多维数据库引擎跟一般的key-value数据库不一样的是，它的value中存储了结构信息，所以它提供了嵌入式的文档结构。

Collection就是documents的集合，可以理解为关系型数据库中的表，也可以看成一个文件夹，用来专门储存同一类文档，如附图4所示。

如附图5所示，多维数据库引擎的最外层结构，和关系型数据库一样，是存放多个Collections的容器。可以把多维数据引擎看成一个文件仓库，每个document就如同一页纸；成千上万张纸被存放在文件夹里，这些文件夹就可以看做是Collection；多个文件夹存放在一个储藏柜里，也就是Database。

多维数据库引擎充分利用了BSON的内部机制，可以深入BSON对象的内部（包括嵌套的对象），在顶层和嵌套的BSON对象上建立索引来支持各种查询功能。

进一步的，LargeFS提供了一种透明的机制，允许把一个大文件分割成许多个较小的文档，这种机制可以有效地保存那些较大的文件对象，特别是巨大的文件，例如视频。LargeFS也提供一种透明的存储选址机制，根据实际的硬件进行配置。LargeFS文件系统的工作流程如附图6所示。

1) LargeFS对数据的预处理

LargeFS在存储的过程中，会分别记录文件对象的元数据信息，和在数据库中的二进制数据的信息。

2) LargeFS对数据的存储选址

LargeFS利用linux kernel2.6的device mapper特性，实现了多路径IO的选址。将多块硬盘组合一个逻辑的整体，实现了最简单意义上的“云存储”，提高了硬件的效能。

进一步的，LargeFS的技术重点LargeFS缓存层，是在Device Mapper层和设备驱动之间新增了的一层缓存层，以模块化的方式加入到了Device Mapper层。

LargeFS包括四个模块，分别为调度模块、逻辑处理模块、底层存储模块、以及后台清理模块；

调度模块，它是LargeFS缓存层次数据入口，所有到达逻辑设备的读写请求，最终都会经过Device Mapper层的处理，通过LargeFS缓存层进入调度模块；主要是指，接收到数据后，它会根据请求的读写类型、是否命中缓存等因素，选择不同的处理分支，如:在缓冲区读/写，在非缓存器读/写。经过不同分支的读写，会调用底层存储模块来完成磁盘或cache的数据读写。

底层存储模块，主要提供了两种方式来完成真实的数据读写，一是由linux内核DeviceMapper层提供的dm_io函数，它最终还是通过submit_bio的方式，将由调度模块处理过的请求提交到通用块层，进行转发到真实的设备驱动，完成数据读写；另外由linux内核提供的一种底层拷贝函数，主要负责旧数据块的写回（从高效存储硬件到普通存储硬件），会引起元数据的更新；

进一步的，本发明中的多维数据库引擎将各种维数的数据进行乱序存储，如附图7所示。多维数据库引擎将不同数据结构（二维、三维、四维等）的源数据随机地存储在某一个数据分片（Fragment）上，实现数据的乱序存储，避免降维操作，为高并发的读写提供了理论基础。

多维数据库引擎为每个处理单元（Processing Unit）配备一个Cache。ProcessingUnit 在处理客户端的请求时，可以直接根据Cache上的地址信息搜索相关的数据，然后再进行读或者写操作，不需要访问Address server。这种算法可以避免在高并发的环境下，备份Address server上的地址信息。当每个数据分片（Fragment）上的数据存储信息有改变后，都会在Address server 上作出相应的修改。Address server再更新所有Cache 上的地址列表。

Processing Unit对请求进行预处理。对请求中的对象id进行hash后的模运算，在自身Cache里面匹配，如命中，直接到Fragment对应的节点通信，否则通过在地址服务器进行模运算并更新自身缓存。

进一步的，所述数据库引擎采用Fragment集群，如附图8所示，可以动态扩展数据库。在多维数据库引擎中，每个Fragment 包含了4个存储数据的Block, 当文件的大小大于一个Fragment 的容量时，这个文件可以自动地被切分，再存储在多个Fragment数据片上。

Fragment 数据片采用Master-Replica模式进行数据库的复制和备份。可以不断地增加，这样使数据库能够动态地扩展；而且数据分布在多个Fragment 节点上，也分散了读写的压力。

MASTER—REPLICAE模式如附图9所示。在多维数据库引擎中，每个Fragment 包含四个存储数据的数据块Block，在这几个Block中，只有一个作为MASTER, 剩余的都作为REPLICA. 只有MASTER 才能够写入数据，从属的REPLICA 自动从MASTER复制数据，REPLICA只能够读数据，这样就实现了读写分离，保持了数据的一致性。

Address server（地址服务器）会介入节点的控制，以秒级频率对节点进行心跳检查。如果MASTER出现了故障，或者断电，其中一个REPLICA会自动接管，并且从那一刻起成为MASTER，保障数据库的继续稳定运行。当原来出现故障的MASTER恢复后，就可以自动地加入集群，并且作为一个REPLICA去提供备障和分摊读压力。同样，当一个新节点声明加入Fragment集群时候，Address server会进行分配新节点到负责合适的block。

Fragment集群的分布策略如下，数据在新表中均衡地分布到所有节点上，尽可能地保持现有的节点和Fragment的关系。

假设我们设置3个Fragment，6台节点服务器，ip为192.168.1.100~192.168.1.111. Address server里面的逻辑信息如下。每一行表达一个Fragment的信息，第一列为hash值。第二列是MASTER地址，第二，三，四列是REPLICA 地址。

0 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.103

1 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104

2 192.168.1.102 192.168.1.103 192.168.1.104 192.168.1.105

当Address server接收到请求后，将对象id的hash值和3取模，然后根据取模后的结果查找对照表。比如取模后的值为0，是写操作，将和192.168.1.100通信。

如果Address server发现新加入的节点192.168.1.200，可能将会修改为如下：（根据负载情况）

0 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.103

1 192.168.1.101 192.168.1.200 192.168.1.103 192.168.1.104

2 192.168.1.102 192.168.1.103 192.168.1.200 192.168.1.105

同样，如果Address server发现有节点down了，也同理。假设MASTER主机192.168.1.100 down了。REPLICA 会替代成为MASTER

0 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.105

1 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104

2 192.168.1.102 192.168.1.103 192.168.1.104 192.168.1.105

进一步的，本发明中数据库引擎的功能命令如下：

1) 新建集合集

createcol("new collection name")

2) 插入数据

insert( )

3) 更新数据

update( )

4) 查询

search( )

5) 遍历集

alllist( )

6) 条件查询

search("condition")

7) 排序

升序排列：sort（-1）

降序排列：sort（1）

8) 索引

添加索引：addindex( );

删除索引：deindex( );

查询索引：queryindex( );

9) 备份

backup( );

10)还原

restore( );

11)帮助信息

help ( );

进一步的，由于多维数据引擎的架构特点和功能特性，它还可以用于建立云服务平台，当外部条件具备时，可以将多维数据引擎和服务器、网络设备等硬件设备整合，形成一个以多维数据引擎为服心的云服务平台，如附图10所示。

云服务平台的特点是，不同的客户可以根据自己的业务类型、特点、用户规模等数据向云服务平台定制相应的服务。云服务平台再根据客户定制的服务而分配相应的计算处理能力、存储空间大小，同时设定网络参数和资源监控范围等，之后只需要向用户提供云接入端口，用户就可以获取所需要的服务，建立自己特有的网站。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims

1.多维乱序存储的超大规模高性能数据库引擎，其特征在于，包括以下功能模块：

Block B：数据块，在服务器上用于保存数据的物理空间；

Cache：存储Address server的数据地址列表，Cache的地址列表和Address Server的保持一致；

2.根据权利要求1所述的多维乱序存储的超大规模高性能数据库引擎，其特征在于：所述数据库引擎采用三级结构组织数据库，以BSON格式存储小型数据，使用LargeFS文件系统存储大型文件。

3.根据权利要求2所述的多维乱序存储的超大规模高性能数据库引擎，其特征在于：所述LargeFS包括调度模块、逻辑处理模块、底层存储模块、以及后台清理模块；

4.根据权利要求1所述的多维乱序存储的超大规模高性能数据库引擎，其特征在于：所述数据库引擎采用Fragment集群，可以动态扩展数据库。

5.利用权利要求1-4任一项所述的多维乱序存储的超大规模高性能数据库引擎搭建而成的云服务平台。