图数据库的发展脉络与技术演进

发布时间：2025-11-05 03:08:35 来源：码上建站 作者：人工智能

导读：​本文由香港中文大学James Cheng教授团队贡献，图数James Cheng教授长期从事分布式系统、据库进分布式计算、展脉图计算与图数据管理等方向的络技研究工作。曾与阿里巴巴、术演华为、图数腾讯、据库进字节跳动等多家公司在大数据计算系统、展脉存储系统、络技调度系统、术演深度学习系统等方向上展开项目合作，图数曾获得香港青年科学家称号，据库进ATC21最佳论文奖。展脉

接下来，络技大家一起来了解下图数据库技术发展的术演前世今生吧：​

一、背景介绍

与传统数据库相比，图数据库的本质区别在于可以更高效的存储和查询图数据。不同的存储模型导致了不同的查询执行策略和对图的具体操作行为，这将最终导致各种性能。例如，在原生的图数据库中，可以通过扫描无索引的邻接列表来执行遍历操作，在基于关系型表而设计的图数据库中，则需要通过对多个表的Join操作来执行。随着遍历跳数的增加，对于幂律分布的图数据来说，用于Join的表的云南idc服务商大小可能呈指数级增长，这将导致严重的性能瓶颈。而另一方面，关联型的数据以Table的形式存储在关系型数据库中，可以实现更好的数据平衡和定位。对于一些原生的图数据库来说，由于图结构的不规则性，不规则的数据模式导致了较差的数据局部性，并为数据检索带来了额外的开销。

本文将梳理图数据库发展的历史脉络与技术演进，并简单讨论笔者认为图数据库今后的发展方向。

二、图数据库的发展历史

从Google分别于2003、2004、2006年在SOSP03、OSDI04、OSDI06发表经典三驾马车（GFS，MapReduce，BigTable）论文开始，以Hadoop开源生态为中心的大数据体系得到了蓬勃的IT技术网发展，数据模型逐步由以表（Table）的主流形式来存储和查询关系型数据慢慢发展到以键值、宽列、文档、图等各种形式来存储和查询海量数据的NoSQL体系。

日益膨胀和快速发展的各类应用所产生的数据使得NoSQL体系对数据存储与查询的要求变得多种多样：高吞吐、高可用、低时延、强一致等等。因此在大数据时代下，各类组件百花齐放，迭代升级也非常迅速。图数据存储作为NoSQL体系中的一种数据建模方式，主要用以表达现实世界中实体间的关联关系；图数据库则是与之对应的存储系统，用以存储和管理（增删改查）图状数据。

图数据库是一种非关系型数据库，以解决现有关系数据库的局限性。图模型明确地列出了数据节点之间的依赖关系，而关系模型和其他NoSQL数据库模型则通过隐式连接来链接数据。图数据库从设计上，就是可以简单快速地检索难以在关系系统中建模的复杂层次结构的。图数据库的底层存储机制可能各有不同。有些依赖于关系引擎并将图数据“存储”到表中（虽然表是一个逻辑元素，但是这种方法在图数据库、图数据库管理系统和实际存储数据的物理设备之间施加了另一层抽象）。另一些则使用键值存储或文件导向的数据库进行存储，使它们具有固有的NoSQL结构。大多数基于非关系存储引擎的图数据库还添加了标记或属性的概念，这些标记或属性本质上是具有指向另一个文档的指针的关系。这样就可以对数据元素进行分类，以便于集中检索。

图片来源自：https://k21academy.com/dba-to-cloud-dba/nosql-database-service-in-oracle-cloud/

从大约2010年开始，各种构建于NoSQL体系或者关系型数据库之上的图数据库便涌现而出，比如：Titan, JanusGraph, RedisGraph, Sparksee, AgensGraph, OrientDB 等等, 当然同一时间也出现了Neo4j这种为图数据而专门设计的图原生存储数据库，其现今已经发展成为了图数据库领域商业化的领头羊。我们下面将根据存储模型的不同对这些图数据库做一个简单的归类和讨论。但由于篇幅有限，详细的分析和性能对比不会在本文展开，我们今后将会在arXiv上提交一篇Experimental Track的学术论文来系统性地分析这些图数据库的设计方案和性能测试报告。

1、图数据库的存储设计​

如何存储图数据以实现高效查询和更新是图数据库的一个重要问题。对于一个图模型G，应该考虑的存储数据包括点（V）、边（E）、顶点属性（VP）和边属性（EP）。一个图通常又可以用三种常见的方法来表示：邻接表、邻接矩阵和边列表。邻接表通常将一个顶点的所有邻居作为一个数组来存储。因此，一条边从两个方向上会出现在两个不同顶点的邻接表中。邻接矩阵选择用一个矩阵来表示两个顶点之间是否有一条边，而边表会独立存储所有的边集合，并使用指针让每个顶点记录它与自己邻居的关系。

2、图原生数据库

Neo4j定制化的分别将四种对象（即点、边、点属性和边属性）作为记录来存储，并利用指针将它们连接起来。图1展示了Neo4j如何在物理存储上组织所有对象。一个顶点/边的所有属性都以链表的形式连接起来，其头部由相关顶点/边的实例的指针指向。与属性类似，一个顶点所有相邻的边也被连接在一起，但用双链接列表来呈现。每个边的实例将只存储一次，但由两个邻接表连接。因此，要找到边的实例，唯一的方法就是遍历顶点上的双向链表，这就会产生对边集的扫描开销。然而，Neo4j中的遍历可以通过双链表的形式来加速。具体来说，考虑到没有顶点属性访问的两跳遍历，Neo4j需要：1）从起始顶点开始遍历双向链表，找到第一条边；2）迭代步骤（1）中找到的所有边上连接的其他双向链表，完成下一跳。这种两跳遍历可以摆脱在两个步骤之间加载顶点记录，以减少磁盘I/O。

图1 - Neo4j的存储模型

图2说明了Neo4j如何将所有记录存储在磁盘上。我们可以看到，每条记录都有自己固定大小的块，相同类型的记录被连续地存储在一起，形成一张表。因此，表中的每条记录都可以根据其偏移量进行有效定位，其中偏移量是根据记录的ID计算的。对于属性值，如果它的长度大于一个记录块的默认长度，那么Neo4j将把这个属性值的超出部分存储在另一个由若干固定大小的槽组成的分离数据块中。

图2 - Neo4j不同类型的数据记录在磁盘上的组织形式

RedisGraph是一个基于Redis的图存储，Redis是一个基于内存的键值存储系统。然而，RedisGraph没有将图数据建模为适合Redis存储模型的键值存储，而是利用邻接矩阵设计了自己的存储模型，只利用了Redis的内存分配和索引管理。这就是我们将RedisGraph列为图原生存储数据库的原因。

图2展示了RedisGraph是如何建模和存储图的。点和边的属性被存储到一个顶点/边缘容器的数组中。每个顶点/边容器都有一个header来记录当前容器的元数据，包括存储的顶点/边的数量，容器的容量，以及使用的内存大小。对于每个顶点/边，其属性被存储在一个链表中，链表里的每个节点是一个具有固定大小的数据块。属性的键值对被按顺序存储在数据块中。当前一个数据块满了之后，一个新的数据块将被追加到链表的尾部。此外，RedisGraph将具有相同标签的顶点/边放到同一个容器中，以获得更好的数据局部性。由于RedisGraph需要为每个顶点/边和数据块从Redis存储层调用内存分配，它根据容器的容量预先分配了容器所需的所有内存，以避免频繁且昂贵的内存分配调用。

RedisGraph中的所有边都以邻接矩阵的格式存储。如果两个顶点之间存在一条边，就会在邻接矩阵的对应位置上存储一个指向该边实例的指针，否则就不存储。由于图的性质，邻接矩阵大多是一个稀疏矩阵。因此，RedisGraph选择使用了压缩稀疏行（CSR）的格式来实现对矩阵的存储。而多跳遍历可以通过RedisGraph中的矩阵乘法来计算。然而，在CSR格式下，图拓扑结构的变化对CSR的更新是很昂贵的，而且会给遍历操作带来严重的开销。

图3 - RedisGraph的存储Layout设计

Sparksee以前被称作DEX，也是一个图数据库。它利用基于位图的索引bitmap来减少存储开销，并通过基于位（bit）的逻辑操作来加速与图相关的工作负载。

为了存储一个图，Sparksee首先将所有的数据分为不同的值集（value set）。具体来说，一个值集是由以下一种键值对组成的：1.（顶点/边ID，Label）；2.（边ID, 头/尾顶点ID）; 3.（顶点/边ID, 属性键的属性值）。对于每个值集，Sparksee用两个map来存储所有的对：一个map记录每个对象（即顶点/边）到一个值（即Label、头/尾顶点或属性值），而另一个map则是将不同的值映射到一个位图（如图4所示）。因此，图的拓扑信息是以边列表和邻接表（即位图）的形式存储在值集中的。

位图结构是一个具有可变长度的bits序列，它由第一个和最后一个非零元素定义。位图中的每个位都与一个对象的标识符oid相关（即顶点/边ID）。如果该对象有相关的值，相应的位置就被设置为1，否则为0。通过使用位图结构，Sparksee可以将一些基于图的操作转化为位运算操作。由于位图的长度是由第一个和最后一个非零元素定义的，所以位图不可避免地会变得很大，这就造成了数据检索的开销。为了压缩位图，Sparksee将一个位图分割成多个长度为32位的子序列。每个子序列都与一个给定的ID配对，并存储在一个排序的树中。为了减少空间的使用，只有非零的子序列会被存储并被排序树索引。由于bits是以连续的方式分割的，Sparksee可以在数据检索时快速定位到某个bits的子序列ID。

图4：Sparksee中的值集与位图

3、基于RDBMS构建的图数据库​

由于关系型数据库有相对成熟的技术和性能优化，许多图数据库都是建立在RDBMS或关系型数据模型之上的（比如SQLGraph, AgensGraph, etc.）。AgensGraph就是一个构建于PostgreSQL之上的图数据库，Oracle Spatial and Graph则是Oracle中支持图数据存储的一个组件。为了在关系数据库中建立图数据模型，顶点和边通常被存储为表中的记录，其中的每一列代表一种属性。除属性外，边记录还将其源点和目标点作为两个外键存储，以支持遍历操作，这可以通过表的Join来完成。而连续的Join会严重损害多跳遍历的性能，特别是当表内有大量顶点时。

我们以AgensGraph为例来介绍在关系型数据库中存储图数据的方案。由于顶点/边的属性在图中并不总是有固定的Schema，AgensGraph用基于JSON的表来存储属性，所有的属性都以JSON格式存储在一列。具体来说，AgensGraph表中的一行记录，对于顶点是按照（VertexID, Label, Properties in JSON）的格式来存储的，对于边则是按照（EdgeID, Source VertexID, Destination VertexID, Properties in JSON）的格式存储的。图5显示了AgensGraph是如何管理磁盘上的表数据的。表文件首先被切成具有固定大小的多个页。每页的页头存储了本页的元数据，包括存储的记录数和这一页的使用空间。为了更好地在页中进行顺序扫描，每条记录都有一个固定大小的指针块，包含相关记录数据的偏移量和长度。指针块以正向方式从页头开始存储，而记录数据则以反向方式从页尾开始存储。

图5 - AgensGraph中图数据在Table中以页的方式的存储格式

4、基于文档构建的图数据库​

文档存储的基本单元是一个以某种标准格式（如JSON、XML或BSON等二进制格式）编码的文档。通过这些半结构化的格式，文档可以灵活地以键值对的形式存储顶点/边的属性，且没有固定的Schema。因此，在基于文档的图数据库中，一组顶点/边被存储为一个文档。为了连接顶点和与之关联的邻接边，顶点文档会包含该点的邻接表，其以一组嵌套的键值来表示，对应的值是一个List或者是一组记录了label的键值对。

OrientDB是一个典型的基于文档的图数据库。图6展示了OrientDB是如何存储顶点和边文件的。顶点和边首先被它们的标签分离成类。一个类可以为存储的文档定义一个属性集。虽然一个文档不一定包含所有定义的属性，但类仍然可以帮助在访问实际数据前对不存在的属性进行预过滤。每个类可以进一步分割成多个cluster，以便根据CPU核数实现并行数据访问。每个顶点/边分配了一个唯一的RID，以便快速定位，RID由类ID、Cluster ID和在Cluster中的位置构成。

除了RID和属性，顶点文件还存储了两种不同格式的邻接表（即regular Edgelist和lightweight Edgelist）。Regular Edgelist存储了相邻边的RID，而Lightweight Edgelist包含了入向顶点的RID。因此在遍历时，如果查询不需要访问边属性，OrientDB可以使用Lightweight Edgelist来直接获得目标顶点。否则，OrientDB将通过RID找到边文档来访问边属性，最后获得存储在边文档中的顶点RID（即源点和目标点）。

图6 - OrientDB的数据存储格式

5、基于宽列构建的图数据库​

宽列存储是由表组成的，表是行的集合。与关系型数据库不同，宽列存储没有要求固定的Schema。每一列的名称因行而异，每一行的键值对都存储在这一列中。因此，宽列存储也可以被视为二维键值存储。Google的BigTable和Hadoop生态体系下的HBase就是典型的宽列存储。其表中的每一行都包含任意数量的单元格，每个单元格都存储一个键值对。利用宽列模型来存储图数据的典型图数据库有Titan和JanusGraph。

JanusGraph的底层存储就是HBase, 在HBase中每一行都是一个由ID唯一识别的顶点。如图7(a)所示，JanusGraph将点的每个属性和邻接边都存储到行中的一个单元格中。为了快速检索，属性按属性ID排序，边按边的标签排序。图7(b)显示了JanusGraph中边和属性存储的详细格式。一条边的key是由label和direction的复合ID、排序键、相邻顶点ID和边ID组成的。排序键可以由边的label和其他边的属性来组成，以便加快遍历。

由于JanusGraph没有将边组织成Row，所有的属性都被序列化并存储在表示边的列单元中。为了避免在属性过滤时对属性列单元中的值进行频繁的反序列化，JanusGraph存储了signature key，其包括了所有的属性ID，以便快速检查属性是否存在。属性列单元的结构比边列单元相对简单，属性单元的key字段只存储一个由属性key编码的ID，而value字段包含一个为每个属性键和属性值分配的唯一ID。

图7 - JanusGraph的图数据存储格式

三、图数据库的现状

随着大数据基础设施的不断发展与完善， 数据库产品的研发方向也正在从不断提升经典存储系统的性能与稳定性逐步转向为针对各种垂直类场景的特定性能要求而定制化设计。例如，随着物联网时代的到来，各类传感器、汽车、基站等端设备产生的数据规模正不断增大，该场景具有典型的存量数据大、新增数据多（采集频率高、设备量多）的特点，对数据库的实时性能要求也比较高，通常需支持千万级QPS的写入，以及毫秒级的查询响应时间。传统的数据库架构很难再满足这种特定场景下的读写需求，用户已不再考虑一招能解决所有问题（one-size-fits-all）的方案，而逐渐转向针对不同工作负载给出特定数据库选型方案的思路。由此，各种垂直类型的数据库不断被提出，例如图数据库、时序数据库、流式数据库、向量数据库等等。

图数据库的架构和性能需求也在不断与时俱进，进入"2.0时代"。一方面图数据的规模越来越大，一套成熟的分布式高可用方案已经变成对图数据库的基本需求，另一方面对图数据的查询复杂度也在进一步提升，人们越来越想从高阶的多跳查询（>3跳）中挖掘出关联关系数据的深层价值。而图数据本来天生就具有数据倾斜的特点，出入度大的点往往占比很少，而与之相关联的查询却需要访问很大比例的全图数据才能返回最终结果，因此需要更多的算力。然而，在图上对度数大的点的访问是很难预测的，如何在不影响吞吐的情况下，降低查询的平均延时以保证服务的P99能满足在线要求？单是这一点就是件挑战力十足的事情。

而随着图数据的价值不断被认可，越来越多的应用场景也开始使用图模型来表达业务数据（例如，金融网络中的反洗钱、反套现，电商交易网络中的商品推荐，短视频中的点赞关注记录等）。数据从产出之初，就被业务写入到了图数据库中，并期望可以做到写后的实时可见，因此在高可用的前提下，图数据库对数据的一致性、事务性也开始有了要求。新一代的图数据库架构在时间和业务需求的催化下，被自然衍生了出来。图数据库的热度也一路水涨船高，如DB-Engines网站所示，从2013年开始至今，图数据库的流行趋势变化是所有垂类数据库中最高的，且看趋势至少未来5年也依然会保持最高。2023年，图数据库的标准查询语言GQL也会发布，各种类型的图数据库查询语言（e.g., Gremlin, Cypher, GSQL, nGQL）相信终将迎来统一，这可以进一步促进图数据库生态的发展。

接下来，本文将盘点近几年有代表性的若干个现代图数据库的架构设计，简单讲解下图数据库2.0时代对高可用性和高性能的业界实现方案。

1、NebulaGraph

NebulaGraph是一款开源的高性能分布式图数据库，一个完整的 Nebula 部署集群包含三个服务，Query Service， Storage Service 和 Meta Service， 如图8所示：

图8 - NebulaGraph的系统架构

图片来源自：https://www.nebula-graph.com.cn/posts/nebula-graph-architecture-overview

Meta Service集群基于raft协议保证了数据的一致性和高可用。Meta Service不仅负责存储和提供图数据的meta信息，如schema、partition信息等，还同时负责指挥数据迁移及 leader 的变更等运维操作。左侧主要服务采用了存储与计算分离的架构，虚线以上为计算，以下为存储。计算层和存储层可以根据各自的情况弹性扩容、缩容，也使水平扩展成为可能。此外，存储计算分离使得 Storage Service 可以为多种类型的计算层或者计算引擎提供服务。

Nebula的每个计算节点都运行着一个无状态的查询计算引擎，而节点彼此间无任何通信关系。计算节点从Meta Service读取meta信息然后将请求发送到对应的Storage Service实例上。这样设计使得计算层更容易使用 K8s 管理或部署在云上。每个查询计算引擎都能接收客户端的请求，解析查询语句，生成抽象语法树（AST）并将 AST 传递给执行计划器和优化器，最后再交由执行器执行。

Storage Service采用shared-nothing的分布式架构设计，每个存储节点都有多个本地 KV 存储实例作为物理存储。Nebula同样用Raft来保证这些 KV 存储之间的一致性，并在KV语义之上封装了一层图语义层，用于将图操作转换为下层的KV操作。图数据（点和边）通过Hash的方式存储在不同Partition中，这些Partition分布在所有的存储节点上，分布信息则存储在Meta Service中。

2、ByteGraph

ByteGraph是字节跳动基础架构团队自研的分布式图数据库产品，并在字节内部的近一百条业务线上得到了广泛的落地，包括抖音上的好友关系，用户-视频点赞关系等。ByteGraph的架构（如图9所示）整体上跟Nebula较为类似，也采用计算-存储分离的架构，不同的地方在于ByteGraph的存储层进一步划分成了内存存储层和磁盘存储层。

图9 - ByteGraph的系统架构

图片来源自：https://zhuanlan.zhihu.com/p/109401046

ByteGraph的查询层同样没有状态，可以水平扩容，主要工作是做读写请求的解析和处理（将数据请求基于一致性哈希规则分发给存储层实例并收集返回的请求结果）。内存存储层的实现和功能有点类似内存数据库，提供高性能的数据读写功能，具体提供点边的读写接口并支持算子下推：通过把计算(算子)移动到存储层实例上执行，以有效提升读性能。内存存储层整体上作为了磁盘存储层的缓存，提供缓存管理的功能，支持缓存加载、换出、缓存和磁盘同步异步sync等功能。磁盘存储层是一个单独部署的分布式键值对存储服务，将图数据以KV pairs的形式持久化存储在磁盘上。

ByteGraph针对热点数据访问做了自己的存储优化，从系统角度当然希望存储在KVS中的KV pairs大小控制在KB量级且大小均匀。其将顶点的所有出度邻居平均拆分成多个KV对，所有KV对形成一棵逻辑上的B-Tree，数据结构如下图所示。值得一提的是，ByteGraph在今年的VLDB22 Industrial Track上发表了一篇论文，对其设计动机和性能分析都做了比较详细的描述，具体可参考论文地址：

​https://vldb.org/pvldb/vol15/p3306-li.pdf​

图片来源自：https://zhuanlan.zhihu.com/p/109401046

3、EasyGraph

EasyGraph是腾讯TEG数据平台部自研的分布式图数据库产品，目前已在腾讯内部如企业微信、微信支付、王者荣耀、和平精英、QQ、广告等诸多关键产品线落地，并且作为腾讯云KonisGraph图数据库对外输出。

图片来源自：https://zhuanlan.zhihu.com/p/450584880

EasyGraph整体上采用存储计算分离架构，在KV存储组件上适配了开源的TiKV及内部分布式KV；TiKV基于rocksdb实现了分区和副本管理，并在TiDB上有成熟的解决方案，适配TiKV可以实现存储层的可扩展性，TiKV基于Raft算法实现了数据多副本之间的一致性。EasyGraph也自研了图可视化分析引擎，在可视化效果及规模上都有明显的提升，支持几十万级点边渲染分析，以及用户级灵活的布局展示和可视化分析。

EasyGraph也支持AngelGraph图计算引擎，其包括几十种传统图算法、Embedding及GNN算法，如社区发现、标签传播、随机游走等算法，这些算法进一步提升对图数据的挖掘分析能力。

4、Neo4j latest​

最新版本的Neo4j已经支持了分布式模式以完善对高可用性和可扩展性的支持，其通过多副本的方式来防止数据丢失，如下图所示：

图片来源自：https://neo4j.com/docs/operations-manual/current/clustering/introduction/

Neo4j通过Primary Mode将一份数据备份到多个servers上并通过raft协议来保证一致性。与之相对应地，一次写入需要保证至少在(N/2+1）个副本上写成功才可以返回成功，因此在primary mode下服务实例数量越多，写性能就越差。而为了实现可扩展性，Neo4j也支持了Secondary mode，即支持对多个只读副本的部署以提高集群整体的读能力，只读副本是功能齐全的Neo4j数据库，能够完成任意（只读）图数据查询和过程。只读副本是通过事务日志shipping来完成对主副本的数据异步同步的。

Neo4j也支持了数据科学（Graph Data Science）库，其包含了许多图分析算法，比如社区发现，路径搜索等，甚至也支持了少量的图神经网络算法（比如GraphSage， Node2Vec）。这些算法统一集成在了Neo4j的Cypher语言体系下，以提供给用户统一的图查询/图分析体验。

5、TigerGraph​

TigerGraph如今已经发展成为了一个商业化程度仅次于Neo4j的图数据库产品，但由于其是一个闭源产品，很多技术实现我们无从知晓。从TigerGraph网站上的官方技术博客描述来看，TigerGraph 是一款分布式MPP图数据库，同时支持在线事务处理（OLTP）和在线分析查询（OLAP），也集成了基于PyG的图神经网络训练功能。

从架构上看，TigerGraph集成了较为完善的数据导入功能，可以在系统在线的情况下，将关系型数据或其他格式的半结构化数据导入到TigerGraph系统中。TigerGraph的Graph Storage Engine（GSE）负责了对数据的压缩和存储，其将数据编码、转换成一种对MPP处理友好的图原生存储格式后加载至Graph Processing Engine（GPE），而GPE则是具体负责响应查询请求和图计算分析的执行引擎。TigerGraph还包含一个可视化的客户端以及 REST API，并集成了很多企业数据基础设施服务。TigerGraph使用Apache Kafka让GSE与GPE进行数据同步，逻辑上GPE可以理解为一个内存存储层，而GSE是一个图原生的持久化存储层；数据的更新将先反应到GPE层，然后通过Kafka将Transaction Log交给GSE消费并完成持久化更新。

图片来源自：https://docs.tigergraph.com/tigergraph-server/current/intro/internal-architecture

在OLTP功能上，TigerGraph支持完整的ACID特性，支持最高的serializability事务隔离级别。TigerGraph支持垂直扩展和水平扩展，且可以对集群中的图数据自动分区。从这点来看，TigerGraph对大规模图数据的存储支持得比Neo4j要友好很多。TigerGraph使用自定义的GSQL语言来表达查询逻辑，GSQL将SQL风格的查询语法与Cypher风格的图遍历语法结合在了一起，并支持用户自定义函数。

四、图数据库的未来

图数据库在经历了最近几年的蓬勃发展之后，无论是系统性能还是稳定性都得到了大幅提升，那接下来Graph Database Community再会往哪些方向发展呢？

笔者认为，一方面统一图数据库的查询语言标准（GQL）是一件迫在眉睫的事情，标准的制定将有利于降低用户的学习门槛，并使得图数据库的查询优化技术可以得到更充分的发展，比如根据图数据分布往往不均匀的特点提出定制化的基于规则和基于代价的优化策略，还比如可以将如今在OLAP领域大红大紫的向量化执行技术和代码生成技术引入到图查询引擎中，以提升Graph OLAP的执行效率。而另一方面，笔者认为图数据库之所以能在最近几年大火的另一个原因是源于图计算技术和图AI技术的崛起。而这些技术能够同时引起各界学者和工程师的关注也是因为图状数据的独特之处 -- 特别是在这个数据互联的时代，需要尽可能在低成本、短时间的前提下从海量数据中挖掘出关联最深，价值最大的信息，图就是非常理想的解决方案。除此以外，我们很难从其他种类的NoSQL模型、大数据框架或关系型数据库中找到隐式数据关联的解决办法。

随着算力的提升和大数据生态的日渐成熟，我们的目标正在从存储系统的效率转变为从存储系统包含的数据中提取价值。图数据库需要与图计算系统、图AI系统，乃至流图系统紧密地联动起来，才能让图数据的价值在用户手中得到充分的释放。而如何打造一套可以让不同目标的图系统都集成到一起，提供统一DDL并简单易用的graph infrastructure呢？我们能看到各个厂商和初创公司正在给出自己的答案...

相关文章