CN111984696B - 一种新型数据库和方法 - Google Patents

Abstract

一种新型数据库和方法，通过设置相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块形成数据库整体架构，并将所述数据库整体架构构建在分布式文件系统上，使其成为既能够具备多类型、大数据、高吞吐、高扩展性特性，又能够具有传统数据库优良特性的新型数据库，具有十分重要的行业应用现实意义。

Description

一种新型数据库和方法

技术领域

本发明涉及数据库技术，特别是一种新型数据库和方法，通过设置相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块形成数据库整体架构，并将所述数据库整体架构构建在分布式文件系统上，使其成为既能够具备多类型、大数据、高吞吐、高扩展性特性，又能够具有传统数据库优良特性的新型数据库，具有十分重要的行业应用现实意义。

背景技术

随着互联网对传统行业的强烈冲击和影响，对传统行业信息化应用模式造成了深刻影响，传统行业应用从互联网所倡导的开放和创新的思维模式汲取营养，不断针对传统行业应用进行改良与创新，不断发展增值应用，以及不断提出新型的服务模式，这一切使得传统行业信息化应用，正在朝着服务化、行业运营级别方向发展。在此过程中，相对于传统应用来说，创新应用以及创新应用模式的最大阻碍，是数据类型更加丰富多样，同时数据规模几何级数膨胀，无法很好的处理丰富多样的数据类型和超大规模的数据量，应用创新便无从谈起。面对上述现实情况，传统的关系型数据库无法满足这么大规模数据的高效存储与高并发读写需求。为了解决这个问题，提出了关系数据库分片集群的方案，它采用分片(sharding)的方式对扩容进行支持，但是所带来的问题是，扩容操作比较复杂，联合多个sharding表数据查询也很麻烦。关系数据库的分片方案分为垂直分片和水平分片，以用户、订单、库存的场景为例，说明关系数据库在应对大规模数据存储上的复杂性和固有缺陷。

垂直分片的做法是将用户、订单、库存的信息分别存储在不同的数据库中，例如数据库A存储用户、订单的信息，数据库B存储库存的信息。当有新的订单生成时，需要将订单信息写入到A库中(插入新订单)，将库存信息写入到B库中(更新库存)，对两个库的操作需要保证原子性和一致性，即要么两个操作都成功，要么都失败，不能出现有新订单却没有减库存的情况，这种保障机制需要在应用系统中来控制和实现，两个数据库之间是无法互相保证的，而且将保障工作交给应用程序，无疑增加了应用程序的复杂度和工作量。随着业务规模的增加，垂直分片的方案很快会遇到新的瓶颈，需要对A、B两个数据库进行再次拆分，例如增加新的数据库C，用于存储订单信息，那么就需要将A库中的订单数据迁移到C库中，相应的，应用程序中的逻辑就需要重新改写，代价是巨大的。

水平分片的做法是根据数据的某些属性，动态将数据分散存储到不同的数据库中，例如按照用户、订单、库存所属的地域，将华北地区的用户、订单、库存信息存储在A库中，将华南地区的用户、订单、库存信息存储在B库中。当需要查询某类商品的全国销量时，需要应用程序分别从不同的数据库中查询相关数据，然后再自行汇总计算。当用户跨地域下单时，也需要同时操作不同的数据库，并在应用程序端保证操作的原子性和一致性。当数据规模扩大时，需要按新的规则进行水平分片(例如按省份分片)，同样会面临大规模的数据迁移，以及应用程序逻辑上的变更。

随着云计算技术的兴起，解决了大规模数据的存储及处理问题，特别是对于结构化及半结构化数据，云存储是一种非常有效、经济的存储方式。针对数据的查询需求，一些公司以及研究机构纷纷开发云上的数据库系统，它们统称为NoSQL。NoSQL是指NoRelationship或Not Only SQL(SQL是结构化查询语言的英文简称，这里代指关系数据库)，用于存储和处理大规模结构化或非结构化数据，能够随着数据规模增大而进行水平扩展，目前已有许多种NoSQL数据库的实现，根据数据的存储方式，可以分为三个主要类型：Key-Value存储模式(即键值对存储模式)、文档模型存储模式、列族模型存储模式。这些NoSQL系统，大多侧重于高吞吐率和高可扩展性的设计，放弃了关系数据库的许多优良特性，如二级索引、事务、连接查询等，同时也不支持SQL访问。这些设计上的刻意侧重，以及针对行业应用开发支持功能上的舍弃，使得NoSQL无法满足许多具有严谨业务逻辑要求的应用需求，用户不能直接由RDBMS(关系数据库)迁移到NoSQL，这限制了NoSQL数据库技术在行业应用上的推广和使用。

本发明人认识到，关系数据库的数据是存放在本地目录中(即数据是存放在安装数据库软件的那台计算机上)，而一台计算机能够提供的存储空间有限，本地存储很难应对数据规模的增长。基于此，有必要借助文件系统的文件存储功能。数据库是运行在计算机操作系统中的一种软件程序，数据库的主要作用之一是存储数据，数据最终都要存放在文件系统中，即数据是存放在磁盘某些目录下的一个或多个文件中。如果要随时应对数据规模的增长，就需要能够随时对文件系统的存储空间进行扩容，由此可见，有必要将数据库构建在分布式文件系统上。分布式文件系统结构如图1所示，包括通过网络连接的节点1、节点2和节点3，节点1为本地节点，程序(用户)能够通过分布式文件系统在各个节点的磁盘上进行文件读写。当现有节点存储空间不足时，可以通过向分布式文件系统中添加新的节点来对存储空间进行扩容，例如图1中具有磁盘的新增节点4(网络计算机或者说联网计算机)。

分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点(可理解为一台计算机)相连。多个节点组成了一个大的文件系统，允许文件和存储空间通过网络在多台节点上分享，如图1所示，在程序与用户看来，让实际上是通过网络来访问文件的动作，就像是访问本地的磁盘一般，而实际上目录和文件可能被分散存储到不同的节点上，甚至单个文件会被拆分成多个文件块分别存储到不同的节点，程序与用户无需关心文件存储的细节。当现有节点存储空间不足时，可以通过向分布式文件系统中添加新的节点来对存储空间进行扩容(图1中的虚线部分)，分布式文件系统支持扩容就相当于为程序和用户提供了近乎无限的存储空间，扩容的过程同样对程序和用户是透明的。

有鉴于此，本发明人通过设置相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块形成数据库整体架构，并将所述数据库整体架构构建在分布式文件系统上，使其成为既能够具备多类型、大数据、高吞吐、高扩展性特性，又能够具有传统数据库优良特性的新型数据库。本发明具有十分重要的行业应用现实意义，具备上述两种特性的新型数据库称为NewSQL数据库系统。

发明内容

本发明针对现有技术中存在的缺陷或不足，提供一种新型数据库和方法，通过设置相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块形成数据库整体架构，并将所述数据库整体架构构建在分布式文件系统上，使其成为既能够具备多类型、大数据、高吞吐、高扩展性特性，又能够具有传统数据库优良特性的新型数据库，具有十分重要的行业应用现实意义。

本发明的技术方案如下：

一种新型数据库，其特征在于，包括构建在分布式文件系统之上的数据库整体架构，所述数据库整体架构包括相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块，所述客户端模块供应用程序操作数据库使用，所述数据库整体架构通过文件系统模块与所述分布式文件系统连接，所述主控系统和所述数据存储系统分别通过一致性协调系统交互模块连接一致性协调系统，所述一致性协调系统通过客户端访问接口与客户端模块连接，所述数据存储系统通过请求处理模块分别与所述主控系统和所述客户端连接，所述主控系统通过外部接口模块与所述客户端模块连接。

所述应用程序采用SQL语句通过所述客户端模块进行数据库操作，所述SQL语句中设置有包括列组名称描述项或列组名称句子成分以适配列式数据库中列式存储模型的列组设置；所述列式存储模型为包括所述列组的多级结构，所述SQL语句能够适配列式数据库中列式存储模型的多级列组结构；所述SQL语句具有以下功能设置：支持动态列作为静态字段和/或作为值的转换方法以适配列式存储模型中的列既能够作为字段也能够作为值的使用方式，支持动态列查询。

所述数据库整体架构为分布式集群模式，所述一致性协调系统、主控系统、数据存储系统均为分布式集群模式。

所述数据存储系统的分布式集群采用多活模式，所述主控系统的分布式集群采用一主多备模式。

所述数据存储系统的数据存储采用列式存储模型，所述数据存储系统针对数据查询采用匹配不同存储层次的分层扫描器查找目标数据。

所述一致性协调系统的分布式集群采用Paxos算法以保证被操作数据状态的一致性，所述分布式集群包括一个领导者节点，分别与所述领导者节点连接的若干个观察者节点，以及分别与所述领导者节点连接的若干个跟随者节点，所述领导者节点、观察者节点和跟随者节点组成集群共同对外提供服务，对于多进程访问共享资源进行协调和保证数据状态的一致性。

所述领导者节点、观察者节点和跟随者节点形成集体决策机制，所述领导者节点负责发起投票和最终决策，所述跟随者节点参与投票决策过程，所述观察者节点接受客户端请求并转发给所述领导者节点，但不参与投票。

所述一致性协调系统在其内部把数据组织为树形结构，客户端根据所述树形结构的数据路径写入或获取数据，所述一致性协调系统在内存中维护数据，不会将数据写入到磁盘中，所述一致性协调系统在所述数据库整体架构中主要负责保障性作用而不是负责实际的数据存储和管理。

所述一致性协调系统与客户端之间通过事件异步反馈机制进行交互，两者之间的通信遵循TCP协议的长连接方式，所述客户端能够对所述一致性协调系统中的一些路径进行观察或订阅，当所述路径下的数据发生了变更，所述一致性协调系统会在第一时间通知到订阅了所述路径的客户端。

所述一致性协调系统对于与其建立了网络连接的客户端设置有效期凭证，如果所述客户端在有效期内没有任何请求，则凭证会失效，所述客户端在一致性协调系统中创建的树节点数据被删除，如果所述客户端从所述有效期内至有效期外定时向所述一致性协调系统发送心跳，则能够保持凭证的有效状态。

所述一致性协调系统提供KV键值对存储服务，所述一致性协调系统能够接受来自所述客户端访问接口的数据操作，所述数据操作包括以下一种或多种：创建树形结构节点，删除节点，修改节点数据，获取节点数据，获取子节点，Watch观察节点；对于同一节点，能够针对多个客户端接受一写多读操作以实现同一节点数据在多个客户端之间交互和共享。

所述一致性协调系统提供中心化的客户端故障发现服务，当第一客户端连接到所述一致性协调系统并创建了第一节点后，连接到所述一致性协调系统的其他客户端能够通过观察第一节点来得知所述第一客户端的健康状况，一旦所述第一客户端发生心跳停止的故障，所述第一节点被删除，观察所述第一节点的其他客户端得到来自所述一致性协调系统的所述第一节点被删除通知，从而得知所述第一客户端已经发生故障。

所述一致性协调系统提供以下协调服务中的一项或多项：分布式场景下的分布式锁，分布式场景下的分布式计数器，分布式场景下的分布式队列技术。

所述分布式锁的使用方式如下：当第一客户端连接到所述一致性协调系统后先获取第一条路径下的第一节点数据，若第一节点数据为空，则更新为上锁状态，后来的客户端发现所述上锁状态只能选择放弃获取锁或等待第一客户端释放锁。

所述主控系统包括指令执行模块，策略模块，所述一致性协调系统交互模块，所述文件系统模块，以及所述外部接口模块，所述指令执行模块分别互连于所述策略模块、所述一致性协调系统交互模块、所述文件系统模块和所述外部接口模块，所述外部接口模块与外部访问请求进行交互，所述文件系统模块与分布式文件系统交互，所述一致性协调系统交互模块与一致性协调系统进行交互。

所述一致性协调系统交互模块包括集群状态管理工具，负载均衡管理工具，数据存储系统管理工具，以及表状态管理工具。

所述集群状态管理工具用于执行主控系统集群的一主多备模式，当主控系统软件被部署到多个节点上并启动后，所述集群状态管理工具通过所述一致性协调系统的分布式锁机制选定一个节点为活动节点，保证只有这一个节点上的主控系统对外提供服务，其他节点均为备用的就位节点，当主控系统活动节点被所述一致性协调系统的故障发现机制确认发生故障，所述集群状态管理工具重新选定活动节点并通过所述指令执行模块完成故障迁移。

所述数据存储系统管理工具用于执行数据存储系统集群的多活模式，所述多活模式中的多个活动节点的信息被存储在所述一致性协调系统中，当其中某一个活动节点被所述一致性协调系统的故障发现机制确认发生故障，所述数据存储系统管理工具调用所述指令执行模块进行故障处理，所述故障处理包括将发生故障的数据存储系统中的数据托管到其他正常的数据存储系统中。

所述负载均衡管理工具通过调用所述指令执行模块管理被触发的对数据存储系统集群所进行的负载均衡工作，所述负载均衡工作包括对表分区进行重新分配，所述重新分配是按照负载均衡策略将表分区托管到不同的数据存储系统中，所述负载均衡工作的触发来自所述策略模块的主动触发或来自所述外部接口模块的外部触发，在所述负载均衡工作的过程中，所述负载均衡管理工具使用从所述一致性协调系统获取的分布式锁防止在负载均衡过程中再次发生负载均衡，同时通过所述一致性协调系统的分布式锁机制对参与负载均衡的数据存储系统及其数据加锁以防止其他工作影响负载均衡，所述其他工作包括新数据写入或数据库扩容。

所述表状态管理工具用于对数据表进行以下状态的择一设置：创建状态，修改状态，正常状态，切分状态，上线状态，下线状态；各种状态代表了所述主控系统对数据表的各种处理过程。

所述外部接口模块包括远程调用工具，监控指标工具，以及管理支持工具。

所述远程调用工具支持外部通过RPC远程方法调用发起数据管理请求，所述数据管理请求包括创建表、负载均衡和/或用户授权，所述数据管理请求由所述指令执行模块进行处理。

所述监控指标工具支持来自外部访问的监控指标请求，所述监控指标工具提供插件扩展机制和规范，允许各种外部系统按照规范开发插件，外部接口模块会加载插件并在运行过程中将监控指标发送到插件中，插件负责对指标数据进行处理使用，所述处理使用包括页面图形展示和/或短信告警通知。示例，所述监控指标请求包括表读写次数和/或平均响应时间；所述处理使用包括页面图形展示和/或短信告警通知。

所述表读写次数包括在主控系统内存中设置的ReadCount对象所存储的读表次数，和在主控系统内存中设置的WriteCount对象所存储的写表次数，所述ReadCount对象和WriteCount对象均为Map结构，所述Map结构中的字典键是表名称，字典键所对应的值是读表次数或写表次数。

所述管理支持工具支持来自外部访问的集群状态请求，所述集群状态请求包括表存储情况和/或数据存储系统分布情况，所述外部访问采用Rest API方式。

所述管理支持工具支持通过URL地址获取集群状态。

所述策略模块包括以下策略的一种或多种：负载均衡策略，表切分策略，故障恢复策略，扩容策略，数据压缩策略。

所述策略模块采用可配置化策略模型，所述策略模型包括具体任务的触发机制和/或具体任务的执行逻辑。

所述负载均衡策略包括阈值设定，如果达到阈值，所述策略模块即触发数据存储系统集群进行负载均衡工作，所述负载均衡工作包括将表分区从达到阈值的数据存储系统迁移到其他的数据存储系统，所述迁移由所述策略模块调用所述指令执行模块完成。示例，所述阈值为集群中同一时间呈现的被单一数据存储系统托管表分区量的最大值减去最小值的差值，如果达到阈值，将表分区从托管量最多的数据存储系统迁移到托管量最少的数据存储系统。

所述文件系统模块用于完成对所述分布式文件系统发起的数据读写工作，所述文件系统模块对于不同类型分布式文件系统的差异具有屏蔽功能。

所述指令执行模块通过指令池机制应对高并发的指令执行以防止系统过载，所述指令池包括若干个执行器，所述指令执行模块对于来自所述主控系统中其他模块生成的执行任务指令，能够根据任务类型选用执行器或根据执行器的处理能力对任务进行拆分或合并。

所述主控系统负责数据库的管理工作，所述管理工作包括以下一项或多项：管理数据服务器以实现负载均衡；管理和分配表分区；实现数据定义DDL操作，所述DDL操作包括创建数据库、创建表和/或修改列；管理数据库和表的元数据；权限控制。

所述数据存储系统包括请求处理模块，一致性协调系统交互模块，预写日志模块，数据缓存模块，分区管理模块，以及文件系统模块，所述请求处理模块互连着预写日志模块、数据缓存模块、分区管理模块、主控系统和客户端模块，所述一致性协调系统交互模块分别互连着分区管理模块和一致性协调系统，所述文件系统模块分别互连着预写日志模块、分区管理模块和分布式文件系统，所述分区管理模块包括若干个表分区。

所述请求处理模块用于接收所述客户端模块的数据读写请求，以及向所述客户端模块返回请求的执行结果，所述请求处理模块通过RPC远程方法调用方式与所述客户端模块进行交互，所述请求处理模块设置有用于读写数据的如下基础操作接口：插入数据Insert操作接口，更新数据Update操作接口，删除数据Delete操作接口，以及查询数据Select操作接口。

所述请求处理模块用于接收所述主控系统发起的数据管理请求，所述数据管理请求包括建表请求，在表加载过程中所述主控系统通过所述请求处理模块告知所述数据存储系统加载具体的表分区，所述请求处理模块在处理数据读写请求过程中向所述主控系统报送监控指标，由所述主控系统汇总监控指标，所述监控指标包括表读写次数和/或请求平均响应时间。

所述一致性协调系统交互模块用于将数据存储系统集群中各个服务器地址和/或健康状况存储到所述一致性协调系统中，所述数据存储系统通过所述一致性协调系统交互模块获取所述主控系统集群中的活动节点状况和/或各个服务器地址。

所述文件系统模块用于完成所述数据存储系统对所述分布式文件系统发起的数据读写工作，所述文件系统模块对于不同类型分布式文件系统的差异具有屏蔽功能。

所述数据包括预写日志数据和数据文件数据。

所述分区管理模块用于表分区的数据读写、管理或托管，所述表分区包括若干个列池，每个列池中包括内存池和文件池，文件池中包括文件引用对象，每一个文件引用对象指向分布式文件系统中的一个数据文件。

所述分区管理模块在处理数据写入请求时，写入的数据根据其所属的列组放入不同的内存池中，当内存池里的数据积攒到一定阈值后，一个表分区的所有内存池会统一将数据从内存池刷写到分布式文件系统中。

所述分区管理模块在处理数据读取请求时，先从内存池中查找数据，若未找到则会从数据文件中查找数据，直到找到目标数据或找完此分区中全部的数据文件。

所述预写日志模块利用预写日志机制保障数据库故障修复后的数据恢复以保证数据库的Robust鲁棒性。所述预写日志模块采用若干个表分区共享一个日志编辑器,日志编辑器对每一次数据更新记录一条预写日志，预写日志的结构包括序列号，更新时间，表名，分区名，以及行级数据或列级数据。

所述数据存储系统中的请求处理模块接收到写入请求时，写入数据首先进入预写日志文件中，然后进入所述分区管理模块的内存池中。

所述写入请求包括Insert请求或Update请求或Delete请求。

所述预写日志模块中的预写日志具有以下生命周期：从日志创建，到日志滚动，到日志过期，到日志删除；所述日志创建是指所有的数据写入操作都会先记录到预写日志中；所述日志滚动是指预写日志模块每隔一段时间会创建一个新的日志文件，记录新的数据写入；所述日志过期是指当分区管理模块把内存中的数据持久化后，就不再需要对应的预写日志，其日志文件会被标记为过期；所述日志删除是指主控节点的策略模块会根据策略删除过期的日志文件。

所述数据缓存模块用于将热点数据存储为内存数据以减少IO开销和提升数据库的读性能，所述数据存储系统中的请求处理模块接收到读请求后，先从所述数据缓存模块查找数据，若命中缓存则直接返回数据，若未命中缓存，则由分区管理模块从数据文件中查找数据，并将结果数据放入所述数据缓存模块和向所述请求处理模块返回结果数据。

所述数据缓存模块采用最近最少使用则淘汰的LRU算法，当缓存的数据达到一定阈值则启动淘汰策略，缓存中最近最少使用的数据会被置换出来以保证缓存对新的热点数据始终保持开放。

所述客户端模块用于用户或应用程序与数据库集群通讯、发起请求和接收结果，所述客户端模块包括连接池和API应用程序接口，应用程序通过所述API实现数据库操作，所述连接池分别连接所述API、所述一致性协调系统、所述主控系统和所述数据存储系统。

所述连接池对数据库连接资源的协调和错误的处理进行统一管理。

所述API对于表分区之间的复杂性具有屏蔽功能，所述API操作的粒度是表，而非表分区。

所述客户端模块根据所述一致性协调系统关于数据库集群变化信息的通知更新本地缓存的集群信息，所述数据库集群变化信息包括扩容、负载均衡和/或故障切换。

所述应用程序通过所述API实现数据库操作的步骤包括：步骤1，传入配置信息，包括一致性协调系统的地址信息；步骤2，创建数据库连接，客户端模块首先连接到一致性协调系统，通过一致性协调系统获取整个数据库集群的相关信息并缓存到客户端模块，并建立与主控系统、数据存储系统的连接；步骤3，管理或操作数据库，通过客户端模块提供的API，将操作指令以及数据传递到集群中执行，并返回结果；步骤4，关闭数据库连接。

所述将操作指令以及数据传递到集群中执行包括以下传递方式：当所述操作指令以及数据为管理数据库则传递到主控系统，当所述操作指令以及数据为操作数据时则传递到数据存储系统。

所述数据存储系统的数据存储模型为基于列式模型基础上的列组模型，通过将列式模型中的若干列组合为不同的列组以区分不同的业务含义，从而在列组层面采取不同的数据约束条件和/或安全策略。

所述列组模型针对用户注册信息表，所述用户注册信息表包括用户名、密码、昵称、邮箱、手机号和微信号，其中用户名、密码、昵称和邮箱被设置为第一列组，手机号和微信号被设置为第二列组，所述第一列组的业务含义为基本信息组，所述第二列组的业务含义为社交账号组，针对所述第一列组和所述第二列组分别进行读写权限的授权，所述社交账号组允许为空或允许增加其他账号。

所述用户注册信息表被切分为三个分区R1、R2和R3，R1、R2和R3以一对一的方式对应用户注册信息表的三段主键区间，R1和R2归属于第一数据存储系统，R3和元数据表归属于第二数据存储系统，客户端通过一致性协调系统获得元数据表位置信息即元数据表所属数据存储系统，通过元数据表获得分区与用户注册信息表主键区间的对应关系。

所述数据存储系统用于存储数据的逻辑模型中，最基本的单位是列，一列或多列形成一行，并由唯一的主键来确定存储。

所述逻辑模型中数据结构为键值对，所述键值对中的键从外层到内层依次是主键、列组、列和时间戳，所述键值对中的值就是存储的数据。

所述逻辑模型采用有序映射的映射方式，排序的依据是主键和时间戳，即先按照主键排序，再按照列排序，然后按照时间戳排序。

在所述主控系统和所述数据存储系统中，数据库的库、表、列组均以虚拟文件系统的目录结构进行组织，所述目录结构为一个数据库对应一个数据库目录，数据库目录下是表目录，表目录下是列组目录，列组目录下是若干数据文件。

所述数据文件中用于存储列式数据的数据结构为若干个数据块+文件元信息块+索引块+尾块，每一个数据块包括头信息+若干个KV键值对，每一个KV包括键部分的总长度KL+值部分的总长度VL+主键长度RL+主键值R+列组长度GL+列组名称G+列名称C+时间戳TS+键类型KT+列值Value，从RL至KT为键部分，Value为列值部分。

所述尾块中设置有指针，所述索引块记录数据块的偏移量，所述头信息包括KV键值对的数量。

所述数据存储系统能够根据查询条件创建或设置多层次扫描器，所述多层次扫描器包括表分区扫描器，列池扫描器，文件池扫描器/内存池扫描器，以及文件扫描器，表分区扫描器对应表分区，列池扫描器对应列池，文件池扫描器对应文件池，内存池扫描器对应内存池，文件扫描器对应分布式文件系统中的数据文件。

一种对数据库进行数据管理的方法，其特征在于，所述数据库是上述新型数据库，所述新型数据库在数据的组织形式上分为两级：表空间和表，所述表空间在数据库集群中能够被创建若干个，所述表能够在每一个表空间中被创建若干个，所述表能够被切分成若干个表分区。

客户端模块发起的创建表的请求中包含创建表所需要的元信息，所述元信息包括表名称、表包含的列组和列组下的列，主控系统接收到所述创建表的请求后根据表名称获取分布式锁，根据元信息在分布式文件系统中创建表对应的目录结构，通知数据存储系统加载表分区，更新元数据表并释放所述分布式锁。

所述元数据表是数据库集群第一次启动时自动创建的表，属于不可删除并且只供数据库集群内部访问的内部表，所述内部表还包括用户权限表和备份记录表。

所述表分区是对表的水平切分，所述水平切分是按照主键区间进行的切分，每个表分区均记录了主键的起止范围。

所述切分包括表的切分和表分区的切分，所述表的切分是指在创建表时进行预切分以形成若干个表分区，或者在数据写入过程中根据策略进行切分以形成若干个表分区，所述表分区的切分是在数据写入过程中根据策略进行切分以形成两个子分区，所述两个子分区分别为上部子分区和下部子分区。

所述数据写入过程包括当数据存储系统接受来自客户端模块的写请求后将数据写入到内存池中，当内存池数据量达到阈值则将内存池数据刷写到分布式文件系统中以形成数据小文件，随着内存池不断刷写而形成越来越多的数据小文件后，主控系统根据压缩策略将这些小文件合并为大文件，每次刷写或合并完成后，如果达到了切分策略的阈值，那么就对表分区进行切分，将一个表分区切分为两个子分区。

数据存储系统将切分状态通过一致性协调系统通知主控系统，重新分配分布式文件系统中的目录结构和数据文件，并更新主控系统上的元数据表中的数据，以便客户端模块能够发现新的子分区。

所述将一个表分区切分为两个子分区的过程包括以下步骤：1)表分区达到切分的阈值，数据存储系统准备切分，通知一致性协调系统准备对表分区进行切分；2)主控系统接收到一致性协调系统的通知，表分区将进行切分；3)数据存储系统在分布式文件系统对应的目录中创建切分子目录；4)数据存储系统关闭将要被切分的表分区，强制刷写表分区的缓存以将内存数据持久化到文件，并将表分区下线，若此时有客户端请求到此表分区上，那么数据存储系统会返回表分区不可用的信息，客户端得到此信息后会自动重试；5)数据存储系统在切分目录下创建两个子目录，以一对一的方式对应切分后的两个子分区，然后数据存储系统切分表分区，所述切分表分区只是在两个子目录下创建相应的软引用文件；6)数据存储系统创建切分后对应实际目录，所述实际目录是与被切分的表分区同级的目录，并将上一步创建的软引用文件拷贝到实际目录中；7)数据存储系统更新主控系统上的元数据表，更新将被切分的表分区的状态为下线，并新增两条记录，分别对应切分后的两个子分区，在元数据表中，两个子分区的状态为不可用，如果更新元数据表成功，表示表分区已经被成功切分，如果更新元数据表失败，那么主控节点以及其他数据服务器将重新打开被切分的表分区，并清理切分产生的脏状态和脏数据，并由主控系统负责整体回退工作；8)对于表分区已经被成功切分的情况，数据存储系统并行的打开两个子分区，打开子分区包括实际上线和状态未上线；9)数据存储系统更新元数据表中两个子分区的状态，并添加相应的元信息，所述元信息包括子分区所属的数据存储系统，此时两个新上线的子分区将代替原分区，对客户端提供服务，所述新上线包括实际上线和状态上线；10)数据存储系统更新一致性协调系统中的状态，从准备切分状态到已经切分状态，主控系统监听到状态改变，根据需要或策略决定是否重新负载均衡子分区到其他数据存储系统中；11)切分完成后，元数据表中、分布式文件系统中仍然会存在原分区相应的信息，这些信息将会在子分区的合并流程中被删除，垃圾清理任务也会定期检查子分区是否仍引用原分区，如果不引用，则原分区会被删除。

所述数据管理包括数据文件的合并，所述数据文件的合并采用主要合并方式或次要合并方式，所述次要合并是把多个小数据文件合并成一个大数据文件，所述主要合并是将列池下的所有数据文件合并为一个大数据文件，并做数据物理删除和多版本清理，以及数据本地化迁移。

所述数据管理包括可配置的负载均衡策略，通过选择以下指标中的一项或多项进行配置：1)每台数据存储系统的读请求数；2)每台数据存储系统的写请求数；3)每台数据存储系统的表分区数；4)表分区的移动代价；5)表分区的数据本地性；6)每张表占据数据存储系统中分区个数上限。

一种对数据库进行数据访问的方法，其特征在于，所述数据库是上述新型数据库，所述新型数据库的数据存储系统上托管着若干个表分区，数据访问请求的步骤包括表分区的查找，表分区的查找过程是对应用程序透明的，是在客户端模块内部自动完成的，查找到需要操作的表分区后再进行以下操作中的一种或多种：插入数据Insert操作，更新数据Update操作，删除数据Delete操作，查询数据Select操作。

所述表分区的查找过程包括客户端模块通过访问一致性协调系统得到元数据表所在的数据存储系统，通过访问元数据表得到目标表的分区信息，通过分区信息找到目标表所在的数据存储系统，所述元数据表所存储的表分区的元信息包括表名称、表分区覆盖的主键区间和表分区所属的数据存储系统。

所述插入数据Insert操作是指写入新数据，所述更新数据Update操作是指修改已有数据，所述插入数据Insert操作和所述更新数据Update操作具有相同的数据写入操作流程，在执行写入操作时，数据会写入到两个地方：预写日志和内存池，只有当这两个地方均写入确认后，才返回写入操作完成结果，所述预写日志用于应对以下情况：如果数据存储系统宕机，没有从内存池刷写到文件系统的数据能够通过回放预写日志来进行恢复。

所述内存池是内存里的写入缓冲区，数据在内存池中积累到一定数量后，其中的数据会一次性刷写到分布式文件系统中，每次刷写均在分布式文件系统中生成一个新的数据文件，数据文件对应列组，一旦生成是不可变的，列组与数据文件之间是一对多的关系，但一个数据文件只能存储一个列组的数据，在每个数据存储系统上，每个列组都有唯一与之对应的内存池。

所述查询数据Select操作为数据读取操作，在读取数据时，数据存储系统将文件池的持久化数据和内存池的未持久化数据重新衔接，在读操作上使用最近最少使用LRU算法缓存技术，这种缓存称为块缓存，块缓存保证频繁访问的数据是在内存中以避免重复地读数据文件，从数据存储系统中读取数据时，先检查内存池，然后检查块缓存，最后访问分布式文件系统磁盘上对应的数据文件。

所述删除数据Delete操作包括匹配目标数据后通过给目标数据打上删除标记进行逻辑删除，使得打上删除标记的目标数据不再被读取，等到执行数据文件合并的时候对逻辑删除的数据做物理删除，所述数据文件合并是将一个表分区内的各个列组对应的数据文件合并成一个数据文件。

所述插入数据Insert操作包括以下步骤：1)客户端访问一致性协调系统，获取元数据表所在的数据存储系统；2)客户端访问数据存储系统上的元数据表，获取目标表的分区情况；3)根据目标表的分区情况，计算得出待写入的数据所属的数据存储系统及其目标分区；4)客户端向目标数据存储系统的目标分区写入数据；5)目标数据存储系统向客户端反馈数据写入的结果，数据插入完成。

所述查询数据Select操作包括以下步骤：1)客户端访问一致性协调系统，获取元数据表所在的数据存储系统；2)客户端访问所述数据存储系统上的元数据表，获取目标表涉及的分区情况；3)根据查询条件以及所述分区情况，向目标数据存储系统发送查询请求；4)目标数据存储系统接收到查询请求后，根据查询条件创建扫描器，对本目标数据存储系统服务器上的分区进行扫描，返回查询结果；5)客户端接收到查询结果游标，遍历游标得到结果中的数据。

所述扫描器为多层次扫描器，所述多层次扫描器包括表分区扫描器，列池扫描器，文件池扫描器/内存池扫描器，以及文件扫描器，表分区扫描器对应表分区，列池扫描器对应列池，文件池扫描器对应文件池，内存池扫描器对应内存池，文件扫描器对应分布式文件系统中的数据文件。

一种用于实现上述新型数据库或上述方法而形成的计算机软件源程序和/或目标程序。

一种计算机存储介质，其特征在于，其上记录包括实现上述新型数据库或上述方法而形成的计算机软件源程序和/或目标程序。

本发明的技术效果如下：一种新型数据库和方法，能够通过数据库整体架构与分布式文件系统的结合，应对数据类型的更加丰富多样和数据规模的几何级数膨胀，代表了数据库技术发展的方向，具有十分重要的行业应用现实意义。

附图说明

图1是本发明新型数据库涉及的分布式文件系统结构示意图。图1中包括通过网络连接的节点1、节点2和节点3，节点1为本地节点，程序(用户)能够通过分布式文件系统在各个节点的磁盘上进行文件读写。当现有节点存储空间不足时，可以通过向分布式文件系统中添加新的节点来对存储空间进行扩容，例如图1中具有磁盘的新增节点4(网络计算机或者说联网计算机)。

图2是实施本发明一种新型数据库的结构示意图。图2中包括构建在分布式文件系统之上的数据库整体架构，所述数据库整体架构包括相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块，所述客户端模块供应用程序操作数据库使用，所述数据库整体架构可以为分布式集群模式，所述一致性协调系统、主控系统、数据存储系统等均可以为分布式集群模式，所述数据库整体架构与所述分布式文件系统之间通过文件系统模块连接。图2中a表示一致性协调系统与主控系统之间通过一致性协调系统交互模块连接，b表示一致性协调系统与数据存储系统之间通过一致性协调系统交互模块连接，c表示一致性协调系统与客户端模块之间通过客户端访问接口连接，d表示主控系统与客户端模块之间通过外部接口模块连接，e表示主控系统与数据存储系统之间通过请求处理模块连接，f表示数据存储系统与客户端模块之间通过请求处理模块连接。数据存储系统集群采用多活模式，数据存储采用列式存储模型，数据查询采用匹配不同存储层次的分层扫描器查找目标数据。主控系统集群采用一主多备模式(即一个活动节点以及一个或多个备用就位节点)。

图3是图2中一致性协调系统集群的结构示意图。图3中Leader为领导者节点(1个)，Observer为观察者节点(多个)，Follower为跟随者节点(多个)，这三类节点组成了一致性协调系统集群共同对外提供相关服务。一致性协调系统集群分别互连着客户端模块、数据存储系统和主控系统。

图4是图2中一致性协调系统内的数据结构。图4中的数据结构为树形结构，表示了根目录下的数据data1和data2，data1下的value1，data2下的value2和value3。

图5是图2中主控系统的结构示意图。图5中主控系统包括一致性协调系统交互模块，外部接口模块，指令执行模块，策略模块，以及文件系统模块。所述一致性协调系统交互模块与一致性协调系统进行交互，所述外部接口模块与外部访问请求进行交互，所述文件系统模块与分布式文件系统交互，所述指令执行模块分别互连着一致性协调系统交互模块、外部接口模块、策略模块和文件系统模块。所述一致性协调系统交互模块包括集群状态管理工具，负载均衡管理工具，数据存储系统管理工具，以及表状态管理工具。所述外部接口模块包括远程调用工具，监控指标工具，以及管理支持工具。

图6是图2中数据存储系统的结构示意图。图6中数据存储系统包括请求处理模块，一致性协调系统交互模块，预写日志模块，数据缓存模块，分区管理模块，以及文件系统模块。所述请求处理模块互连着预写日志模块、数据缓存模块、分区管理模块、主控系统和客户端模块，所述一致性协调系统交互模块分别互连着分区管理模块和一致性协调系统，所述文件系统模块分别互连着预写日志模块、分区管理模块和分布式文件系统。所述分区管理模块包括若干个表分区。

图7是图6中表分区的结构示意图。图7中的表分区包括若干个列池，每个列池中包括内存池和文件池，文件池中包括文件引用对象，每一个文件引用对象指向分布式文件系统中的一个数据文件。

图8是图6中预写日志模块所采用的日志结构示意图。图8中第一表分区R1和第二表分区R2共享一份预写日志。例如当发生涉及第一表分区R1的数据更新时，则录入一次数据更新，所述一次数据更新的记录的结构包括序列号，更新时间，表名，分区名，以及行级数据。

图9是图2中客户端模块的结构示意图。图9中客户端模块包括连接池和API(Application Program Interface，应用程序接口)，应用程序通过所述API实现数据库操作，所述连接池分别连接API、一致性协调系统、主控系统和数据存储系统。

图10是用户注册信息表数据所对应的行式存储模型和列式存储模型。图10中用户注册信息表包括六个字段(列名)，分别为用户名，密码，昵称，邮箱，手机号，以及微信号。六个字段下的三行数据中第一行是u001\123\张三\zs@demo.com\13500000000\…；第二行是u002\456\李四\ls@demo.com\13600000000\…；u003\789\王五\ww@demo.com\13800000000\…。图10中行式存储模型对数据按行存取(与上述行对应)，列式存储模型对数据按列存取，例如第一列为u001\u002\u003，第三列为张三\李四\王五。

图11是列式存储的文件结构示意图。图11中文件结构包括若干个数据块+文件元信息块+索引块+尾块，每一个数据块包括头信息+若干个KV(key-value，键值对)，每一个KV包括KL(键部分的总长度)+VL(值部分的总长度)+RL(主键长度)+R(主键值)+GL(列组长度)+G(列组名称)+C(列名称)+TS(时间戳)+KT(键类型)+Value(列值)。从RL至KT为键部分，Value为值部分。

图12是用户注册信息表在数据库整体架构中分区情况示例图。图12中包括数据存储系统A和数据存储系统B，数据存储系统A中包括分区R1和分区R2，数据存储系统B中包括分区R3和元数据表。客户端通过一致性协调系统获得元数据表位置信息即元数据表所属数据存储系统，通过元数据表获得分区与用户注册信息表主键区间的对应关系。用户注册信息表被切分为三个分区R1、R2和R3，R1、R2和R3以一对一的方式对应用户注册信息表的三段主键区间。主控节点分别连接一致性协调系统、数据存储系统A和数据存储系统B。客户端分别连接一致性协调系统、数据存储系统A和数据存储系统B。

图13是图2中数据存储系统的扫描器层次结构示意图。图13中扫描器层次结构包括表分区扫描器，列池扫描器，文件池扫描器/内存池扫描器，以及文件扫描器。表分区扫描器对应表分区，列池扫描器对应列池，文件池扫描器对应文件池，内存池扫描器对应内存池，文件扫描器对应分布式文件系统中的数据文件。

具体实施方式

下面结合附图(图1-图13)对本发明进行说明。

图1是本发明新型数据库涉及的分布式文件系统结构示意图。图2是实施本发明一种新型数据库的结构示意图。图3是图2中一致性协调系统集群的结构示意图。图4是图2中一致性协调系统内的数据结构。图5是图2中主控系统的结构示意图。图6是图2中数据存储系统的结构示意图。图7是图6中表分区的结构示意图。图8是图6中预写日志模块所采用的日志结构示意图。图9是图2中客户端模块的结构示意图。图10是用户注册信息表数据所对应的行式存储模型和列式存储模型。图11是列式存储的文件结构示意图。图12是用户注册信息表在数据库整体架构中分区情况示例图。图13是图2中数据存储系统的扫描器层次结构示意图。参考图1至图13，一种新型数据库，包括构建在分布式文件系统之上的数据库整体架构，所述数据库整体架构包括相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块，所述客户端模块供应用程序操作数据库使用，所述数据库整体架构通过文件系统模块与所述分布式文件系统连接，所述主控系统和所述数据存储系统分别通过一致性协调系统交互模块连接所述一致性协调系统，所述一致性协调系统通过客户端访问接口与客户端模块连接，所述数据存储系统通过请求处理模块分别与所述主控系统和所述客户端连接，所述主控系统通过外部接口模块与所述客户端模块连接。所述应用程序采用SQL语句通过所述客户端模块进行数据库操作，所述SQL语句中设置有包括列组名称描述项或列组名称句子成分以适配列式数据库中列式存储模型的列组设置；所述列式存储模型为包括所述列组的多级结构，所述SQL语句能够适配列式数据库中列式存储模型的多级列组结构；所述SQL语句具有以下功能设置：支持动态列作为静态字段和/或作为值的转换方法以适配列式存储模型中的列既能够作为字段也能够作为值的使用方式，支持动态列查询。所述数据库整体架构为分布式集群模式，所述一致性协调系统、主控系统、数据存储系统均为分布式集群模式。所述数据存储系统的分布式集群采用多活模式，所述主控系统的分布式集群采用一主多备模式。所述数据存储系统的数据存储采用列式存储模型，所述数据存储系统针对数据查询采用匹配不同存储层次的分层扫描器查找目标数据。

关于分布式文件系统，参看图1和图2，本发明新型数据库是构建在分布式文件系统之上的，数据库是运行在计算机操作系统中的一种软件程序，数据库的主要作用之一是存储数据，数据最终都要存放在文件系统中，即数据是存放在磁盘某些目录下的一个或多个文件中。关系数据库的数据是存放在本地目录中(即数据是存放在安装数据库软件的那台计算机上)，而一台计算机能够提供的存储空间有限，本地存储很难应对数据规模的增长。而本发明所述的新型数据库，其数据是存放在分布式文件系统中的。分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点(可理解为一台计算机)相连。多个节点组成了一个大的文件系统，允许文件和存储空间通过网络在多台节点上分享，如图1所示，在程序与用户看来，让实际上是通过网络来访问文件的动作，就像是访问本地的磁盘一般，而实际上目录和文件可能被分散存储到不同的节点上，甚至单个文件会被拆分成多个文件块分别存储到不同的节点，程序与用户无需关心文件存储的细节。当现有节点存储空间不足时，可以通过向分布式文件系统中添加新的节点来对存储空间进行扩容(图1中的虚线部分)，分布式文件系统支持扩容就相当于为程序和用户提供了近乎无限的存储空间，扩容的过程同样对程序和用户是透明的。

与关系数据库不同，本发明所属的新型数据库是一种分布式数据库，是由多个软件系统共同构成的，分别是：一致性协调系统、主控系统、数据存储系统、以及客户端模块，其中客户端模块不是独立的软件系统，而是供应用程序操作数据库使用，整套系统需要部署安装在由多个节点组成的计算机集群中，各组成部分及其相互关系如图2所示。图2中包括构建在分布式文件系统之上的数据库整体架构，所述数据库整体架构包括相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块，所述客户端模块供应用程序操作数据库使用，所述数据库整体架构可以为分布式集群模式，所述一致性协调系统、主控系统、数据存储系统等均可以为分布式集群模式，所述数据库整体架构与所述分布式文件系统之间通过文件系统模块连接。图2中a表示一致性协调系统与主控系统之间通过一致性协调系统交互模块连接，b表示一致性协调系统与数据存储系统之间通过一致性协调系统交互模块连接，c表示一致性协调系统与客户端模块之间通过客户端访问接口连接，d表示主控系统与客户端模块之间通过外部接口模块连接，e表示主控系统与数据存储系统之间通过请求处理模块连接，f表示数据存储系统与客户端模块之间通过请求处理模块连接。数据存储系统集群采用多活模式，数据存储采用列式存储模型，数据查询采用匹配不同存储层次的分层扫描器查找目标数据。主控系统集群采用一主多备模式(即一个活动节点以及一个或多个备用就位节点)。

关于图2中的一致性协调系统，一致性协调是指在分布式系统的环境下，对于多进程(即多个独立的程序)访问共享资源的一个协调和数据状态的一致性的保证。一致性协调系统采用Paxos算法(Paxos算法就是一种基于消息传递模型的一致性算法)保证一致性。另外，一致性协调系统本身也是集群环境，用来保证自身的高可用，在一致性协调系统集群中，各节点的角色主要分为三类，分别是：领导者(Leader，一个)、跟随者(Follower，多个)、观察者(Observer，多个)，如图3所示，三类节点组成了一致性协调系统集群，集群共同对外提供相关服务。

一致性协调系统集群中的各种角色(领导者、观察者、跟随者)之间的关系类似于一个集体决策机制，领导者是由决策机制选举出来的，负责发起投票和最终决策；跟随者参与投票决策过程；观察者可以接受客户端请求并转发给领导者，但不参与投票。一致性协调系统在其内部把数据组织为树形结构，如图4所示，客户端可以根据数据路径写入和获取相应的数据，类似于文件系统中的目录和文件，不同的是一致性协调系统是在内存中维护数据，不会将数据写入到磁盘中。

一致性协调系统与客户端之间的交互采用事件异步反馈机制，两者之间的通讯采用长连接(TCP协议)，客户端观察(Watch)一致性协调系统中的某些路径，一旦相关路径下的数据发生了变更，一致性协调系统会第一时间通知到订阅了相关路径的客户端。客户端在连接一致性协调系统时，会尝试连接一致性协调系统集群中的任意节点，只要与其中一个节点建立连接(指网络连接)，一致性协调系统就会记录该客户端的凭证，并为凭证设置一个有效期，如果客户端在有效期内没有任何请求，则凭证会过期，此客户端在一致性协调系统中创建的数据(树节点)也会被删除。客户端可以通过定时向一致性协调系统发送心跳来保持凭证的有效状态，即不停的向一致性协调系统报告客户端自身的健康状况。

一致性协调系统在数据库系统中扮演着非常重要的角色，本发明所述的新型数据库属于分布式数据库，一致性协调系统解决了分布式数据库中一些最基础的问题，包括：提供低延迟的KV(即key-value，键值对)存储服务、提供中心化的故障发现服务和提供分布式场景下的锁、计数、队列等协调服务。

关于提供低延迟的KV(即key-value，键值对)存储服务：通过一致性协调系统提供的API(客户端访问接口)可以操作存储在一致性协调系统中的数据(即操作树形结构)，包括创建节点、删除节点、修改节点数据、获取节点数据、获取子节点、观察(Watch)节点等，键值对(key-value)中的key是节点路径，value是节点数据，多个客户端可以对同一节点进行操作(例如一写多读)，从而达到数据在多个客户端之间交互和共享的目的。

关于提供中心化的故障发现服务：客户端A1连接到一致性协调系统后，可以创建相应的节点(如/app_1)，其他客户端连接到一致性协调系统后，可以通过观察/app_1节点来得知客户端A1的健康状况，一旦客户端A1发生故障(即没有了心跳)，由客户端A1创建的节点/app_1会被删除，观察/app_1的所有客户端会得到通知(/app_1被删除)，进而得知客户端A1已经发生故障。

关于提供分布式场景下的锁、计数、队列等协调服务：分布式场景下，如果需要对共享资源进行访问，那么就需要有分布式锁、分布式计数器等服务的支持，例如多个窗口售票的场景，剩余票源是共享资源，售票系统出票时就需要分布式锁的支持，只有在获取到锁之后才能出票，有效的防止了一票多卖。客户端A1连接到一致性协调系统后，先获取某一路径下的节点数据(例如获取/lock节点的数据)，若节点数据为空，则将数据更新为a1(相当于客户端A1获取到了锁)，其他客户端在做相同的操作时，发现/lock节点的数据为a1，说明锁已经被占用，则可以等待客户端A1释放锁(即观察/lock节点以便及时得到通知)，或放弃获取锁。

在本发明中，利用一致性协调系统提供的上述关键服务，实现了主控系统的HA(High Available，即高可用)、数据存储系统的故障发现和监测、分布式锁等一系列功能(详见后续章节)。一致性协调系统在整体架构中主要起保障性作用，其自身并不负责实际的数据存储和管理。

关于图2中的主控系统：主控系统主要负责数据库的各种管理工作，包括：1)管理数据服务器，实现其负载均衡；2)管理和分配表分区(也可称为表分片，本发明所述的数据库会对表进行自动分片，见后续章节)；3)实现DDL(Data Definition Language，这里指数据定义)操作(如创建数据库、创建表、修改列等)；4)管理数据库和表的元数据；5)权限控制。主控系统的架构、模块、以及模块间的关系如图5所示。图5中主控系统包括一致性协调系统交互模块，外部接口模块，指令执行模块，策略模块，以及文件系统模块。所述一致性协调系统交互模块与一致性协调系统进行交互，所述外部接口模块与外部访问请求进行交互，所述文件系统模块与分布式文件系统交互，所述指令执行模块分别互连着一致性协调系统交互模块、外部接口模块、策略模块和文件系统模块。所述一致性协调系统交互模块包括集群状态管理工具，负载均衡管理工具，数据存储系统管理工具，以及表状态管理工具。所述外部接口模块包括远程调用工具，监控指标工具，以及管理支持工具。

关于图5中的集群状态管理：在整个数据库集群中，主控系统是一主多备模式，主控系统部署到多个节点上启动后，会在一致性协调系统的/master路径下创建相应的子节点(即/master/...是主控系统列表)，通过一致性协调系统的分布式锁机制，选定一个节点为活动节点(Active节点)，保证只有一个节点上的主控系统对外提供服务，其他节点处于就位状态(StandBy，就位节点)，当Active节点上的主控系统发生故障时，通过一致性协调系统的故障发现机制，其他节点上的主控系统将得到通知并重新选定Active节点，自动接管故障节点的工作，完成故障迁移(Failover)，故障迁移的具体工作是在指令执行模块中完成的。当故障节点修复完成后，可以作为新的StandBy节点重新加入到/master路径下。

关于图5中的数据存储系统管理：与主控系统的一主多备模式不同，数据存储系统属于多活模式，即数据库集群中可以有任意多个(至少一个)数据存储系统，在正常情况下，集群中所有的数据存储系统均处于活动状态(Active状态)，其自身的一些关键信息(如服务器地址、进程编号、健康状况等)会存储在一致性协调系统中(节点路径为/data-server/...)。主控系统通过订阅一致性协调系统中相应节点来监测各数据存储系统的健康状况、活动状态等信息，并对数据存储系统出现的各种状况作出响应(通过调用指令执行模块完成具体工作)。当某一数据存储系统发生故障时，主控系统会接收到通知并调用指令执行模块，对故障进行处理，主要是将发生故障的数据存储系统中的数据托管到其他正常的数据存储系统中。当新的数据存储系统加入到数据库集群中时(数据库扩容)，主控系统也会通过一致性协调系统接收到想应的通知，主控系统将通过指令执行模块完成扩容工作，主要根据扩容策略是将原有的数据存储系统的部分数据托管到新加入集群的数据存储系统中。从故障中恢复的数据存储系统再次加入到集群中时，其处理逻辑与数据库扩容的处理逻辑一致。

关于图5中的负载均衡管理：数据库集群随着数据读写、数据库扩容、以及故障等情况的发生，托管在的数据存储系统中的数据会出现分配不均匀的情况(即集群中各个数据存储系统的压力不均衡)，当这种不均衡的情况累积到一定程度时(根据负载均衡策略，主控节点会计算并量化相关的阈值)，策略模块会主动触发集群重新负载均衡，也可以通过外部接口模块由外部(如客户端)触发集群负载均衡，负载均衡的实际工作由指令执行模块完成。集群在进行负载均衡时，核心工作就是对数据(即表分区)进行重新分配(ReAssignment)，按照负载均衡策略将数据合理的托管到不同的数据存储系统中，此过程中主控系统会通过一致性协调系统获取分布式锁，防止在负载均衡过程中再次发生负载均衡，同时主控系统也会通过一致性协调系统对相应的数据存储系统及其数据加锁，防止其他工作(如新数据写入、数据库扩容等)影响负载均衡的过程。当负载均衡工作完成后，主控系统会释放相关的锁，并通过一致性协调系统告知整个集群已完成负载均衡。

关于图5中的表状态管理：本发明中，数据是存储在数据库的表中，数据表具有多种状态，包括：创建状态、修改状态、正常状态、切分状态、上线状态、下线状态等，各种状态代表了主控系统对数据表的各种处理过程，主控系统通过与一致性协调系统的交互完成处理过程中对表状态的获取、监控、变更等工作。以创建数据表为例，主控系统首先在一致性协调系统中创建相应的表节点(节点路径为/table/表名称)，并将节点数据置为creating(即正在创建)，当表创建完成后会将节点数据置为assigning(即正在分配托管的数据存储系统)，当表分配完成后会将节点数据置为loading(即正在加载数据表)，当表加载完成后，会将节点数据置为online(即表已上线)，至此完成数据表创建工作，数据表可以正常使用(即可以接收数据读写请求)。集群中的各个组成部分会及时接收到数据表的状态变更，并根据表的状态来决定做出适当的反馈，例如当数据表正处在creating状态时，客户端发起对数据表的写入请求，此时集群会拒绝请求，并通知客户端数据表尚未创建完成，当数据表正处在loading状态时，客户端发起对数据表的写入请求，此时集群会等待表加载完成(等待超时策略会控制等待时间，不会无限期等待)，然后再处理客户端的写入请求。

关于图5中外部接口模块：主控系统通过外部接口模块来对外提供服务和访问通道，对外是指主控系统之外的部分，即包括集群的其他组成部分(如客户端模块、数据存储系统、一致性协调系统)，也包括外部系统，外部访问请求主要包括以下3类，数据管理请求、监控指标请求和集群状态请求。

1)数据管理请求，如创建表、负载均衡、用户授权等，访问方式为RPC(remoteprocedure call，远程方法调用)，此种方式主要供集群内部以及客户端模块使用，通过RPC可以直接集群进行管理。

2)监控指标请求，如表读写次数、平均响应时间等，监控指标提供插件扩展机制和规范，允许各种外部系统按照规范开发插件，外部接口模块会加载插件并在运行过程中将监控指标发送到插件中，插件负责对指标数据进行处理(如页面图形展示、短信告警通知等)。

3)集群状态请求，如表存储情况、数据存储系统分布情况等，集群指标通过RestAPI方式供外部访问(即通过URL地址获取集群状态，类似于访问网页)。

其中，数据管理请求会转发到指令执行模块，由指令执行模块完成实际的工作(例如创建表的工作)，其他两类请求会根据具体请求调用不同模块完成，如数据存储系统分布情况会通过查询系统表(见下文)获取相关信息，如表读写次数是在主控系统的内存中存储的(读写次数分别存储在ReadCount对象和WriteCount对象中，两个对象均为Map结构，即内存中维护了两个字典，字典的键是表名称，键对应的值是读次数或写次数)，直接从内存中获取即可。

关于图5中策略模块：策略模块用于管理集群中各种类型的处理策略，包括：负载均衡策略、表切分策略、故障恢复策略、扩容策略、数据压缩策略等。不同类型的处理策略均是可配置化的，可以根据实际需要选择不同的策略模型，策略模型代表了具体任务的触发机制和执行逻辑。

以负载均衡为例，如前文所述，主控系统的策略模块会监测集群中的数据存储状况，策略模块会根据具体的负载均衡策略量化计算数据不均衡的程度，并判断其程度是否达到负载均衡策略中定义的阈值(例如数据存储系统中托管的表分区数量之差大于5，即有节点表分区多，有的节点表分区少)，如果达到阈值，策略模块会触发集群进行负载均衡工作，根据负载均衡策略决定如何进行负载均衡(如将表分区从托管量最多的数据存储系统迁移到托管量最少的数据存储系统)，具体的托管迁移工作(如将表分区R1从A节点迁移至B节点)是由策略模块调用指令执行模块完成。

关于图5中文件系统模块：本发明所述的新型数据库是构建在分布式文件系统之上的，所有需要持久化的数据均存放在分布式文件系统中，主控系统中的文件系统模块的主要作用就是与分布式文件系统进行交互，主控系统的数据读写全部交由文件系统模块完成，通过文件系统模块有效的屏蔽了不同类型的分布式文件系统的差异，对主控系统的其他模块来说就不必关心数据是如何进行读写的。

以创建表为例，主控系统通过文件系统模块会在分布式文件系统中创建文件夹、文件等，表加载的过程(loading)又会通过文件系统模块读取相应的文件夹、文件等，主控系统只需要关注逻辑上的目录、文件，实际存储、读写方式交由文件系统模块完成。

关于图5中指令执行模块：指令执行模块负责具体的任务处理，指令执行模块提供了一系列明确的指令，其不会主动执行指令，而是等待其他模块调用。其他模块在经过相应的请求处理、逻辑判断之后，任务最终会生成一个或多个明确的指令，由指令执行模块完成指令的执行工作。

指令执行模块提供了指令池机制来应对高并发的指令执行，并且能够有效防止系统过载。指令池机制类似于物流车队，车队会提前配备一定数量的、不同型号的车辆，当有新的运输任务时，根据运输的距离、货物类型、载重量等因素选择不同的车辆来承担运输任务，并且会对货物进行搭配，保证车辆满载进而提高运输效率。如果任务过多没有可调配的车辆时则会将货物暂存在仓库中等待车辆，如果仓库已满则会拒绝接单。

在主控系统中，由其他模块生成的指令相当于运输任务，指令交由指令执行模块进行处理时，会根据任务类型从指令池中选择合适的执行器，并会根据执行器的处理能力对任务进行拆分或合并。

以负载均衡为例，经过负载均衡策略的处理，形成了一系列表迁移的指令，如将表分区R1从A节点迁移至B节点、将表分区R2从A节点迁移至C节点，指令执行模块会根据迁移的任务量选择合适的执行器来完成具体的表迁移工作。

关于图2中数据存储系统：主控系统负责数据库集群的管理控制工作，但并负责实际的数据存储和读写，数据存储和读写是由数据存储系统来完成的，即数据存储系统对外提供数据读写服务、处理数据读写请求、以及实际的数据存储工作，数据存储系统的架构、模块如图6所示。图6中数据存储系统包括请求处理模块，一致性协调系统交互模块，预写日志模块，数据缓存模块，分区管理模块，以及文件系统模块。所述请求处理模块互连着预写日志模块、数据缓存模块、分区管理模块、主控系统和客户端模块，所述一致性协调系统交互模块分别互连着分区管理模块和一致性协调系统，所述文件系统模块分别互连着预写日志模块、分区管理模块和分布式文件系统。所述分区管理模块包括若干个表分区。

关于图6中的请求处理模块：请求处理模块负责接收客户端模块的数据读写请求，以及返回请求的执行结果。请求处理模块通过RPC(remote procedure call，远程方法调用)方式与客户端模块进行交互，请求处理模块提供了读写数据的基础操作，包括：插入数据(Insert)、更新数据(Update)、删除数据(Delete)、查询数据(Select)。除与客户端模块交互之外，请求处理模块还会接收主控系统发起的数据管理请求，例如通过主控系统创建表时，在表加载过程(loading)中主控系统会通过请求处理模块告知数据存储系统加载具体的表分区。请求处理模块在处理具体的数据读写请求过程中，还会产生(或更新)相应的监控指标(如表读写次数、请求平均响应时间)，监控指标会上报到主控系统中进行汇总。

关于图6中的一致性协调系统交互模块：如前所述，在数据库集群中，数据存储系统为多活模式，即整个集群中存在一个或多个数据存储系统，其基本信息(如服务器地址、健康状况等)会通过一致性协调系统交互模块存储到一致性协调系统中。同时，数据存储系统也会通过一致性协调系统交互模块从一致性协调系统获取主控系统的相关信息(如服务器地址、活动节点等)。

关于图6中的文件系统模块：同主控系统中的文件系统模块作用类似，数据存储系统的所有数据持久化工作均通过文件系统模块完成，屏蔽了底层不同类型的分布式文件系统带来的差异。数据存储系统通过文件系统模块读写的数据包括：预写日志；数据文件。两种类型的数据均为实际的数据(即业务数据)，只是其存储机制和文件格式不同，具体见后续章节。

关于图6中的分区管理模块：分区管理模块负责表分区的管理(托管)、数据的读写。如前文、及后续章节所述，本发明所述的数据库是一种分布式数据库，数据库中的表会被自动切分并分配给不同的数据存储系统进行管理(托管)。数据库集群中会存在若干数据存储系统，每个数据存储系统负责一部分表分区的管理，托管在数据存储系统中的多个表分区之间没有关联性，不论表分区是否隶属于同一张表，其管理上均是独立进行的。另外，随着数据读写会触发的表分区的再次切分、以及重新负载均衡，或者发生故障、扩容等状况，托管在某个数据存储节点上的表分区可能会迁移到其他数据存储节点上。托管在数据存储系统中的表分区，其具体的管理工作、以及数据读写请求的处理，是在分区管理模块中完成的。分区管理模块管理着多个表分区，在分区管理模块中表分区的结构如图7所示。图7中，表分区是由多个列池组成，本发明所述的数据库采用列式存储模型(见后续章节)，表是由多个列组构成，对应的在表分区中会有多个列池，列池内又分为内存池和文件池，文件池中会有多个文件引用，文件引用指向分布式文件系统的数据文件。

在分区管理模块处理数据写入请求时，写入的数据根据其所属的列组放入不同的内存池中，当内存池积攒到一定阈值后，一个表分区的所有内存池会统一将数据从内存持久化到分布式文件系统中，此种持久化过程称为刷写，每刷写一次就会在分布式文件系统中生成N个数据文件(N是表分区中内存池的数量，也是表的列组数量)。

可见，内存池只是暂存数据，最终数据都要持久化到分布式文件系统中。之所以要在内存池中暂存数据，是因为分布式文件系统不支持对文件的随机写入(因为文件会拆分为文件块，文件块是不可变的)，只能通过内存池暂存，然后批量写入新的数据文件，相当于表中的数据是分散存放在许多数据文件中的。若系统发生故障时，内存池中还未持久化的数据就会丢失，防止数据丢失的措施是预写日志(见后续章节)。

在分区管理模块处理数据读取请求时，会先从内存池中查找数据，若未找到则会从数据文件中查找数据，直到找到目标数据或找完此分区中全部的数据文件。实际上，数据读取请求会先经过数据缓存模块(见后续章节)，若未命中缓存，读请求才会交由分区管理模块处理。

关于图6中的预写日志模块：本发明所述的新型数据库是一种分布式数据库，数据库的各个部分共同组成了分布式集群，集群(多台计算机)中很难保障每台计算机以及网络通讯不出故障，当故障发生时，分布式集群必须能够提供故障恢复机制，来保证整个集群的鲁棒性(Robust)，是健壮和强壮的意思，软件系统在输入错误、磁盘故障、网络过载等情况下，能否不死机、不崩溃，就是该软件的鲁棒性。对数据库系统来说，故障恢复的核心是数据恢复，数据可恢复是通过预写日志模块来保障和实现的。

请求处理模块接收到写入请求(Insert、Update、Delete)后，首先会通过预写日志模块将数据追加到预写日志中，然后才会将数据写入到分区管理模块的内存池中，直到内存池中的数据积攒到一定程度后再将这一批数据写入到分布式文件系统中(见后续章节)。数据存储在内存中是不可靠的，在节点发生故障(如断电)的情况下数据很可能会丢失。解决这个问题的方法是预写日志，所有数据更改都会先写入日志，只有写入成功才会通知客户端操作成功。

在正常情况下，预写日志并不会被读取，但如果数据存储服务器出现某些异常发生宕机，此时内存池中尚未持久化的数据就会丢失，就需要回放预写日志对丢失的数据进行恢复。预写日志机制类似于观看视频直播，在观看节目的同时进行录制，如果因为某些原因造成某些片段没有看到，可以通过回放录像来补救。

每个数据存储服务器会管理(托管)多个表分区(表分区可能隶属于不同的数据表)，但每个数据存储系统只会维护一份预写日志，对各个表分区的数据更改都会写入到同一份预写日志中。预写日志的基本结构如图8所示。在数据存储系统中，所有的数据更新都会以追加的形式记录到预写日志中，预写日志会通过文件系统模块持久化到分布式文件系统中。

预写日志并不会永久存储在系统中，它的生命周期分为如下阶段：1)日志构建：所有的数据写入操作都会先记录到预写日志中；2)日志滚动：预写日志模块每隔一段时间会创建一个新的日志文件，记录新的数据写入；3)日志过期：当分区管理模块把内存中的数据持久化后，就不再需要对应的预写日志，其日志文件会被标记为过期；4)日志删除：主控节点的策略模块会根据策略删除过期的日志。

关于图6中的数据缓存模块：在本发明中，为提升数据库的读性能，采取的一种重要手段是数据缓存，将热点数据存储到内存中，避免高代价的IO开销。

请求处理模块在接收到读请求后，先从数据缓存模块查找数据，若命中缓存(即在缓存中查找到数据)，则直接返回数据，不必再从数据文件中查找数据；若未命中缓存，则会由分区管理模块从数据文件中查找数据，若查找到数据则会将数据放入缓存并返回数据。

数据缓存模块才采用LRU淘汰算法(Least Recently Used，最近最少使用)，当缓存的数据达到一定阈值之后，就会启动淘汰策略，缓存中最近最少使用的数据会被置换出来，保证了热点数据(活跃数据)始终在缓存中。

关于图2中客户端模块：客户端模块不是独立的软件系统，是一种操作数据库的SDK(Software Development Kit，软件开发工具包)，应用程序可以基于SDK对本发明所述的数据库进行管理和操作。客户端模块负责与数据库集群通讯、发起请求和接收结果，客户端模块内部组成如图9所示。图9中客户端模块包括连接池和API(Application ProgramInterface，应用程序接口)，应用程序通过所述API实现数据库操作，所述连接池分别连接API、一致性协调系统、主控系统和数据存储系统。

连接池是客户端模块进行数据库操作的基础，连接池维持了客户端模块到数据库集群的连接，例如数据库集群中有2个主控系统(一主一备)，7个数据存储系统(多活)，那么连接池会维持至少1个与主控系统(Active节点)的连接、7个与数据存储系统的连接。其中，主控系统的地址、数据存储系统的地址，以及集群的其他信息，客户端模块是通过一致性协调系统获取的。应用程序通过客户端模块操作数据库基本步骤如下：

1)传入配置信息，主要是一致性协调系统的地址；

2)创建数据库连接，客户端模块首先连接到一致性协调系统，通过一致性协调系统获取整个数据库集群的相关信息(并缓存到客户端模块)，并建立与主控系统、数据存储系统的连接；

3)管理或操作数据库，通过客户端模块提供的API，将操作指令以及数据传递到集群中(如创建表会传递到主控系统，读写数据会传递到数据存储系统)执行，并返回结果；

4)关闭数据库连接。

其中，数据库连接可以多次重复使用，不必每次操作均重新创建连接、关闭连接，即，步骤1、2、4可以看做是一次性的，步骤3可以多次执行。同时，连接池可以管理多个数据库连接，即客户端模块可以同时连接到不同的数据库集群，而且连接池会对数据库连接资源的协调、错误的处理做统一管理。

客户端模块提供的API还屏蔽了表分区带来的复杂性，应用程序层面无需关心表分区的具体细节，通过API操作的粒度是表，而非表分区。例如一个跨分区的查询，客户端模块会根据从数据库集群中获取的表分区信息，同时发起两个查询操作，并负责合并两个分区的查询结果，最后才返回数据到应用程序端。

当数据库集群发生变化时(如扩容、负载均衡、故障切换等)，客户端模块会及时得到来自一致性协调系统的通知，接收到响应的通知后，客户端模块会更新本地缓存的集群信息，并重新连接数据库集群——有些情况需要重新连接，比如主控系统发生了failover(即发生主备切换)，客户端需要连接到新的Active主控节点。

关于数据模型中存储模型、逻辑模型和物理模型等分别加以如下说明。

关于存储模型：本发明所述的数据库的存储模型采用列式存储(Column-based)，列式存储相对于传统关系数据库的行式存储(Row-based)来说的，可以通过图10直观的看到两者的不同。如图10所示，用户注册信息表包括六个字段(列名)，分别为用户名，密码，昵称，邮箱，手机号，以及微信号。六个字段下的三行数据中第一行是u001\123\张三\zs@demo.com\13500000000\…；第二行是u002\456\李四\ls@demo.com\13600000000\…；u003\789\王五\ww@demo.com\13800000000\…。图10中行式存储模型对数据按行存取(与上述行对应)，列式存储模型对数据按列存取，例如第一列为u001\u002\u003，第三列为张三\李四\王五。

从图10中可以看出，相同的示例数据(用户注册信息)，在行式存储模型中数据被组织为行(按行存取)，在列式存储模型中数据是按列存取的。与行式存储相比，列式存储的主要优缺点如表1所示：

表1-列式存储与行式存储的对比

另外，在列式存储中，各列的数据都是独立读写的，一列的数据类型一般情况下都是相同的，可以实现更加高效的数据压缩，更加适合海量数据的存储。

本发明所述的新型数据库，其存储模型在列式模型的基础上提出了列组模型(ColumnGroup-based)，即列式模型中的列以进行分组，列组(ColumnGroup)的优势在于：对于宽表(即表的列数很多)而言可以通过列组区分不同的业务含义，在列组层面采取不同的数据约束条件、安全策略等。以上述的用户注册信息为例，用户名、密码、昵称、邮箱可以分为一组(基本信息组)，手机号、微信号等可以分为一组(社交账号组)，针对此两组可以分别进行授权(读写权限)，社交账号组还可以允许增加其他账号、允许为空等。

关于逻辑模型：在逻辑模型中，最基本的单位是列，一列或多列形成一行，并由唯一的主键来确定存储。反过来，一个表中有若干行，其中每列可能有多个版本(时间戳)，每个版本存储了不同的值。表的逻辑模型可以看作是键值数据库，即有序映射的映射。从外层到内层的键依次是主键、列组、列、时间戳，值是存储的数据。另外，映射是有序的，排序的依据是主键和时间戳，即先按照主键排序，再按照时间戳排序。用Java语言来描述这种模型的话，可以表示成如下的数据结构：Map<主键,Map<列组,Map<列,Map<时间戳,值>>>>。

关于物理模型：存储的数据最终会转换成二进制格式进行存储，在分布式文件系统中，数据以固定大小的数据块进行存储，对于超过数据块大小的文件需要进行切割，文件的元信息(大小、位置等)存储在主控系统上，通过分布式文件系统屏蔽数据的存储细节，对上层组件来说，文件始终是完整的、可用的。对上层组件(主控系统、数据存储系统)来说，数据是按列存储的，数据库、表、列组均以虚拟文件系统的目录结构进行组织，一个数据库是一个目录，数据库目录下是表目录，表目录下是列组目录，列组目录下是若干的数据文件。数据文件中的内容是一种特殊的数据结构，可以高效的存储列式数据。文件的结构如图11所示，图11中文件结构包括若干个数据块+文件元信息块+索引块+尾块，每一个数据块包括头信息+若干个KV(key-value，键值对)，每一个KV包括KL(键部分的总长度)+VL(值部分的总长度)+RL(主键长度)+R(主键值)+GL(列组长度)+G(列组名称)+C(列名称)+TS(时间戳)+KT(键类型)+Value(列值)。从RL至KT为键部分，Value为值部分。数据块的长度是可变的，唯一固定的块是文件元信息块和尾块。尾块中包含着指向其他块的指针，它是在持久化数据到文件结束时写入的，写入后即确定其成为不可变的数据存储文件。索引块记录数据块的偏移量。每个数据块都包含一个头信息(记录了数据块的KV数量等信息)和一定数量的序列化的KV(即key-value，键值对)。每个KV都是一个底层的字节数组(二进制格式)，它允许零复制访问数据。KV的结构以两个分别表示键长度(KL)和值长度(VL)的定长数字开始，有了这个信息，就可以在数据中跳跃，直接访问某一部分的值。

关于数据管理中表的创建、表的切分、数据文件的合并、负载均衡等分别加以如下说明。

关于表的创建：本发明所述的数据库，在数据的组织形式上，分为两级：表空间和表，即在数据库集群中可以创建若干表空间，表空间下可以创建若干表——表空间可以视为对表进行分组。数据是存储在表中的，客户端模块提供的API也主要是以表为粒度对数据库进行管理和操作的。然而在实际的存储模式中，表会被切分成若干的表分区——这是本发明对海量数据存储做出的重要设计之一。

客户端模块发起创建表的请求，请求中包含创建表需要的各种信息(如表名称，表包含的列组、列等，这些信息统称为元信息)，请求会被发送到主控系统中，主控系统首先根据表名称获取分布式锁，获取锁后根据元信息在分布式文件系统中创建表对应的目录结构，然后通知数据存储系统加载表分区，最后更新元数据表并释放锁。元数据表是在数据库集群第一次启动时自动创建的表，此表不可删除并且只供集群内部访问(统称为内部表)，元数据表用于存储其他表的信息(如其他表的分布情况)。除元数据表外，类似内部表的还包括：用户权限表、备份记录表等。

关于表的切分：在整体架构中，表会被切分成若干的表分区，可以在创建表时进行预切分，或者在数据写入过程中根据策略进行合理的切分。表分区是对表的水平切分——按照主键进行切分，每个表分区均记录了主键的起止范围。当数据存储系统接受来自客户端模块的写请求后，先将数据写入到内存池中，当内存池数据量达到阈值时会将数据刷写到分布式文件系统中(形成数据文件)，随着内存池不断刷写，会形成越来越多的数据文件。主控系统会根据压缩策略将这些小文件合并为大文件，每次刷写或合并完成后，如果达到了切分策略的阈值，那么就会对表分区进行切分，将一个表分区切分为两个子分区。

由于所有的数据文件是不可变的，切分时不会将原文件中的数据写入到新创建的子文件中，而是创建两个软链接文件，称为参考文件，根据计算出来的切分点(即主键的值)，两个子文件分别指向原文件的顶部或底部，参考文件可以向普通数据文件一样使用，但每个参考文件只有原文件一半的记录(上半部分或下半部分)。只有原文件不是参考文件的情况下才可以被切分，参考文件通过不断的合并会逐渐被清理(形成真正的数据文件)，不需要再引用原文件(没用的原文件在合并过程中会被删除)，形成真正的数据文件后，就可以进一步被切分。

虽然表分区的切分是在数据存储系统层面触发的，但切分的过程必须有主控系统和一致性协调系统的参与。数据存储系统将切分状态通过一致性协调系统通知主控系统，重新分配分布式文件系统中的目录结构和数据文件，并更新主控系统上的元数据表中的数据，以便客户端模块能够发现新的子分区。表分区切分是一个多任务的过程，数据存储系统在切分过程中会在内存中记录执行状态日志，以便出错时回滚。

表分区切分的详细流程如下：

1)表分区达到切分的阈值，数据存储系统准备切分，通知一致性协调系统准备对表分区进行切分；

2)主控系统接收到一致性协调系统的通知，表分区将进行切分；

3)数据存储系统在分布式文件系统对应的目录中创建切分子目录；

4)数据存储系统关闭将要被切分的表分区，强制刷写表分区的缓存(将内存数据持久化到文件)，并将表分区下线，若此时有客户端请求到此表分区上，那么数据存储系统会返回表分区不可用的信息，客户端得到此信息后会自动重试；

5)数据存储系统在切分目录下创建两个子目录(上分区、下分区)，分别对应切分后的两个子分区，然后数据存储系统切分表分区，如前所述，切分只是在两个子目录下创建相应的软引用文件；

6)数据存储系统创建切分后对应实际目录(即与被切分的表分区同级的目录)，并将上一步创建的软引用文件拷贝到实际目录中；

7)数据存储系统更新主控系统上的元数据表，更新将被切分的表分区的状态为下线，并新增两条记录，分别对应切分后的两个子分区，在元数据表中，两个子分区的状态为不可用，如果更新元数据表成功，表示表分区已经被成功切分，如果更新元数据表失败，那么主控节点以及其他数据服务器将重新打开被切分的表分区，并清理切分产生的脏状态和脏数据，并由主控系统负责整体回退工作；

8)数据存储系统并行的打开两个子分区(实际上线、状态未上线)；

9)数据存储系统更新元数据表中两个子分区的状态，并添加相应的元信息(如所属的数据存储系统等)，此时两个新上线的子分区将代替原分区，对客户端提供服务(实际上线、状态上线)；

10)数据存储系统更新一致性协调系统中的状态，从准备切分到已经切分，主控系统监听到状态改变，如果需要的话可以重新负载均衡子分区到其他数据存储系统中；

11)切分完成后，元数据表中、分布式文件系统中仍然会存在原分区相应的信息，这些的信息将会在子分区的合并流程中被删除，垃圾清理任务也会定期检查子分区是否仍引用原分区，如果不在引用，则原分区会被删除。

关于数据文件的合并：在整体架构中，表由若干表分区组成(对应表的水平分片)，表分区由若干列池组成(对应表的各个列组)，列池由内存池和文件池组成，内存池是写缓存，数据会先写入到内存池中(另外还有预写日志)，内存池根据一定的算法将数据刷写到分布式文件系统中(在表分区层面上统一刷写)，形成新的数据文件。长时间刷写会产生大量的小文件，影响读性能(查找数据需要扫描大量文件)，系统会根据配置的策略对池进行合并，将若干数据文件合并为一个大的数据文件，合并有两种，主要合并和次要合并，其中次要合并把多个小数据文件合并成一个大数据文件，主要合并会将列池下的所有数据文件合并为一个大数据文件，并做数据物理删除和多版本清理，以及数据本地化迁移，即处理由重新负载均衡引起的数据不在本地的问题(负载均衡会分配表分区到其他数据存储系统托管，但不会做数据迁移)。

关于负载均衡：表在水平切分之后，系统会根据负载均衡策略，对表分区进行重新分配(托管到不同的数据存储系统上)，达到多个数据存储系统的负载均衡——数据读写上的均衡——是逻辑上的重新分配，不会移动数据文件(移动数据文件会造成存储层面上的远程读写)，直到主要合并时才会将数据从远端移动到本地。负载均衡由主控系统自动触发，或由外部强制触发(客户端程序或命令)。

负载均衡策略是可配置的，可以根据实际情况选择不同的策略，以达到最好的负载均衡效果，默认的负载均衡策略会根据如下的指标决定如何进行负载均衡：1)每台数据存储系统的读请求数；2)每台数据存储系统的写请求数；3)每台数据存储系统的表分区数；4)表分区的移动代价；5)表分区的数据本地性；6)每张表占据数据存储系统中分区个数上限。

关于数据访问，数据读写服务是由数据存储系统来提供的，数据存储系统上托管着若干表分区，所有的数据访问请求(SELECT、INSERT、UPDATE、DELETE)的首要步骤是查找需要操作的表分区，表分区的查找过程是对应用程序透明的，是在客户端模块内部自动完成的。关于数据访问中、数据写入、数据读取、数据删除等分别加以如下说明。

关于表分区的查找：表分区是按照主键进行水平切分的，为了让客户端能够找到包含特定主键的表分区，系统提供了特殊的元数据表。元数据表存储了系统中所有表分区的元信息(如表分区的主键范围、所属的数据存储系统等)，元数据表的位置信息(即元数据表是托管在哪个数据存储系统中的)是存储在一致性协调系统中的。客户端模块通过访问一致性协调系统得到元数据表的位置，然后通过访问元数据表得到目标表的分区信息，最后找到目标表的特定分区所在的位置(数据存储系统)。客户端模块会逐步缓存元数据表中的数据，后续的数据访问就不需要再次访问一致性协调系统和元数据表，直接根据缓存的信息找到目标表的分区。当元数据表发生变更时，客户端模块会更新缓存。

关于数据写入：数据写入时，无论插入新行(Insert)还是修改已有的行(Update)，其内部流程都是相同的。在执行写入操作时，数据会写入到两个地方：预写日志和内存池。只有当这两个地方均写入确认后，才认为写操作完成。内存池就是内存里的写入缓冲区，数据在内存池中积累到一定数量后(内存池写满)，其中的数据会一次性刷写到分布式文件系统中，每次刷写会在分布式文件系统中生成一个新的数据文件。数据文件对应列组，一旦生成是不可变的，一个列组可以有多个数据文件，但一个数据文件只能存储一个列组的数据。在集群的每个数据存储系统上，每个列组都有唯一与之对应的内存池。为应对大型分布式系统的硬件故障，在写入数据时，先写入预写日志，每台数据存储系统维护一个预写日志来记录发生的变化，只有预写日志新记录成功写入后，写操作才会完成。如果数据存储系统宕机，没有从内存池刷写到文件系统的数据可以通过回放预写日志来进行恢复。

关于数据读取：为保证数据快速访问，在读取数据时，数据存储系统会重新衔接文件池(持久化数据)和内存池(未持久化数据)，在读操作上使用了最近最少使用算法(LRU)缓存技术。这种缓存称为块缓存，块缓存保证了最频繁访问的数据是在内存中，避免重复地读文件。从数据存储系统中读取一行数据，首先会检查内存池，然后检查块缓存，最后访问分布式文件系统(磁盘)上对应的数据文件。

关于数据删除：数据删除的流程和数据写入类似，删除数据时并不是立即删除，只是给目标数据打上删除标记。被打上删除标记的数据不会再被读取。因为数据文件是不可变的，只有执行数据文件合并的时候才会真正的删除被标记的数据。数据文件合并分为两种：主要合并和次要合并。两者都会重整存储在数据文件的数据。其中，次要合并把多个小数据文件合并成一个大数据文件。主要合并将处理一个表分区的所有数据文件，主要合并完成后，一个表分区内的各个列组对应的数据文件被合并成一个。在主要合并过程中，会真正的删除被标记的数据。

关于数据读写示例：以用户注册信息表为例，数据增删改查的流程如下所述。

用户表的逻辑表结构如表2所示，以用户名为主键，用户的各项信息分为两个列组，其中基本信息中的列不允许为空，社交账号中的列可以自由添加。

表2-用户注册信息表

设定用户注册信息表的在整体架构中的分区情况如图12所示，表被切分为3个分区：R1、R2、R3，其中分区R1和分区R2托管在数据存储系统A中，分区R3托管在数据存储系统B中。元数据表托管在数据存储系统B中，元数据表中存储了用户注册信息表的分区情况。元数据表的位置(所属服务器)存储在一致性协调系统中。

对应的元数据表的主要内容如表3所示，由表3的内容可知：用户"U009"的信息是存储在A服务器上的R2表分区中，根据主键区间确定。

表3-元数据表中的数据

分区名称	主键区间	所属表	所属服务器
				R1	[null,U005)	用户注册信息表	A
R2	[U005,U010)	用户注册信息表	A
				R3	[U010,null)	用户注册信息表	B

关于数据读写示例中插入数据、更新数据、删除数据、查询数据等分别加以如下说明。

关于插入数据(INSERT)：假设要向用户注册信息表插入数据(用户名：U003，密码：000，昵称：老王，手机号：18800000000)，当客户端向数据库集群发起写入请求时，内部的详细流程如下：

1)客户端访问一致性协调系统，获取元数据表所在的位置数据存储系统[B]；

2)客户端访问数据存储系统[B]上的元数据表，获取用户注册信息表的分区情况；

3)根据用户注册信息表的分区情况，计算得出待写入的数据应属于数据存储系统[A]的分区[R1]；

4)客户端向数据存储系统[A]的分区[R1]写入数据；

5)数据存储系统[A]向客户端反馈数据写入的结果(成功或失败)，数据插入完成。

元数据表中存储了用户注册信息表的分区情况，关键信息是各个分区的主键区间，以及分区所属的服务器。在步骤3中，根据需要插入的数据的用户名，即可计算得出数据应写入到哪个数据存储系统的哪个表分区。另外，并非每次插入数据都需要经过步骤1和2，客户端会缓存步骤1和2的返回结果，后续可根据缓存中的内容直接进行步骤3。当用户注册信息表的分区情况发生改变时(如重新负载均衡)，主控系统会推送消息到一致性协调系统中，客户端会得到通知并更新缓存。

关于更新数据(UPDATE)：更新数据的内部流程与插入数据基本一致，不同之处在于更新数据需要先对数据进行匹配(步骤4中完成)，相当于有一次查询的过程。具体来说，就是根据更新条件进行查询操作，再根据查询结果中每行的主键组织新的写入数据。

关于删除数据(DELETE)：数据删除的内部流程和更新数据类似，也需要先对数据进行匹配，而新的写入数据的值是一个删除标记。因此删除数据时并不是立即删除，只是给目标数据打上删除标记(逻辑删除)。被打上删除标记的数据不会再被读取。因为数据文件是不可变的，只有执行数据文件合并的时候才会真正的删除被标记的数据(将底层存储的多个数据文件合并为一个数据文件，并对逻辑删除的数据做物理删除，合并的目的是提高查询性能)。

关于查询数据(SELECT)：假设需要查询用户名为"U009"的用户注册信息，查询数据的内部流程如下：

1)客户端访问一致性协调系统，获取元数据表所在的位置数据存储系统[B]；

2)客户端访问数据存储系统[B]上的元数据表，获取用户注册信息表的分区情况；

3)根据查询条件以及用户注册信息表的分区情况，向目标数据存储系统发送查询请求，查询结果可能需要跨多个分区(及服务器)；

4)数据存储系统接收到查询请求后，根据查询条件创建扫描器，对本服务器上的用户注册信息表的分区进行扫描，返回查询结果。

5)客户端接收到查询结果(游标)，遍历游标得到结果中的数据。

数据存储系统在接收到查询请求时，是通过扫描器来查找目标数据的。扫描器具有如图13所示的分层结构，不同的扫描器对应于表的不同存储层次(逻辑上的或物理上的)。图13中扫描器层次结构包括表分区扫描器，列池扫描器，文件池扫描器/内存池扫描器，以及文件扫描器。表分区扫描器对应表分区，列池扫描器对应列池，文件池扫描器对应文件池，内存池扫描器对应内存池，文件扫描器对应分布式文件系统中的数据文件。

本发明还可以实施为一种用于实现上述新型数据库或上述方法而形成的计算机软件源程序和/或目标程序。本发明还可以实施为一种计算机存储介质，其上记录包括实现上述新型数据库或上述方法而形成的计算机软件源程序和/或目标程序。

在此指明，以上叙述有助于本领域技术人员理解本发明创造，但并非限制本发明创造的保护范围。任何没有脱离本发明创造实质内容的对以上叙述的等同替换、修饰改进和/或删繁从简而进行的实施，均落入本发明创造的保护范围。

Claims (6)

1.一种数据库系统，其特征在于，包括构建在分布式文件系统之上的数据库整体架构，所述数据库整体架构包括相互连接的一致性协调系统、主控系统、数据存储系统和客户端模块，所述客户端模块供应用程序操作数据库使用，所述数据库整体架构通过文件系统模块与所述分布式文件系统连接，与所述主控系统和所述数据存储系统分别通过一致性协调系统交互模块连接所述一致性协调系统，所述一致性协调系统通过客户端访问接口与客户端模块连接，所述数据存储系统通过请求处理模块分别与所述主控系统和所述客户端连接，所述主控系统通过外部接口模块与所述客户端模块连接；

所述应用程序采用SQL语句通过所述客户端模块进行数据库操作，所述SQL语句中设置有包括列组名称描述项或列组名称句子成分以适配列式数据库中列式存储模型的列组设置；所述列式存储模型为包括所述列组的多级结构，所述SQL语句能够适配列式数据库中列式存储模型的多级列组结构；所述SQL语句具有以下功能设置：支持动态列作为静态字段和/或作为值的转换方法以适配列式存储模型中的列既能够作为字段也能够作为值的使用方式，支持动态列查询；

所述数据库整体架构为分布式集群模式；所述一致性协调系统、主控系统、数据存储系统均为分布式集群模式；所述数据存储系统的分布式集群采用多活模式，所述主控系统的分布式集群采用一主多备模式；所述数据存储系统的数据存储采用列式存储模型，所述数据存储系统针对数据查询采用匹配不同存储层次的分层扫描器查找目标数据；

在所述主控系统和所述数据存储系统中，数据库的库、表、列组均以虚拟文件系统的目录结构进行组织，所述目录结构为一个数据库对应一个数据库目录，数据库目录下是表目录，表目录下是列组目录，列组目录下是若干数据文件；所述数据文件中用于存储列式数据的数据结构为若干个数据块+文件元信息块+索引块+尾块，每一个数据块包括头信息+若干个KV键值对，每一个KV包括键部分的总长度KL+值部分的总长度VL+主键长度RL+主键值R+列组长度GL+列组名称G+列名称C+时间戳TS+键类型KT+列值Value，从RL至KT为键部分，Value为列值部分；所述尾块中设置有指针，所述索引块记录数据块的偏移量，所述头信息包括KV键值对的数量。

2.根据权利要求1所述的数据库系统，其特征在于，所述一致性协调系统的分布式集群采用Paxos算法以保证被操作数据状态的一致性，所述分布式集群包括一个领导者节点，分别与所述领导者节点连接的若干个观察者节点，以及分别与所述领导者节点连接的若干个跟随者节点，所述领导者节点、观察者节点和跟随者节点组成集群共同对外提供服务，对于多进程访问共享资源进行协调和保证数据状态的一致性；或者，所述主控系统包括指令执行模块，策略模块，所述一致性协调系统交互模块，所述文件系统模块，以及所述外部接口模块，所述指令执行模块分别互连于所述策略模块、所述一致性协调系统交互模块、所述文件系统模块和所述外部接口模块，所述外部接口模块与外部访问请求进行交互，所述文件系统模块与分布式文件系统交互，所述一致性协调系统交互模块与一致性协调系统进行交互；或者，所述数据存储系统包括请求处理模块，一致性协调系统交互模块，预写日志模块，数据缓存模块，分区管理模块，以及文件系统模块，所述请求处理模块互连着预写日志模块、数据缓存模块、分区管理模块、主控系统和客户端模块，所述一致性协调系统交互模块分别互连着分区管理模块和一致性协调系统，所述文件系统模块分别互连着预写日志模块、分区管理模块和分布式文件系统，所述分区管理模块包括若干个表分区；或者，所述客户端模块用于用户或应用程序与数据库集群通讯、发起请求和接收结果，所述客户端模块包括连接池和API应用程序接口，应用程序通过所述API实现数据库操作，所述连接池分别连接所述API、所述一致性协调系统、所述主控系统和所述数据存储系统。

3.根据权利要求2所述的数据库系统，其特征在于，所述一致性协调系统交互模块中的集群状态管理工具用于执行主控系统集群的一主多备模式，当主控系统软件被部署到多个节点上并启动后，所述集群状态管理工具通过所述一致性协调系统的分布式锁机制选定一个节点为活动节点，保证只有这一个节点上的主控系统对外提供服务，其他节点均为备用的就位节点，当主控系统活动节点被所述一致性协调系统的故障发现机制确认发生故障，所述集群状态管理工具重新选定活动节点并通过所述指令执行模块完成故障迁移；或者，所述一致性协调系统交互模块中的数据存储系统管理工具用于执行数据存储系统集群的多活模式，所述多活模式中的多个活动节点的信息被存储在所述一致性协调系统中，当其中某一个活动节点被所述一致性协调系统的故障发现机制确认发生故障，所述数据存储系统管理工具调用所述指令执行模块进行故障处理，所述故障处理包括将发生故障的数据存储系统中的数据托管到其他正常的数据存储系统中；或者，所述一致性协调系统交互模块中的负载均衡管理工具通过调用所述指令执行模块管理被触发的对数据存储系统集群所进行的负载均衡工作，所述负载均衡工作包括对表分区进行重新分配，所述重新分配是按照负载均衡策略将表分区托管到不同的数据存储系统中，所述负载均衡工作的触发来自所述策略模块的主动触发或来自所述外部接口模块的外部触发，在所述负载均衡工作的过程中，所述负载均衡管理工具使用从所述一致性协调系统获取的分布式锁防止在负载均衡过程中再次发生负载均衡，同时通过所述一致性协调系统的分布式锁机制对参与负载均衡的数据存储系统及其数据加锁以防止其他工作影响负载均衡，所述其他工作包括新数据写入或数据库扩容；或者，所述一致性协调系统交互模块中的表状态管理工具用于对数据表进行以下状态的择一设置：创建状态，修改状态，正常状态，切分状态，上线状态，下线状态，各种状态代表了所述主控系统对数据表的各种处理过程。

4.根据权利要求1所述的数据库系统，其特征在于，所述请求处理模块用于接收所述客户端模块的数据读写请求，以及向所述客户端模块返回请求的执行结果，所述请求处理模块通过RPC远程方法调用方式与所述客户端模块进行交互，所述请求处理模块设置有用于读写数据的如下基础操作接口：插入数据Insert操作接口，更新数据Update操作接口，删除数据Delete操作接口，以及查询数据Select操作接口。

5.根据权利要求1所述的数据库系统，其特征在于，所述文件系统模块用于完成对所述分布式文件系统发起的数据读写工作，所述文件系统模块对于不同类型分布式文件系统的差异具有屏蔽功能。

6.一种对数据库系统进行数据管理的方法，其特征在于，所述数据库系统是权利要求1-5之一所述的数据库系统，所述数据库系统在数据的组织形式上分为两级：表空间和表，所述表空间在数据库集群中能够被创建若干个，所述表能够在每一个表空间中被创建若干个，所述表能够被切分成若干个表分区；所述表分区是对表的水平切分，所述水平切分是按照主键区间进行的切分，每个表分区均记录了主键的起止范围；所述表分区能够在数据写入过程中根据策略进行切分以形成两个子分区，所述两个子分区分别为上部子分区和下部子分区；将一个表分区切分为两个子分区的过程包括以下步骤：1)表分区达到切分的阈值，数据存储系统准备切分，通知一致性协调系统准备对表分区进行切分；2)主控系统接收到一致性协调系统的通知，表分区将进行切分；3)数据存储系统在分布式文件系统对应的目录中创建切分子目录；4)数据存储系统关闭将要被切分的表分区，强制刷写表分区的缓存以将内存数据持久化到文件，并将表分区下线，若此时有客户端请求到此表分区上，那么数据存储系统会返回表分区不可用的信息，客户端得到此信息后会自动重试；5)数据存储系统在切分目录下创建两个子目录，以一对一的方式对应切分后的两个子分区，然后数据存储系统切分表分区，所述切分表分区只是在两个子目录下创建相应的软引用文件；6)数据存储系统创建切分后对应实际目录，所述实际目录是与被切分的表分区同级的目录，并将上一步创建的软引用文件拷贝到实际目录中；7)数据存储系统更新主控系统上的元数据表，更新将被切分的表分区的状态为下线，并新增两条记录，分别对应切分后的两个子分区，在元数据表中，两个子分区的状态为不可用，如果更新元数据表成功，表示表分区已经被成功切分，如果更新元数据表失败，那么主控节点以及其他数据服务器将重新打开被切分的表分区，并清理切分产生的脏状态和脏数据，并由主控系统负责整体回退工作；8)对于表分区已经被成功切分的情况，数据存储系统并行的打开两个子分区，打开子分区包括实际上线和状态未上线；9)数据存储系统更新元数据表中两个子分区的状态，并添加相应的元信息，所述元信息包括子分区所属的数据存储系统，此时两个新上线的子分区将代替原分区，对客户端提供服务，所述新上线包括实际上线和状态上线；10)数据存储系统更新一致性协调系统中的状态，从准备切分状态到已经切分状态，主控系统监听到状态改变，根据需要或策略决定是否重新负载均衡子分区到其他数据存储系统中；11)切分完成后，元数据表中、分布式文件系统中仍然会存在原分区相应的信息，这些信息将会在子分区的合并流程中被删除，垃圾清理任务也会定期检查子分区是否仍引用原分区，如果不引用，则原分区会被删除。