图数据库基础知识（上）

图数据库基础知识（上）

背景知识
图数据库的介绍

图数据库的 特点

图数据库应用场景

图数据库的术语

一.图数据库的介绍

图数据库（英文：Graph Database）在传统意义上被归类为NoSQL（Not OnlySQL）数据库的一种，也就是说属于非关系型数据库，其它的非关系型数据库在广义上还包含例如，键值数据库、文档数据库、列数据库、时序数据库等。

从数据科技（DT）、数据处理技术发展的趋势来看，过去的40年间，我们经历了从Data到Big Data 到Fast Data到Deep Data的四个阶段。1980-2010年间的关系型数据库主导的阶段，2010-2020年间的大数据与快数据主导的云计算&大数据时代，而未来的10年（2020-2030）则可以预见的被认为是图计算、图数据库的时代。这是由商业驱动的本质来决定的，当企业IT信息化已经基本完成后，再向前就是企业的全面智能化，而智能化时代的核心技术就是可以处理高维数据关联关系的图数据库或图计算与存储引擎，低维的SQL类型的数据库注定会逐步消亡。

知名信息咨询公司Gartner在2019年11月和2020年6月的两份关于数据与分析科技（Data & Analytics Technology Trends）的报告中，明确的提出了图分析（Graph Analytics，如下图所示）作为10大核心科技发展趋势之一，且其所代表的细分市场以年复合增长率100%的速度持续增长，预计到2023年，30%的BI（商务智能、商业决策）会通过图分析与计算（既图数据库系统）来完成。

二. 图数据库特点

    图数据库的的所有特点都是相对于传统数据库而言的，尤其是关系型数据库。简单而言，图数据库的最大特点有3个：

1.高维

2.高性能

3.高效率

相比于传统的关系型数据库中的关系表（二维表），图数据库采用的是可描述复杂关联关系的高维拓扑结构，既图论的理念，这也是图数据库（Graph Database）名字的源头。高维的数据关联关系并不意味着性能降低、效率降低，恰恰相反，图数据库中的高维关系的构建只依赖两大类最基础的数据类型：顶点与边，我们也通常称作实体与关系。用图数据库可以简单、高效、自由，并且非常自然的表达真实世界中的关联关系。这种100%还原世界的能力，让图数据库比关系型数据库或其它类型的数据库或大数据处理框架可以更加快速、深度、准确的挖掘事物间的关联关系，很多时候这种效率与性能的提升是指数级的，成千上万倍或者更多（随着搜索深度的增加，相对的性能与效率的提升会呈现指数级的差异增大）。

三.图数据库应用场景

我们可以从狭义场景与广义场景两个维度来阐述图数据库的应用场景。

狭义场景如上图所示的部分商业场景，例如在泛金融行业中，可以归纳为开源vs.节流这两大类场景，也可以泛化到任何行业中的普适场景，一方面通过智能化营销的手段来获客（捕获新客户）或促活（促进客户活跃度，以实现更高的ARPU），另一方面通过智能化的节省开支或减少欺诈来实现更健康的企业运营。

在广义场景中，或者说图数据库的长期发展趋势中，它必将全面取代关系型数据库。当图数据库的高效、高能、高维被越来越多的商业场景所采用，越来越多的企业认识到通过它可以实现更好的ROI，更低的TCO后，以及在核心的场景中（例如金融交易）可被证明其效率与稳定性后，关系型数据库被取代只是个时间问题。在那之前，眼下我们看到越来越多的BI、商业决策、风控、知识图谱、可解释AI、区块链、供应链金融、产业互联网等场景中看到图数据库、实时图计算与分析的身影，这个趋势不可逆转。

四.图数据库术语

GQL

Graph Query Language，即图数据库的查询与管理语言。在SQL标准已经发展40年后才迎来了数据库领域的第二个标准，这就是GQL，预计GQL的第一版国际标准在2022年中发布。

点(node)

称之为顶点（Vertex）或点（node），也可以称作实体（Entity）。

边(edge)

连接两个点（node）的边，分为1)无方向，2)有方向（见下面"方向"的解释）。在知识图谱范畴内也常被称作关系（relation、relationship）。

路径(path)

多个相连的边（包括边连接的点）构成的一个序列称为一条路径，例如a–b--c，单独的一条边也是一个路径。

子图(subgraph)

子图相对于全图（完整图数据集合）而言，是由全图的部分顶点和边组成，例如每一次查询结果可以作为一张子图。

属性(property)

图系统中的数据属性，主要分为点属性（node property）和边属性( edge property)。

实例(instance)

实例通常指在图数据库的底层系统架构中的一个相对独立且完整的功能集合的实体，例如计算实例、存储实例、管理实例等。例如一个集群化部署的图数据库系统可能由3台实例构成，每台实例可以有各自的角色分配（管理、计算、存储、同步等等）。

Simple-Graph单边图
Multi-Graph多边图

在图中，任意两个顶点间只能存在一条边的情况在图论中的定义为单边图（simple-graph），可以存在多条边的情况为多边图（multi-graph）。要更自然的表达真实的世界，显然是需要多边图的。否则的话，就需要制造大量的实体和没有太多意义的关联边来构图，如下所示：单边图的构图会有数倍于多边图构图所消耗的顶点与边，并且效率低下！

图数据集(Graph Set)

一个图数据集，简称为图集，代表一个完整的由点和边构造的数据集，以及在此基础上的权限设置，算法结果等一系列内容。类似的概念有多图等。在一个图数据库中，可以存在有多张图或多个图数据集，正如关系型数据库中可以有多库概念。注：每一个图集或每张图相当于传统的关系型数据库中的多张表的融合，也是在这个维度上看图数据库是高维的。

过滤器(filter)

用于属性的过滤，在查询与计算中会被经常用到。

方向 (左)

表示边的方向，向左，即在图中的点的入方向，例如 a<–

方向 (右)

表示边的方向，向右，即在图中的点的出方向，例如 a–>

有向图

当图中的边有明确的方向时，且在图中的各类操作可以利用这种方向的时候，我们称其为有向图。例如，区块链就是典型的有向无环图，英文简称为DAG（Directed
Acyclic Graph）。以DAG的方式，可以追溯每一笔比特币的流向、分布、归属。

无向图

无向图指的是忽略了边的方向。在实际的图数据库实现中，通常都采用双向边存储的方式来实现无向图。

近邻查询

所谓近邻查询，指的是从任一图中的顶点出发，可以查询它的直接相连的邻居（1度邻居），或者是2度关联的邻居，并以此类推。例如图上的K-hop（K邻）操作，就是典型的近邻查询，当K=1，1-Hop就是查找某个顶点的全部1度邻居。

K-Hop（K邻）

K-hop是一种典型的近邻查询，它的标准定义是从当前顶点出发与之最短距离为K步（层）的所有顶点的集合。这个定义中最为关键的是“最短距离”，其次是顶点的集合应该是去重的，既不应重复、多次计算任何顶点。K代表一个较小的整数，通常在1-X之间，最小为1，最大几乎不会超过X=30，但是这个并非是绝对的上限。例如在中国工商数据中，有一些大型集团的投资关系的网络可以触达30层以外。这对于系统进行深度的近邻查询是极大的算力挑战。

路径查询

所谓路径查询就是在图中查找两个（或多个）顶点之间的，符合过滤条件的，相关联的路径。复杂的路径查询有多个节点组网操作，它在本质上是多对节点间的两两的路径查询。

广度优先搜索（BFS）

在图论中，BFS指的是从某个顶点出发，由浅及深的遍历、搜寻相邻顶点的方式。它必须先把前一层的邻居都遍历完毕后，才可以遍历之后一层的邻居。例如图上的的K邻查询就是典型的BFS操作（如下图所示）。

深度优先搜索（DFS）

相对于BFS的横向（广度）优先搜索而言，DFS则是纵向（深度）优先搜索，它会从当前顶点出发先深度的探索，在到达最大限定的搜索深度后或当前路径上无路可寻时折返回到上一层继续搜索，直到找到符合搜索终止条件的点、边结束，或遍历完全图而结束。

最短路径

在无权重（过滤条件）的情况下，最短路径是图中两点间的通过BFS方式所找到的最短相关联的路径。采用DFS的方式进行最短路径计算通常是错误的，或者说，需要比较路径的结果长度（所谓长度的最小单位指的是通过一条边关联的两个顶点，它们之间的距离或长度为1步或1度），最短的那些路径才可以算作最短路径。因此，BFS作为最短路径的查询模式通常是更高效的。

带权重最短路径

如果把路径上的点或边的属性（例如权重）累加进行计算来决定图上2点间的最短路径，搜索的逻辑就会更为复杂，特别是在权重可以为负数的情况下，那么就需要遍历全部联通的子图才可能确定哪一条路径是最短的权重路径。

全部路径

全部路径通常指的是两点间的所有可能存在的路径。在实际的商业场景（相对有纯学术场景而言）中，通常会限定某个搜索深度或最大搜索深度，例如3度以内的全部路径或正好3度的全部路径，并且附加路径过滤条件，而极少会进行暴力的全部路径搜索。不同的图系统可能会采取BFS或DFS的模式来实现这一路径搜索需求。

带属性路径搜索

在商业化的图路径搜索查询中，通常都带有顶点或边的属性参与计算。例如寻找从账户A出发到账户B之间的转账关联关系路径，途径所有账户节点的当前余额要大于10000。

时序路径

时序路径是一种典型的带有属性的路径搜索。例如在银行的转账数据所形成的图数据集中，从账户A出发到账户B截止，找到深度为5度的转账路径，其中经过的每一对账户间的转账时间沿路径呈升序排列。

图算法

图算法指的是因需要对图上的部分或全部的数据进行批量处理而所需实现的计算逻辑，例如度算法、中心度算法、排序算法、传播类算法、相似度算法、聚类算法、社区识算法、图嵌入算法、随机游走算法等等。图算法的计算量通常会和图的数据量以及拓扑结构相关，通常意义上，越大的图，计算复杂度度越高，拓扑结构约复杂的图，图计算的复杂度越大。传统意义上的图算法的时耗通常在T+1甚至更久。但是，在成本可控的条件下，可以实现T+0或准实时、实时计算显然是具有重大意义的。

另：值得指出的是，BFS/DFS并不是图算法，它们是图上的搜索模式，也更为基础，可以说图上的所有查询与计算的基础都可能会是BFS或DFS的方式。

实时图算法

通过对数据结构、存储结构和系统架构的优化与调整，在获得指数级的性能提升后，有一些图算法即便在大图上也是可以完全实现纯实时计算的。例如面向单个或部分顶点的出入度计算、相似度计算算法等。

OLAP

OnLine Analytical Processing既在线分析处理，通常OLAP因经常面向全量数据，计算量巨大而导致时延较长，因此很多人把OLAP等同于高延时批处理+静态数据处理。尽管，这么理解并不准确。在批处理时延中，T+1时延指的就是OLAP系统需要连夜运行到第二天才能结束。而T+0通常指的是当天（小时级时延）可以分析、运算完毕。

OLTP

Online Transactional Processing既在线事物（交易）处理。OLTP相对于OLAP系统有两点不同。1. 低时延，OLTP系统通常是实时性的，例如典型的交易处理系统要求低时延、高并发；2.数据一致性，交易处理系统尤其会强调对于系统的数据一致性要求，特别是当系统有高并发的读写，例如增删查改操作时的系统中的数据一致性要求。

HTAP

Hybrid Transactional & Analytical Processing指的是在一套系统内可以同时支持OLAP+OLTP，既同时支持这两类业务场景。通常是在一套分布式集群内不同的实例来支撑不同的OLAP或OLTP的需求。

图中台

图中台可以等同于图数据库或图计算+图存储平台。如果从技术栈的视角上看，图中台向下直接对接底层的操作系统与硬件平台，对上则直接服务应用层需求。中台这个概念最原始的定义=中间件，既数据库！中国互联网公司近年来所提出的数据中台的概念在本质上依然是面向业务的数据服务平台，相对于前台（例如Web前端）与后台（服务器端）而言，中间层、中间件即为中台。

图分析

Graph Analytics在本质上是对图数据进行处理与分析的各类行为的汇总，通常图分析与图计算这两个名词可以混用，但是有些场景下，分析被等同于OLAP，也就是说高延迟、静态数据，尽管这样理解并不准确。在高性能图系统中，图分析的很多操作可以是以纯实时的方式实现与完成的。

图计算

Graph Computing与Graph Analytics在业务层面看并没有本质区别，只是前者更关注于计算（算力）本身，而后者则更多的是从业务层去看图系统所完成的工作的归纳就是一系列的面向图中的数据的分析与处理。

图存储

所有图计算或图分析平台的底层一定用到了图存储的技术。区别在于有的是原生图存储，有的是非原生图存储。例如使用列数据库、键值数据库、文档数据库或关系型数据库来实现图存储就是非原生图存储。原生图存储通常会强调存储效率更高、原生化的支持图中高维的关联关系的表达与查询等。

原生图

Native Graph这个概念是相对于非原生图而言的。在上面的图存储中我们介绍了用传统数据库作为底层存储架构来实现的图计算、图分析就是典型的非原生图系统。原生图最核心的是底层的数据结构是可以天然的表达近邻存储的关系，既所有相连的顶点间的关系是以近邻、无索引的方式存储的，这种存储模式会带来几个显著的优点：1.最低延迟的访问，例如O(1)的近邻无索引访问时延；2. 潜在的最高并发支持，当近邻关系与顶点的集合可以被高度的并发访问时，在图上的深度查询、遍历等操作可以以递归的方式实现极低的延迟，进而实现整个系统级的低延迟、高并发特点。