多模型数据库：处理数据的多样性的新旅程

多模型数据类型	历史	策略	对比
多语言持久性	多数据库和联邦数据库	利用不同数据库存储不同数据模型，并通过中介将它们集成来回答查询	多数据库，中介集成
单一数据库·多模型数据库	ORDBMS的概念	建立一个单一的数据库管理不同的数据模型	单一数据库，使用面向对象的编程模型

（二）实验目的：

本研究通过全面回顾多模型数据库管理系统的发展历程、关键特性及比较分析，梳理了多模型数据库领域的脉络、分类与演进，并通过实例阐述了不同产品的特性和适用范围，同时指出了该领域现存的开放问题与挑战，为未来多模型处理技术创新及实际应用的选择与评价提供了理论依据。

二、数据模型初步工作

首先，千里之行，始于足下，我们需要了解四个常见的应用于多模型数据库的数据模型，常见于关系模型、半结构化模型、键值对模型和图模型。

关系模型，这一模型根植于数学关系理论，并通过SQL语言进行操作，它在金融、银行等系统的数据库中有着广泛的应用。

另一方面，半结构化模型，例如XML和JSON，这些模型以其灵活的方式表示带有结构标签的数据，因此，在web服务等场景中得到了广泛的使用。

键值模型，作为NoSQL数据库中最简单的数据模型，它以键值对的形式存储数据，虽然查询能力有限，但非常适合高效处理大量数据。

至于图形模型，它则是基于图论概念构建的，适用于大数据环境下的图形数据库。图形模型分为事务性和非事务性两种类型，它们分别满足了不同规模和用途的图形数据处理需求。

数据模型对比表

模型	描述	应用场景
关系模型	根植于数学关系理论，通过SQL语言进行操作，广泛应用于金融、银行等系统的数据库中。	金融、银行等系统的数据库
半结构化模型	例如XML和JSON，以灵活的方式表示带有结构标签的数据，广泛应用于web服务等场景。	web服务等场景
键值模型	NoSQL数据库中最简单的数据模型，以键值对的形式存储数据，适合高效处理大量数据。	高效处理大量数据的场景
图形模型	基于图论概念构建，适用于大数据环境下的图形数据库，分为事务性和非事务性两种类型，分别满足不同规模和用途的图形数据处理需求。	大数据环境下的图形数据库

三、分类学与比较研究

自1960年数据库的需求被发掘并逐渐走入公众的视野以来，逐渐经历了关系模型->加入非关系模型->加入非结构化数据的阶段化发展。这一现象指明了越来越多的数据类型被存储的趋势——例如2000年后，关系型数据库依照SOL/XML标准或其变体向XML扩展，因此它们被转换为所谓的支持XML的数据库；同样的，支持xml的数据库也逐渐发展兼容了JSON格式的数据。

虽然目前存在NOSQL等许多数据库向多模型数据库的跨越风向，但是这能称得上是合格的多模型数据库吗？

由于存在不同完成度的多模型数据库，我们将细细分类来讨论这些数据库。将从以下方面进行考察：

跨不同模型进行查询

索引模型的内部结构

跨模型优化查询

对多模型数据的支持级别差异

（一）数据拓展方法

对于数据类型逐渐糅合的数据库，其特点是采用了将原始模型扩展到其他模型或组合多个模型的策略，对于数据拓展的具体实现，我们又区分了四种方法：

数据拓展方法	数据库代表
采用一种适用于新数据模型的全新存储策略	支持XML的数据库，使用本机XML方法
为了建立新的数据模型而扩展了原来的存储策略	ArangoDB，使用特殊的边集合来承载关于图中的边的信息
为原始存储策略创建一个新的接口	Sinew，它在传统的关系存储策略之上构建了一个新的层。
原有的存储策略没有变化	适用于所有的数据库系统，所有文档数据库也可以被视为键/值和列存储，只是比较低效

笔者思索：第2.3种方法实现较为高效和实际，而第四种方法往往过于简单，缺少对于数据的处理，可能导致数据检索和处理的性能代价。

（二）数据库支持的数据格式

下面这张表格展示的是多模型dbms中支持的数据模型概述，和它们受欢迎的程度。

这张表格说明了当前流行的数据库确实很大一部分实现了对于多种类型数据的存储，常见的有JSON数据和xml数据。

可以发现一个规律，那就是最受欢迎的数据库都拥有Nested data/UDT/object的数据类型。同时，越受欢迎的数据库往往兼容的数据类型都不会低于三种。

（三）数据库支持数据格式/存储策略/查询语言/指标

接下来，让我们把目光看向对于不同数据库更加详细的研究表格。我们重点关注以下部分：

(1)支持的数据格式， (2)用于不同数据的存储策略， (3)它支持什么的查询语言，(4)为优化查询评估的目的所支持的索引类型，(5)该数据库是否为分布式数据库， (6)数据库是否需要模式定义来存储数据，(7)不同的数据是否可以使用单一的通用语言一起查询， (8)是否也存在一个针对云的版本，(9)是否引入了一种特殊的事务管理方法来处理不同的数据。

在这个表格中，让我们来看看各列名的涵义：

特征一为支持的语言——包括了关系型，XML，键值对等等；
特征二为存储的策略——关系型，文本，xml等等；
特征三为查询的策略——包括声明性方法和命令式方法。选项范围从简单的API（DynamoDB）、全文搜索（Riak），到流行的标准查询语言的扩展，如SQL（例如 PostgreSQL、卡桑德拉或OrientDB）或XQuery（MarkLogic）。
特征四为指标（索引）。

通过表格给予的信息，我们能得到一个概览，这展示了不同数据库或数据存储系统在语言支持、存储方式、查询方法以及性能指标方面的差异和特性。

（四）数据库·数据分发特性

我们可以看到，在今天大数据的时代背景下，大多数系统都支持数据分发，并且正在成为一个趋势。与此同时，数据库的云计算特性，数据库供应商正在加强对于云版本的支持，目前，DAAS的使用能为复杂的大数据应用程序创建解决方案，这是因为它是一种将数据封装成可重复使用的服务并提供标准化的数据接口和数据访问方式的服务模式。它使得用户可以方便地获取和使用数据，而不必关心数据的存储和数据处理技术。

同时，要想成为一个比较合格的多模型数据库，支持跨多个模型查询的能力是必须的。但是，对于不同系统而言，有时跨多个查询获取到的信息可能是无关的或者混乱未知的，目前并不存在一种通用良好的处理特殊类型的事务管理的明确信息。

从上图中提供的信息来看，确实可以观察到大部分数据库都支持分布式、灵活的模式，跨模型的查询以及云版本的实现。这反映了现代数据库技术发展的几个重要趋势：

分布式支持：随着数据量的爆炸式增长，分布式数据库技术变得尤为重要。通过将数据分散到多个节点上，分布式数据库能够处理大规模的数据集，同时提供高可用性和容错能力。
灵活性：现代数据库系统越来越注重灵活性，允许用户根据需求定制数据库的结构和行为。

跨模型查询：跨模型查询能力意味着用户可以在一个统一的平台上查询多种类型的数据模型，而无需在不同的系统之间切换，提高了工作效率。
云版本实现：随着云计算的普及，越来越多的数据库系统提供了云版本。云数据库不仅提供了弹性伸缩的能力，还降低了运维成本，使得用户可以更加便捷地部署和管理数据库。

此外，部分数据库还实现了多模型的交易。多模型交易意味着这些数据库能够同时处理多种数据模型的事务，保证数据的一致性和完整性。这对于需要处理复杂业务逻辑和多种数据类型的应用场景来说是非常有用的。

（五）多模型数据库的·SQL拓展和SQL语言

1．补充概念：什么是SQL?

SQL，是结构化查询语言，是用于数据库管理系统的标准编程语言。SQL语言的主要功能包括数据查询、数据操纵、数据定义以及数据控制，涵盖了关系型数据库中的增删改查等基本操作。

下表揭示的是常见多模型数据库的SQL拓展和SQL语言。

从上面的图表中我们可以看出，关系型/文件/键值对/列/图/对象等类型的多模型数据库均有SQL的拓展——例如IBM DB2的SQL语言策略为SQL/XML+嵌入SQL查询到XQuery;对于文本本身结构就嵌套的JSON数据而言，使用各种操作符能够访问包括数组项的更深层次的数据级别。

（六）多模型数据库的·查询优化策略

下面的图表讲述的是多模型数据库中的查询优化策略。

我们可以看出，最常见的查询方式如下所示：

一种B-树/B+-tree索引，特别是在关系数据库中，平衡树的设计使得它们能够高效地处理大量的数据，并通过平衡树的结构来减少查询时的磁盘I/O操作。
其次支持XML数据的系统还利用一种本地XML索引，最常见的是一种基于顺序路径的方法，它支持高效的查询和数据更新。
再者就是采用一种哈希技术，这是一种几乎可以普遍使用的技术。

然而，一般来说，似乎没有公认的最优或次优方法适合于多模型查询优化（这些不同的方法通常与系统扩展到其他数据模型的方式高度相关。）

从前面关于多模型数据库的各个方面的讨论中，我们总结了这些观察结果如下：

——多模型数据库支持的数据模型包括关系模型、列模型、键/值模型、文档模型、XML模型、图形模型和对象模型。

——多模型数据库采用基于SQL、XML和图形语言的扩展的跨模型语言。

——多模型数据库中的数据索引包括反向索引、b树、物化视图、哈希和位图索引。其中大多数都是基于关系数据库或XML数据库的扩展。

——现有的多模型数据库具有数据共享、灵活的模式和云版本的特点。但它们仍然缺乏对多模型事务的支持。

四、查看多数据库的代表

在这一节里，我们将从跨不同模型进行查询、索引模型的内部结构、跨模型优化查询、对多模型数据的支持级别差异等几个方面来分析不同的多模型数据库。

关系存储

1．什么是XML格式？

XML 被设计用来传输和存储数据，指可扩展标记语言，是从标准通用标记语言中简化修改出来的。它主要用到的有可扩展标记语言、可扩展样式语言（XSL）、XBRL和XPath等。

2．PostgreSQL

PostgreSQL，一种开源关系型数据库，起初是为建立经典的关系型DBMS而设计，但随着时间的推移，最新版本引入了许多NoSQL特性，如实例化视图、数据重复性支持等，以加速查询和实现同步/异步主从复制。它还可以方便地在云环境中设置、操作和扩展。自2006年支持XML格式以来，它还支持HStore数据类型的键/值对存储，自2013年以来，支持JSON和jsonb格式的存储。JSONb使用二进制格式存储数据，不需要重新解析，并支持索引建立。它还提供了丰富的SQL扩展和函数来查询和处理存储在JSON和jsonb类型中的数据。此外，通过广义反向索引（GIN），存储在jsonb中的数据可以进行索引，GIN支持多种操作符来进行路径/值包含和顶级键存在等操作。

3．Sql server

微软SQL Server是一个关系型数据库和数据管理与分析平台，。它通过使用SQLXML和JSON格式的支持，在数据库领域与时俱进。SQL Server支持XML数据存储和查询，可以将JSON数据存储为文本或解析为关系表。通过Polybase技术，SQL Server 2016变成了一个多模型多数据库DBMS，能够同时访问非关系和关系数据。

在查询方面，SQL Server提供了用于XML和JSON数据的各种函数和语法。对于XML数据，可以使用XML类型的列建立索引，并使用ORDPATH模式进行索引优化。然而，对于JSON数据，SQL Server目前不支持特殊的索引技术，只能利用b树引或全文索引。

4．IBM DB2

IBM DB2是一款面向对象关系型数据库管理系统，衍生了云数据库。自2007年以来它开始支持XML，自2012年起也支持RDF图。XML数据可以存储在本地XML数据类型列中，以反映其分层结构的解析格式，也可以通过用户定义的分解成关系表进行存储。通过使用标准SQL/XML并增强了多个DB2特定构造，如嵌入SQL查询到XQuery表达式中，可以访问这些数据。

5.Oracle DB

在Oracle数据库中，XML数据可以存储在表中或使用XMLType数据类型，而JSON数据则可以存储在VARCHAR2、BLOB或CLOB中。对于XML数据，可以使用标准SQL/XML进行访问，而对于JSON数据，则可以使用SQL/JSON函数扩展SQL。

索引方面，XML数据可以自然地使用B树索引，而XMLIndex则用于本机XML存储的索引路径、父、值和关系。对于JSON数据，可以为SQL函数json_value创建基于函数的索引。

6.MySQL

MySQL支持数据共享和复制，它能够结合关系和键/值的数据访问优势。默认情况下，数对（键、值）存储在同一个表中，同时用户定义的键前缀可以确定应该存储该值的预定义表和列。大多数MySQL索引存储在b树中，r 树用于空间数据类型，内存表支持散列索引。

列存储

这一种多模型数据库由列存储表示，主要类型为NoSql。我讲例举三种经典的数据库进行分析。

什么是列存储？

第一种可以理解为将数据存储为列。

另一种理解就表示一种NoSql数据库，能够去支持不同列数量和类型的表，特点表示为底层存储策略是任意的。

2.CQL（Cassandra Query Language）

语言特点：

可以看作是SQL的一个子集（包括SELECT、FROM、WHERE、GROUP BY、ORDER BY和LIMIT等子句），但是在FROM和WHERE子句有限制。（在FROM子句中只能查询单个表，而在WHERE子句中有一些限制，比如只能针对主键或具有二级索引的列进行限制等）。排序仅支持根据决定数据排序和存储在磁盘上的列。SELECT JSON子句可用于将每一行返回为单个JSON编码映射；

存储与索引：

Cassandra类型与JSON之间的映射与存储情况相同。Cassandra中有几种类型的索引。主键始终使用倒排索引自动索引，实现方式是使用辅助表。可以根据需要为要搜索的列（包括集合）显式添加二级索引。相应的SASI使用内存映射的B+树实现，因此也允许范围查询。

3.Cassandra. Apache

总体：是专为云应用设计的数据库Enterprise 的基础。

查询语言：使用CQL,将数据存储在稀疏表中

支持的数据：列表、集合、映射、元组和用户定义任意数据类型

存储：存储在SSTables（有序字符串表，从键到值的有序不可变映射，其中键和值都是任意字节字符串）中，进一步分为块，块被索引以加速数据查找，并定期使用压缩进行合并。

4.CrateDB

总体：动态分布式SQL数据库

支持数据：嵌套的JSON文档、数组和blob

存储：每行是一个半结构化文档，每张表在集群的节点间分片，每个分片是一个Lucene索引。

语言：标准的ANSI SQL 92，可包含嵌套的JSON属性。

索引：添加了一个SQL层，使用Elasticsearch接口，Lucene索引

键值对存储

一般来说，键/值存储被认为是最简单的NoSQL多模型数据库，只支持一个简单但快速的API，用于存储和检索具有特定ID的项——但是往往能够提供更复杂的“值”部分的操作。

因此，由键值对存储简单的数据库向键值对存储复杂的多模型数据库的转变是性价比较高的，人们总会顺其自然的发展这种存储类型的多模型数据库。

接下来，将介绍所有论文中的键值对多模型数据库。

1.Riak

什么是CRDT？

无冲突复制数据类型，是一种设计用于分布式系统中的数据结构，能够支持高效地实现数据同步和复制功能。利用CRDT，可以保证在分布式系统的各个节点之间，数据的一致性和时间顺序的正确性。

特点：Riak Search和Riak Data types，具有查询功能的文档存储，支持所有分布式SOLR查询。

Riak Data types：集合、映射、计数器，基于无冲突复制数据类型。

Riak Search：配置一个Solr模式，以便Solr知道如何索引值字段。具体而言，字段被提取器提取内容，字段被命名为Solr索引，并与桶/桶类型相关联。

2.c-treeACE

总体：NoSql多模型数据库

语言：NoSQL和SQL

接口：关系的和非关系的

索引：顺序访问方法（ISAM）结构

3.Oracle NoSQL Database

总体：可拓展分布式“键/值”DBMS，和Oracle MySQL这种关系型 DBMS相反。

使用：SQL，提供表的定义。

支持数据：关系数据和JSON数据。

索引：辅助索引是分布式的、分散的本地双树实现的。

文档存储

首先，将文档存储放在键/值存储之后介绍的原因是因为，文档DBMS可以被认为是具有可以查询的复杂值部分的高级键/值存储。

因此，文档存储自然的包括了键/值存储或列存储的功能。

自然而然的，文档存储可以进化为DBMS。

接下来，我们将介绍集中经典的文档存储DBMS。

ArangoDB.

总体：本地DBMS，也可以云托管运行

支持存储类型：键/值、文档和图形数据

语言：AQL。

数据组织：

文档，以JSON格式表示，并在集合中分组。
每个文档包含一组属性。（每个属性具有原子/复合类型）
每个文档集合都有一个主键属性。

图形数据存储：

边缘集合包括两个特殊属性_frond和_to ，可以创建文档之间的关系，并连接。
可以使用各种类型的遍历图结构和最短路径搜索。

键/值存储：

每个文档集合都有一个主键属性，主键属性可以作为键/值存储。
单键查找和键/值对的插入和更新。

文档存储：

可以简单示例查询，也可以复杂的使用集合/函数。

索引类型：

自动创建的索引
用户定义的集合级别的索引
每个集合有主索引，边集合有from/to索引
存储所有属性的联合的散列索引，支持相等式查找，但不支持范围查询或者排序。
“跳过器”索引，已排序的索引结构，用于查找、范围查询和排序。
持久性/全文性/ geo类型......

Couchbase.

总体：支持云部署，文档DBMS。

语言：SQL。

支持存储模式：文档型、键/值。

数据组织：文档为基本单位，文档放在桶中。

存储方法：对于每个文件附加写入模型，以高效写入，并定期采用LRU算法清理数据。

索引：B+树索引、更有效更浅层的B+trie。

MongoDB.

总体：最流行的文档DBMS之一，支持云托管。

支持存储模式：文档型、键/值、图形数据。

数据组织：文档，具有灵活的模式（文档可以嵌入或者引用其他文档）。

语言：JSON语法，支持使用条件，不支持连接，可以用手动引用或者DBRefs引用来关联文档。

数据存储：BSON（JSON文档的二进制表示形式），BSON文档会自动创建唯一主索引。

索引：b树数据结构。

4.XML存储（特殊类型的文档数据库）MarkLogic

总体特点：

是一个支持分层半结构化数据的系统，支持云托管。

存储模式：

支持将JSON文档建模为XML文档，作为节点树，支持对象、数组、文本、数字、布尔值或空值等节点类型。

数据组织：

数据以节点树的形式组织，节点可以表示各种数据类型，节点名称可对应属性名称或支持未命名节点，提供了统一的管理和索引方法。

语言：

支持使用XPath查询遍历JSON文档，也可从JavaScript和XQuery代码中调用，还可以使用SQL进行查询，允许创建视图将分层数据平成表。

数据存储：

支持存储和索引文档片段，默认情况下，片段是整个文档，但也可将大型XML文档分解成文档片段，JSON文档是单片段的

索引：

维护一个通用索引用于搜索文本、结构及其组合，包括反向索引、XML元素和JSON属性及其值的索引，还有父子关系的索引和范围索引用于有效评估范围查询。

图存储：

首先，这一小节我们将只会介绍一个典型的数据库OrientDB，因为图存储对数据结构/数据访问/添加新数据的要求高、难度大。

所以，我们将会详细分析这难得的独苗。

OrientDB

总体：原型是对象DBMS，现在NoSql DBMS，支持云托管

支持数据类型：图形、键/值、文档和对象模型

数据组织：记录。

每个记录具有唯一的ID，并且可以对应于文档/BLOB/订单/边。
记录可以是是模式完整的、无模式的或模式混合的。
类可以继承，类定义属性后可以约束或索引，类可以物理链接或者嵌入记录。

语言：

Gremlin。

SQL，注意，不支持经典连接，由链接表示类关系。

索引：

其他存储

在这一小节，我们将简要地重点介绍其他类型的多模型系统，包括小众DBMS，正在发展的和已经过时的DBMS。

对象存储

虽然目前关系型存储占据了主导地位，但是在特定领域，对象存储十分成功。同时，由于对象模型能够存储任何类型的数据，所以对象存储发展DBMS十分有前景。

InterSystems Caché.

数据存储：数据存储在能够携带层次结构化数据的稀疏、多维数组中。

数据访问方法：

ODMG标准的对象

索引：

id集，是位片索引的拓展。

多用例存储

首先，多用例存储的概念需要阐述清楚—— 一组相关的dbms可以表示为多用例。往往是对于数据库应用程序的应用场景而言的。

SAP HANA DB

内存中的、面向列的、关系式的DBMS，结合了三中存储方式的优势。

OctopusDB

模拟OLTP、OLAP、流媒体和其他类型的数据库系统

目前还没有成为多模型的DBMS

目前也存在一些不能表示为多模型的dbms。然而，他们目前正在开发中。

NuoDB

DBMS，可以在云中工作。

Redis

键/值存储

不再可用的DBMS

例如，DBMS FoundationDB被收购，从而不再使用。

结论

大数据时代，不同的数据类型和数据特征为多模型数据库迎来了挑战，也迎来了机会。多模型数据库的出现与完善是迫在眉睫的，如何提供高效的数据管理、查询、存储？

我们这次的探索集中在DBMS应对大数据的多样性挑战上，它需要并发存储和管理不同的数据类型和格式。

尽管多模型DBMS正迈向成熟与健壮的阶段，但其旅程仍漫长且充满挑战，尤其是在与关系数据库世界那些久经考验的解决方案相比时。当前，我们正面临着开发一个全面且高效的多模型数据库系统的艰巨任务。本次调查的核心目标，便是推动研究和工业界的共同努力，以便把握机遇，克服这些挑战，为数据库技术的未来铺平道路。让我们携手并进，共同迈向一个更加灵活、多功能的数据库新时代。