作者介绍

王涛，巨杉数据库联合创始人之一，目前担任SequoiaDB的CTO与总架构师，负责SequoiaDB产品的架构设计与开发。曾是北美IBM DB2 Lab核心研发成员，有着超过十年数据库核心架构设计、数据库引擎研发和企业级数据库应用的经验。

 

如今，随着业务“互联网化”和“智能化”的发展以及架构 “微服务”和“云化”的发展，应用系统对数据的存储管理提出了新的标准和要求，数据的多样性成为了数据库平台面临的一大挑战，数据库领域也催生了一种新的主流方向。

 

数据库多模Multi-Model是指同一个数据库支持多个存储引擎，可以同时满足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。

 

一、数据库云化需求催生Multi-Model

 

企业使用云数据库对接的应用越来越多，需求多种多样，传统的做法是在dbPaaS里面提供十几个不同的数据库产品分别应对各种需求，这样的方法在系统增加后，整体维护性和数据一致性管理成本很高，会影响整个系统的使用。

 

云数据库的“多模”示意图

 

为了实现业务数据的统一管理和数据融合，新型数据库需要具备多模式（Multi-Model）数据管理和存储的能力。通常来说，结构化数据特指表单类型的数据存储结构，典型应用包括银行核心交易等传统业务； 而半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中得到大规模使用；非结构化数据则对应着海量的图片、视频、和文档处理等业务，在金融科技的发展下增长迅速。

 

多模式数据管理能力，使得数据库能够进行跨部门、跨业务的数据统一存储与管理，实现多业务数据融合，支撑多样化的应用服务。在架构上，多模Multi-Model也是针对云数据库需求的，则使得数据库使用一套数据管理体系可以支撑多种数据类型，因此支持多种业务模式，大大降低使用和运维的成本。

 

二、Multi-Model存储引擎架构

 

数据库是现有许多业务系统的核心。随着数据生成与采集技术的飞速发展，数据量不断爆炸式增长，数据的结构也越来越灵活多样。传统基于关系型理论构建起来的数据库管理系统，面对大数据、人工智能的真正到来，在成本、性能、扩展性、容错能力等方面遭遇到了不小的挑战。

 

面对多类型的的结构化数据、半结构化数据、非结构化数据，现代应用程序对不同的数据提出了不同的存储要求，数据库因此也需要适应这种多类型数据管理的需求。

 

比较流行的两种解决思路分别是：混合持久化（Polyglot Persistence）与多模数据库（Multi-Model Database）。

 

1、混合持久化 Polyglot Persistence

 

 

混合持久化的思路是指，用户根据工作的不同需求分别选择使用合适的数据库，这样在一个完整的系统中，可能同时运行着多种不同的数据库。

 

图1 Polyglot Persistence示意图

 

混合持久化一个显著的优点就是单一流程的性能提升，但缺点也同样的显而易见：以增加复杂性和学习成本为代价，在部署、使用及维护上带来了挑战。

 

2、多模Multi-Model

 

 

Multi-Model多模数据库则是另一种解决思路，在同一个数据库内有多个数据引擎，将各种类型的数据进行集中存储和使用。多个不同类型的应用，同时接入一个数据库，并在同一个分布式数据库内进行管理，大大简化应用程序的开发及后期维护成本。

 

图2：多模数据库引擎架构示意图

 

图为多模Multi-Model数据库的示意图，我们可以看到在同一个存储引擎里面同时具备关系型数据、JSON半结构化数据、对象数据以及全文检索引擎等等多个数据引擎，统一提供给应。这一架构大大降低开发和运维的难度，应用统一连接到数据库，数据库内部进行数据的划分、隔离和管理，对应用来说只需要连接到数据库即可，无需为了每个应用搭建对应的数据后台。

 

三、存储数据结构

 

针对多模数据库的需求，分布式数据库的存储数据结构也会有新的创新。下面以SequoiaDB为例，剖析其在Multi-Model方面进行的数据存储结构和访问的设计和实现，可作为Multimodel数据库的一个参考。

 

1、结构化、半结构化数据存储

 

 

结构化数据的特点是结构固定，每一行的属性是相同的，如传统关系型数据库表中的数据。半结构化数据是一种自描述结构，它包含相关标记用来分隔语义元素及对记录和字段进行分层，如XML，JSON等。

 

存储结构

 

如何在数据引擎中同时管理结构化和半结构化数据呢？SequoiaDB使用JSON数据模型，在数据库内部使用BSON格式来将结构化及非结构化数据以文档的形式存储在集合中。

 

BSON（Binary JSON）是对JSON的一种二进制编码数据格式，和JSON一样，BSON支持嵌入式的文档和数组。BSON由若干个键值对存储为单个实体，这种实体称为文档。BSON包含了JSON中的数据类型，并扩展了一些JSON中没有的数据类型，如Date，BinData等。BSON结构的一个简单示例如下图所示：

 

图3：BSON结构示例

 

BSON具有以下几个特性：轻量级（Lightweight）、可遍历性（Traversable）、高效性（Efficient）。由于BSON结构包含足够的自描述信息，因此它是一种schema-less的存储形式。

 

SequoiaDB将BSON作为记录的存储结构，由于其良好的灵活性，不需要事先对集合的结构进行定义，每一个记录中包含的字段信息可以相同，也可以不同，并可随时进行修改，这样对结构及半结构化的数据都能以一致的方式统一存储和访问。

 

SequoiaDB中的数据管理模型如图4所示：

 

图4：SequoiaDB数据管理模型架构图

 

数据最终都是要在磁盘文件中进行持久存储，与之相关的三个概念如下：

 

• 文件（File）：磁盘上的物理文件，用于持久存储集合数据、索引及LOB数据。

• 页（Page）：页是数据库文件中用于组织数据的一种基本结构，SequoiaDB中使用页来对文件中的空间进行管理与分配。

• 数据块（Extent）：由若干个页组成，用于存放记录。

 

在该模型中，与结构/半结构化数据存储相关的三个核心逻辑概念包括：

 

• 集合空间（Collection Space）：用于存储集合的对象，物理上对应于一组磁盘上的文件。

• 集合（Collection）：存放文档的逻辑对象。

• 文档（Document）：存储在集合中的记录，以BSON结构存储。

 

一个集合会包含若干个extent，所有这些extent使用链表串联起来。当向集合中插入文档时，需要从extent中分配空间。如果当前extent没有足够空间，则分配新的extent（必要时对文件进行扩展），挂到该集合的extent链表上，然后向其中插入文档。每个extent内的记录也通过链表的形式组织起来，这样在进行表扫描时，可顺序读取块内的所有记录。

 

数据访问

 

1）SQL

 

当前大量基于数据库的应用使用SQL来进行数据库访问，因此对的SQL支持是数据库必不可少的能力。SequoiaDB支持标准SQL接口，完全兼容PostgreSQL及MySQL语法和协议，现有的应用可平滑地将存储系统切换为SequoiaDB，以获得分布式存储系统所带来的扩展性、性能及可靠性等立面的巨大提升。

 

2）API

 

SequoiaDB在结构化数据提供了丰富的API接口用于管理整个集群及操作数据，提供了各种主流编译语言的驱动。

 

数据压缩

 

对于JSON/BSON数据结构，因为其嵌套结构，在拥有灵活的存储结构同时，也会造成数据的膨胀。JSON数据存储的膨胀问题，也是早期如MongoDB等JSON数据库性能瓶颈的一个重要原因。

 

SequoiaDB在使用JSON/BSON作为数据存储结构时，为了避免过度的膨胀问题，在数据引擎中加入了数据压缩的机制。目前SequoiaDB引擎提供了两类压缩方式：行压缩与表压缩。行压缩使用Snappy算法，是一种不需要字典的快速压缩机制。表压缩则使用LZW算法，是一种基于字典的压缩机制。

 

数据压缩机制，一方面从存储上节省空间和成本，另一方面提升单位I/O的效率。在IO吞吐量非常高的查询场景下，基于数据字典的深度压缩机制能够大幅降低IO开销，有效提高查询效率。

 

2、非结构化数据存储

 

 

存储结构

 

非结构化数据即没有固定结构的数据，如文档、图片、音频/视频等，这种类型的数据在现在的很多业务中所占的比重越来越大。在SequoiaDB中，使用大对象（LOB，Large Object）来对这种类型的数据进行管理。

 

大对象依附于普通集合存在，当用户上传一个大对象时，系统为它分配一个唯一的OID值，后续对该大对象的操作可通过该值来进行指定。

 

大对象在存储时会进行分片，并使用hash算法将分片分散存储在相应的分区组中，其哈希空间与所属集合的哈希空间一致。分片大小为LOB页大小，在创建集合空间时指定，默认为512KB。

 

为了对LOB数据进行有效的存储和管理，SequoiaDB内部将LOB数据抽象为元数据和数据本身，并使用两种文件来存储这些数据：LOBM文件用于存储LOB分片的元数据，LOBD文件用于存储真正的LOB数据分片。它们的逻辑结构如下图所示：

 

图5：LOB文件逻辑结构

 

其中LOBM文件主要包括：

 

• 文件头：包含该文件的一些元数据信息。

• 空间管理段（SME）：用来标记页的使用情况。

• 桶管理段（BME）：hash值相同的分片所占用的页以双向链表的形式挂在一个桶上。

• 页：与LOBD中的页一一对应，记录该页所属的集合信息，OID及sequence值等。

 

LOBD文件主要包括：

 

• 文件头：包含该文件的一些元数据信息。

• 真正的数据页：用于存储LOB分片。LOB还有一些自身的元数据，保存在sequence为0的分片中，包括该LOB数据的大小、创建时间、版本号等。

 

数据访问

 

1）写入LOB

 

当需要写入LOB数据时，LOB数据会在协调节点上进行分片，每一个分片分配了一个sequence值，它表示这些分片在原始LOB数据中的顺序。因此，LOB的OID与分片的sequence值唯一地标识了这个分片。

 

在存储一个LOB分片时，使用其OID+sequence计算hash值。先使用集合的分区hash函数来计算出该分片要存储到哪个分区组上，然后使用LOB分片的hash函数来计算出其挂接到哪个桶上，之后在LOBD及LOBM文件中分配数据页，完成数据写入，LOBM中的页挂到对应的桶上。

 

2）读取LOB

 

在获取LOB数据时，需要指定其OID值。引擎根据OID值获取sequence值为0的分片，从中读出LOB的元数据信息，然后进行分片计算，确定所有分片信息，向所有包含分片的分区组发送请求。

 

当协调节点接收到各级返回的分片数据后，按sequence的顺序对LOB数据进行合并还原，以获取完整的LOB数据。

 

3）标准Posix文件系统接口

 

除了LOB的API之外，目前提供SequoiaFS文件系统，它是基于FUSE在Linux系统下实现的一套文件系统，支持通用的文件操作API。SequoiaFS利用SequoiaDB的集合存储文件和目录的属性信息，LOB对象存储文件的数据内容，从而实现了类似NFS分布式网络文件系统。用户可以将远程SequoiaDB的某个集合通过映射的方式挂载到本地节点，从而在挂载节点的目标目录下可以通过通用文件系统API对文件和目录进行操作。

 

四、总结

 

根据Gartner的报告，Multi-Model多模是数据库领域近年兴起的一个主要的技术方向之一，其代表了在云化架构下，多类型数据管理的一种新理念，也是简化运维、节省开发成本的一个新选择，目前已在许多行业得到了应用。

 

我们看到MySQL、PostgreSQL等数据库也开始支持JSON等多类型格式，在朝着Multi-Model的方向发展。未来相信各产品也会持续保持创新，出现更多Multi-Model的数据库。