论文阅读笔记：Multi-model Databases: A New Journey to Handle the Variety of Data

 

写在前⾯

看到这篇论⽂，我的第⼀个疑问就是：何为Multi-mode DB？

⼀开始我尝试⽤“多模数据库”去理解，但感觉并不能准确的阐述其本意，结合这篇⽂章（https://www.predictiveanalyticstoday.com/top-multi-model-databases/）以及赵⽼师分享的论⽂，基于⾃身的理解⽤⼀句话解释Multi-model  DB：可以同时针对不同数据模型如关系型、⽂本型、图型等进⾏操作的数据库称之为Multi-model数据库，以下为了撰写⽅便，采⽤不太准确的中⽂名“多模”替代Milti-model。⽽本⽂正是基于这样⼀个技术背景下，结合当前⼤数据5V问题，针对各家DBMS进⾏“华⼭论剑”，最后得出⼀个结论是：⽬前依旧没有⼀个⾜够成熟的技术架构（Multi-model DBMS）能够单独处理上述所提到的多模数据。

这篇论⽂是边看边记边上⽹查资料完成的，从去年开始到现在断断续续花了⼀个⽉（2021-01-07书）才看完。除了个⼈认为的⽂章要点记录之外，个⼈感受就像是笔记末尾总结所述：就像在我没看到这篇论⽂之前，压根就不知道原来还有“Multi-model”这样⼀个洞⻅以及理念—“one size fits all”。可能还对关系数据运⽤场景⽤MySQL、Oracle，⾮关系数据场景⽤Redis、Hbase、Hive等这种策略习以为常。本⽂⼤⼤拓宽了个⼈在数据处理技术上的知识⾯以及对⾏业的认知深度。

 

概述

本⽂主要分为如下五部分

1. 新兴Multi-model DB的研究现状与问题：尽管有多篇新发布论⽂介绍了Multi-mode DB，但没有⼀篇论⽂能够较为全⾯的将多项数据库技术结合在⼀起进⾏对⽐研究。
2. 简单介绍了四种常⽤数据组织模型：Relational、Semi-structured、KV、Graph
3. 对现有的Multi-model DBMS进⾏分类讨论、对⽐学习
4. 从不同的维度，如存储格式、操作语⾔、索引等详细介绍了不同数据模型下的⼏个代表作
5. 依旧存在的问题：⽬前依旧没有⼀个⾜够成熟的技术架构（Multi-model DBMS）针对多模型数据提供统⼀的数据操作接⼝。

在对⽐学习中，本⽂从不同的数据组织⽅式⼊⼿，简单列举了结构化、半结构化、关系型、图数据类型，⽽后进⼀步探讨了对应这些数据所对应的数据库产品。其中包含索引方式、⽀持数据格式、查询语⾔等、元数据等，在索引⽅式中提到Lucence、Hash、B（+） 树等尤其让我⼜复习了⼀把索引相关知识，B+树可是⽼师在课堂上重点讲解的内容。

提出问题

随着互联⽹的发展普及以及⼤数据时代的到来，我们每天要产⽣⼤量各种各样类型的数据，如⽂本数据、图数据、关系数据等。为了存储、处理这些数据，衍⽣了多种多样的数据 处理产品，如我们⼯作常⻅的Oracle、MongoDB、Hbase等，这使得我们可以在各种复杂的场景下都可以很好的找到适⽤的技术。⽽在百家争鸣的背景下，另⼀个问题也渐渐凸显出    来；如何使⽤⼀个统⼀的界⾯或接⼝去访问不同组织结构（Multi-model）的数据？

 

对⽐学习

该部分中简单概述了四种常⻅数据组织模型的特性，包括关系型、半结构型、KV型、图等。其中在半结构化类型中产⽣了⼀个疑问；⽂中将JSON、XML归为半结构化类型，那是否可以将经过组织的⽂本⽂件如⽇志归为半结构化类型呢？从Molti-model DB的发展历史来看，XML作为拓展标记语⾔⼴泛运⽤于Web数据传输中，基于Unicode编码，其有较好的数据交换通⽤性。⽽在后期⼜有了JSON这种集KV、数组、⽂ 本属性于⼀体的更加⾼效的数据表示⽅法。

另⼀⽅⾯，本⽂针对不同数据库类型的代表产品对⽐中，从数据组织类型、⽀持的数据格    式、存储策略等相关特性进⾏了的详细对⽐学习。其中让本⼈影响⽐较深刻的是关于   Lucene、Solr，在许多岗位JD中提到过这两项技能；似曾相识但却⼀⽆所知，从⽹上搜索资料后才想起这是全⽂搜索技术框架，⽽⼀年前曾经⽤过的ElasticSearch正是基于Lucene开  发，那他们三者是什么关系呢？通过进⼀步资料搜索，在阿⾥云社区找到了年初的⼀篇⽂章（https://developer.aliyun.com/article/744246）算是⽐较清晰地道出了三者的关系。

本部分总体来看，其较为详细的从多个维度对⽐了不同类型数据库的特性。从数据查询索引的⻆度出发，所提到的数据库都能够通过倒排索引、B+树或Hash的⽅式提供较⾼的查 询效率，也同样有相当部分数据库采⽤了SQL或类SQL查询操作语⾔，对许多开发⼈员来说，降低了学习成本。除此之外，现有的Multi-model DB还提供了分库分表、Flexible Schema、DAAS等特性，但却缺少针对Multi-model transactions的⽀持

 

详细剖析

本部分基于上⼀部分的分类基础上，对⼏个⽐较有代表性的数据库进⾏⼀个更加详细的论述，涵盖Relational、Column、KV、Document、Graph五种数据组织、存储模型。其主  要围绕代表数据库的存储结构、操作语⾔⽀持、索引机制等⽅⾯展开论述。详细如下。

 

Relational Store数据库

如第⼀个⼩块介绍了关系型数据库，提到了关系型数据的拓展性、通⽤性、易⽤性等⼏个优点。PosgreSQL，⼀款⾮常具有年代感的经数据库产品，已经有40年的历史了。虽然偶尔听到其⼤名，但从来没有⽤过，据说某些银⾏的部分⾦融业务还是使⽤PostgreSQL。此  处提到了json和jsonb这类多模数据组织类型，简单对⽐了两者的优缺点；如json类型插⼊快但取⽤慢；jsonb作为json的解析⼆进制格式，插⼊慢⽽取⽤较快。此处也简单介绍了在此类数据操作的操作符如->,->>#>等，同时给出了⼏个简单的SQL语句。当然关于json和jsonb的更多信息我还是从⽹上查询了才了解到的，⽐如这篇博客就写的⽐较清晰易

懂：https://www.cnblogs.com/alianbog/p/5658156.html。沿着jsonb，本⼩块还介绍了其     索引相关的知识，简单提到了GIN（Generalized Inverted Index）以及B-tree，特别是GIN索引结构的两种情况：posting tree 和posting list，其余Java8后的HashMap存储策略倒是⾮常类似。

接着⼜介绍了SQL Server、DB2、Oracle、MySQL对Relational Data和K/V Data的多模操作⽀持，对XML、JSON数据类型的⽀持，以及对应的数据操作、索引机制。最后简单介 绍了基于以上传统关系数据库下所研发的⽆固定数据模型的Sinew数据库，其可以⽀持上述 提到的多种数据模型的灵活操作。这让我想起了公司⾃⼰研发的那⼀套ETL系统就是通过JSON数据来控制作业运⾏流程的，但其中的JSON数据是通过单独的JSON⽂件来存放的， 在JSON⽂件很多的时候并不容易管理。是否可以尝试将JSON数据直接以JSON  format string存放在数据表呢？⽬前公司有多重模式的数据库，是否能够有有⼀个统⼀的数据接⼝  进⾏操作呢？

 

Column Store数据库

不同于传统的航存储⽅式，在⼤数据OLAP领域⽐较多的采⽤列式存储以提⾼数据查询效率；在海量的数据⾥⾯只需要提取出需要的那⼏个列进⾏分析，典型的针对“⾼表”分析运⽤场景。

1. 单列存储（Column-oriented）：⼀个列⾥⾯只存储单个属性
2. 列簇存储（Column-family）：⼀个列⾥⾯存储多个属性，其以列簇的形式体现

该部分主要探讨了列簇式存储数据库

⾸先，这⾥采⽤Cassandra为例⼦介绍了其以下⼏个特性：

存储机制：列簇存储其Blocks、Immuttable机制以及修改数据时HBash相似的数据版本控制机制，以此加速了数据查询。其同样⽀持JSON格式，但需要提前指定Schema。表6给出了⼀个JSON schema从⾥向外层层嵌套预定义以及对应的数据插⼊例⼦，很具有学习意义， 在此进⾏截图记录。

 

1. 查询语句：我们可以把它看成是SQL的⼀个⼦集，其⽀持SQL常⻅操作。但在针对列簇数据进⾏where查询和索引时会⾯临⼀些限制。
2. 索引机制：其中间索引默认采⽤倒排索引机制，⼆级索引采⽤B+ trees⽅式以⽀持范围查询。虽然合适索引可以增加查询效率，但并不推荐针对频繁修改、删除、⼤范围查询的数据表列进⾏索引建⽴。

⽽后简单介绍了Column-oriented数据库CrateDb查询层⾯的Lucence索引⽀持，值得注意的是其为动态Schema数据库。

⽽接下来介绍的DynamoDB可作为云部署的、具有动态Schema、分布式的⾼性能数据库。这⾥简单提到分区Key、排序Key以及全局索引和局部索引以及他们的不同之处。最后提到  的HPE⾼新能分布式数据库中的virtual column与real column的转换也是值得关注，如virtual column可以转换成real     column以获得更⾼的查询性能。以上两款数据库皆提到了SQL操作、索引、针对JSON以及其他数据模型得⽀持。

 

K/V Store数据库

键值数据库被认为是最简单的NO SQL数据库，在索引中只需要听⼀个Key就可以索引到对应的值，但也因此⽽使得针对值的操作更加的复杂。

⾸先来看看Riak，其作为经典的K/V数据库，基于Sorl的集成提供了了⾼效的索引机制。另外从开源中国（https://www.oschina.net/p/riak）也可以了解到，其还具备分布式、⾼可⽤、⾼可拓展的特性。另外⼀个KV DB c-treeACE同时⽀持No-SQL和SQL两种操作模式。最后介绍的Oracle NoSQL除了具备JSON、Index外，还添加了RDF：Graph module、Child Table等机制，同时在⽂中还给出了JSON Schema定义与数据查询的例⼦。关于JSON Schema定义和上述Cassandra不⼀样的，其Schema描述遵循了JSON数据格式，⼤⼤增强了可读性。

 

Document Store数据库

据⽂中所述，⽂档数据库也可看成是KV型数据库的增强模式，其⽂档索引也和KV DB 类似，⽀持复杂查询。同样的，以下简单对⽂中介绍到的⼏款代表性数据DOC数据进⾏归  纳。综合来看，⽂档数据库显得更加的贴近于multi-model DB，以下所介绍数据库从数据存储结构、索引策略出发，论述了集KV、DOC、Graph等多种模式于⼀身的集中代表性DOC 数据库。

ArangoDB

⽂中⾸先介绍了ArangoDB这⼀原⽣多模型、开源数据库，其强⼤的AQL查询⽀持在⼀ 个单个查询中混合使⽤三种数据模型（kv、doc、graph）。此外也介绍了⼏⼤值得关注的特性，如其和JSON类似的⽂档存储组织存储⽅式；⽂档之间的关系图模型及对应图算法的经  典操作（图遍历、最短路径）；Hash和Skiplist索引⽅式及其差别（Hash不⽀持范围查询或 排序⽽Skiplist⽀持，除此之外ArangoDB也⽀持persistent、full-text、geo等索引⽅式）。详 细性能参⻅官⽹：https://www.arangodb.com/performance/。

Couchbase

这款数据库给我感觉和redis、memcache类似性质但⼜不⼀样，从其官⽹(https://www.couchbase.com) 也 可 以 看 到 ：Best NoSQL Cloud Database Service（build fast、scala big、save more），其是⼀款基于内存的⾼性能⽂档数据库。此外，其有以下⼏个特性值得⼀提：

1. 对JSON存储格式的数据⽆需预先创建Schema，使得数据操作更加灵活。
2. 针对操作频繁的⽂档进⾏缓存，以及append-only、regular compaction特性使其可以提供更加⾼效的服务响应。
3. 类SQL API提供了针对地理空间、JSON、KV等复杂数据的操作。
4. 提供了B+tree好B+trie（字典树）两种索引，其中B+trie因为在树结构上构造更短的深度⽽获得更好的查询效率。

接下来提到了MongoDB，其作为时下最流⾏的DOC DB，⽂中介绍了其Flexible Schema、JSON syntax 数据查询、Manual和DBRefs 引⽤、BSON作为JSON的⼆进制⾼效表示等特性。⽽后介绍的Cosmos DB和MarkLogic除了基本DOC DB属性外，也都各有特性，如Cosmos DB的多模式（constistent/lazy/none）索引更新策略、MarkLogic基于树状存储结构为XML和JSON提供的统⼀索引管理⽅式。值得⼀提的是MarkLogic针对⽂档索引提供了kv互换下的两种范围索引数据结构：KV和VK型。

 

Graph Store数据库

图模型数据库算是最为复杂的那⼀批了，学习了数据结构或离散数学的同学都知道各种复杂的算法都集中在图结构⾥，可能这也是为什么在这部分只⽤了⼀个数据库作为介绍样   例。

按照本⽂⻛格，针对OrientDB这⼀图模型数据库代表的介绍同样围绕着存储结构、数 据操作、索引等关键点进⾏。OrientDB⽀持针对云环境的⽀持，这意味着其能够提供DAAS 平台层⾯的服务。顾名思义，其作为对象数据库，也⽀持类型继承以及类间关系建⽴，如引

⽤；类似于Java代码涉及中常⽤的“引⽤”策略，其作为依赖注⼊中常⽤到的⼀种类间关系组织⽅式。此处介绍了两种类间关系模式：引⽤（Referenced）和嵌⼊（Embedded），其中  “引⽤”通过存储对应数据的物理连接来维持这⼀关系；⽽“嵌⼊”⽅式下直接将实际数据存储  在对饮的关系的数据对象下形成共⽣依赖。两种类间关系组织都⽀持单点记录、Set、List和Map四种结构。同样的，作为图模型⽀持，节点（vertex）和边（edge）⾃然也是要体现出来的，本⽂以⼀个简单的例⼦给出了⼀个图创建案例，如下：

从案例中我们可以看到：

1. 节点类需要继承类V（vetex）。
2. 边类继承E（edge）。
3. 节点数据嵌⼊（Embedded）的时候在本类数据对象中直接保存了嵌⼊关系数据的实际数据。
4. 边创建时可以指定节点之间的关系，如Mary认识John，John与之对应的订单节点。

⽽在OrientDB中，其同样⽀持复杂的图遍历语⾔Gremlin

（https://www.jianshu.com/p/8f1f8aafc9b1）以及针对图遍历的拓展SQL。需要注意的是OrientDB并不⽀持Join操作，细想也是，其类间关系通过边进⾏链接建⽴，⽽⼀个庞⼤的图节点间可以进⼀步建⽴异常复杂的关系模型（参考社交⽹络关系图），在这样的情况下进⾏Join⾸先就需要⾯临⼤规模图查找的问题。说到查找，OrientDB基于B-tree的改进，运⽤SB-tree（Size balance AVL tree）获得了更⾼效的数据插⼊和区间查找操作，此外其基于Hash散列算法的拓展可以获得更加⾼效的查找但不⽀持区间查找。

 

Others Stores

当然除了上述⼏种主流的数据存储模型之外，还有其他⼀些潜在的多模数据存储模型， 如object-model、multi-use-case stores。针对object-model，理论上来说是可以存储任何类型的，从⾯向对象的的编程思想来看：“万物皆对象”。其中对象模型数据代表有INterSystems，其中值得⼀提的是其⽀持schemaless、schema-based存储策略，这将带来 更加灵活的数据定义操作。针对Molti-Use-Case，其思想是one-size-fits-all。有点类似于“⼀ 招通吃”？就像是SAP HANA DB其作为⾯向列存储的关系数据库，既可以运⽤以OLTP（On- Line Transaction Processing ）、⼜适⽤于OLAP（On-Line Analytical Processing）；⼀个⼯具涵盖了两种主流运⽤场景。

当然了，多模数据库还是由单模发展⽽来。本⽂还介绍了⼀些在当前是单模数据库，在未来很可能发展为多模的例⼦，如NuoDB、Redis、Aerospike等，其中提到New-SQL还是挺值得关注的。

 

遇到的挑战

虽然上述介绍了如此多的技术模型，但针对当前⼤数据背景下的5V问题（Vlume、Velocity、Variety、Veracity、Value），我么依旧⾯临许多挑战。本⽂简要提出了以下⼏个⾯临的挑战。

1. 数据操作问题：当前不存在⼀种能够对各种模型数据进⾏完备操作的语⾔，即使AQL 已可以操作图、⽂档数据模型，但依旧不够成熟。此外在针对动态Schema时，也还不存在成熟的技术⽀持。其他类似的还有多模型数据索引问题、基于云的分布式数据管理问题。
2. Schema设计问题：表结构设计的合理与否和数据操作、存储效率息息相关。以本⽂为例，如何调和关系数据与⾮关系数据之间建⽴⼀个统⼀的操作或是标准？是否可以将XML、JSON这种⾃带Schema数据类型作为多模数据库的突破向？动态类型推断 呢？
3. 多模数据的演变问题：随着数据模型愈发复杂的演变，我们往往需要⾯对同类数据模型间（intra-model）以及不同数据模型间（inter-model）内部的数据处理，已经⽆法单从富有经验的DBA对数据进⾏管理，⽽是继续⼀种新的平台级解决⽅案。
4. 拓展性问题：我们⾯临着同类数据模型间的纵向功能性拓展，如XML的ID与ID引⽤查询。同时也⾯临着不同数据模型间的横向贯通拓展；如怎样让关系数据库也⽀持XML相关的操作？或者⼲脆在原有的数据模型上拓展出新的模型。

 

总结

以上对⽐了各种数据模型的典型数据库产品，并重点针对数据存储模型、操作语⾔、索引、拓展性等进⾏论述。但存在⼀个问题是：我们⽬前还没有⼀个较为成熟的、可针对多种数据模型提供⼀个统⼀操作接⼝的数据库技术。⽽在⼤数据背景下，针对5V问题（Vlume、Velocity、Variety、Veracity、Value），我们急需⼀个统⼀的数据库技术来操作多种数据模 型，贯通各个数据模型间壁垒，进⽽提⾼数据处理效率、降低数据处理难度、节约企业数据处理成本。相信经过⼏⼗年的技术发展，当前⼀定存在着各种各样我们所不知的数据模型、技术和数据处理策略；就像在我没看到这篇论⽂之前，压根就不知道原来还有multi-model这样⼀个洞⻅：“one  size  fits  all”。可能还对关系数据⽤MySQL、Oracle，⾮关系数据⽤Redis、Hbase这种运⽤策略习以为常。故⽽基于⼆⼋法则，我们是不是可以针对最为常⽤  的哪⼏种数据模型开发出⼀个统⼀的、可操作多种数据模型的技术框架呢？就像⽂末附录所提到的最常⽤的五种数据模型（Relational、Column、KV、Document、Graph），或许在  未来的某⼀天会有⼀个统⼀的技术架构对这些类型的数据进⾏各种复杂处理呢。