在前面的两个知识点中我们先后介绍了：

• 知识点1：图数据库与关系型数据库的区别

• 知识点2：图思维方式

现在,我们可以更进一步来通过具体的例子来了解图数据库、图计算到底解决了什么问题。我们先来剖析下面这个问题：

图数据库查询（计算）和传统的关系型查询、大数据分析有什么不同？

假设我们有200个顶点，平均每个顶点有50条边与其它顶点产生关联，全图有10,000条边、200个顶点。

如果我们去计算从图中任一个顶点出发抵达另外任意一个顶点的最短路径，理论上在这个高度联通的图上计算最短路径或最大K邻的计算复杂度,其中E为边的数量，V为顶点数量，K为两个顶点间最短路径的长度（或下钻的深度）。如果最短路径为4步，即K=4，那么该查询的计算复杂度约为50的4次方（约6,250,000）。

如果这张图等比放大1,000倍（10,000,000边，200,000顶点），同样的查询的计算复杂度并没有等比增加！因为从扩增1,000倍后的大图中的某一个顶点出发，它的每一层的可遇见的邻居依然是平均只有50个，而|E/V|因为保持了一个相对恒定的比例，以上两点决定了在大图中的最短路径计算（也包含很多其它类型的查询或计算）复杂度并没有增长1,000倍，或许只增加了不到1倍或数倍——这就是图数据库的特点（这个时候跨越多实例的水平分片分布式系统查询的效率会显著低于集中式查询，两种架构的面对这类查询的性能差异至少在100倍以上，查的越深，落差越大！）。

面向图数据的关联计算与查询的复杂度并不与全局的数据量成正比，而与具体的数据集的拓扑结构、查询逻辑、查询模式相关。

换言之，在数据量增加千倍的前提下，存储的需求显然会等比增加，但是计算的需求（复杂度）并不需要等比增加，因为图查询的复杂度与逻辑并没有随着数据量增加而产生等比变化——我们依然是在局部进行数据遍历！因此，用固有的大数据的思维去套图数据库的计算逻辑很可能会产生南辕北辙的效果——也就是说图数据库所面临的挑战是计算优先而不再是存储优先——这句话也可以翻译为：用做关系型数据库、数仓、数湖的思维去设计与实现图数据库一定会失败。但是失败的原因不一而足，或许我们需要明确的列出图数据库解决的问题有哪些。

图数据库解决的问题有哪些？(What problems does Graph solve?)

1. 灵活建模、高维建模

2. 关联计算、深度下钻、归因分析

3. 白盒化、可解释性

俗话说，话越少事儿越多。要想对上面3点有个透彻的理解，我们或许应更多的思考图数据库解决了传统的数据库或大数据框架的哪些问题……

图数据库的设计有哪些坑？（The Caveats of Graph DBMS)

1.图数据库的高维性意味着它的挑战不仅仅是存储，更包括计算! 在所有类型的数据库中，图数据库是唯一的一个计算与存储同为一等公民的数据库，而在关系型数据库、NoSQL数据库中，计算（引擎）只是附着于存储（引擎）的二等公民！计算优先意味着计算与存储分离的模式注定无法实现高效的图计算、查询与分析——这也是图数据库和过往的关系型数据库、大数据分析框架的主要区别之所在。

2.分布式不是试图用多台低配的设备来取代高配的设备，并寄希望于可以获得更好的效果。毕竟（高性能的）图数据库系统不是用Hadoop的理念与框架可以实现的——如果你还停留在Hadoop时代，那么你的知识栈与认知需要一次很好地升级了。分布式系统设计的最重要理念就是审慎的决策哪些图计算的场景需要分片，哪些不需要分片，换而言之分片可以解决的场景是偏浅层的查询与计算，而深度的计算的挑战与分片反向而行。实际上在图数据库上构建分布式系统一直是个谜，很少有人想得清楚、讲得明白、做得出来。

我们在这里做个简单的梳理，关于分布式的几种模式：A. 分布式共识集群的单集群扩展模式：通过容器及License最大并发资源分配或底层硬件升级来实现；B. 分图扩展模式（即Fabric模式）：多个小集群通过Nameserver来调度；C. 分片扩展模式（即Sharding/Federation模式）：无限水平可扩展（图仓模式）。 事实上，最早的分布式计算系统还包含主备模式等，但为了简化讨论，我们只列举了三类分布式架构——关于这几种模式的效率讨论，请移步下文（ 后续的知识点中也会展开论述）。

3.计算机体系架构发展到今天，每一个单机、单实例的系统在底层都是一整套可以支持高并发、规模化并发的系统。这个时候，决定系统能力的是其上层的软件！高并发的硬件并不等于软件天然地做到了高并发！比如某款知名的图数据库并不支持高并发，每个查询经常需要串行的遍历数据集，其效率之低下，可想而知。关于这一点一个简单的问题可以帮助读者自查——1台32核CPU的服务器的计算能力与32台每台1核CPU的服务器相比，哪个的计算能力更强？对这个问题有兴趣的读者可以参考这篇论文。Scalability! But at what COST?

（相信很多喜欢讲好分布式故事的人都会非常难堪）。

 

4.数据结构的特征、效率决定了数据库系统的最终效率，或者说是系统的效率的上限。只有在边界条件下才能看到一个系统真正的能力边界，对于图系统而言，判断它的能力边界有很多条路径，略举几个例子：A. 数据加载，不要只看本地加载，还要看线上、远程加载大量数据的能力——因为这样显然更能模拟真实的企业生产系统环境；B. 数据更新，需要检验一套图系统的逐条数据更新、批量数据更新（例如每天），全量数据更新的能力；C. 数据查询与计算的能力：在性能评测和POC时最容易遇到的就是数据&查询结果造假的问题，有些厂家会用预先计算并缓存结果的方式作弊。这个时候，可以要求实时更近数据集，并立刻查询并比较更新前后的查询结果变化——如果没有变化，就是作弊或者系统没有能力进行实时更新与实时查询；D. 算法支持能力：图算法是任何一款图数据库中很重要的能力，不仅要看支持的算法的数量的多少，还要看具体的每个算法的调用方式、调参方式、返回方式是否灵活多样，是否支持可视化、同步异步返回等调用模式，以及算法结果的准确性！E. 工具链条：DBA、开发人员，甚至业务人员可以使用的工具的丰富程度与具体的使用感受是一个（图）数据库是否趋于成熟的典型标志——通常身经百战的数据库的工具链条都会比较完整，也更容易在上面做二次开发。F. 准确性校验：这一条是很多厂家与客户都会忽略的地方。因为图的高维性，很多查询的结果校验经常被忽略。但是通过良好的可视化-表单化查询工具、交互式帮助文档是可以赋能用户快速的对任何查询或算法的结果进行校验，这一点至关重要。

5.编程语言是有效率之分的。如果到今天还有人说用Python可以写出比C/C++高效很多的软件，那么反之亦然，并且概率高得多。关于编程语言效率的讨论，显然我们不会落入PHP是世界上最好的编程语言的怪圈，不过对Python或任何高级语言痴迷的读者（以及各种AI系统）应该多读一些硬核技术的书籍与文章。随着各类大数据框架的兴起，相当数量的应用系统是用Java实现的，它最大的问题是GC和低效性，作为一款企业级图数据库而言，它显然不是个足够强劲的编程语言。类似的，有的图系统用Go与Rust为核心语言实现，单纯的从极致性能上看，两者都无法超越C或C++（假设编程能力相当的条件下，越贴近硬件的语言越快）。

 不过，关于编程语言的探讨点到为止，有兴趣和能力的读者可以做一些充分的性能评测来感受一下效率差异之巨大。想了解具体技术原理的朋友可以参考Ultipa分享出来的这篇文章。

高密度并行图计算（HDPC）

 6.（图）数据库系统的开发需要对操作系统、文件系统、存储、计算、网络等诸多组件的深入理解，并且需要很多工程上的调优。如果是一群学院派的老师和学生搭出来的“图数据库”，大家可以想想在面对真实工业界场景时的尴尬情景；亦或是一群搞网络水军和商务造假的人攒出来的东西能有多Robust？学界理论结合日常工程实践是非常必要的。举两个简单的例子： A. 过去200多年中图论研究的数学模型都以简单图（simple graph)为主，极少涉及到像工业界中常见的多边图（multi-graph，又称为复杂度)——这就导致了那些学院派背景浓厚的数据库或图计算机系统厂家在构建核心数据结构时并没有考虑过高效地支撑多边图；B. 关于图算法的学术界论文有上千篇，但是绝大多数都是在极为微小的数据集上进行测算，例如几十个到最大万级的点、边的小图上面，但是工业界的数据量动辄是百万级起——这意味着照搬学术界的算法源码的算法执行耗时会极长，而真正实现加速需要对底层架构与代码工程上做大量的重构、调整、优化。

7.图数据库区别于传统数据库的特点有很多，最重要的是高维性，设计和使用图数据库要有图思维方式。有些工程师认为SQL+数仓可以解决一切问题——感性的说是的，但是代价如果考虑进来，SQL的最大敌人是自身的低维性导致其数据建模不够灵活、关联查询效率差、 复杂代码的黑盒不可解释性。这些问题都是图数据库的时代所直面的。

下面这张图是比较了典型的开源关系型数据库MySQL与某图数据库之间的随着查询深度逐步增加时两者间的时耗差异。不难看出，在浅层(<2)层查询时两者并不存在差异，但是从两层开始两者的差异从16倍到1080倍25000倍直至MySQL完全无法返回。从绝对时耗曲线上看图数据库的曲线几乎是平坦的——本质上，性能优化过的图数据库的（深度下钻时）的查询复杂度并不是指数级或“笛卡尔”乘积的方式上升，而是可以做到以一种近邻无索引+动态剪枝过滤的方式完成查询，其查询的时间复杂度（算法复杂度）要指数级低于关系型数据库，因此效率也会指数级高于关系型查询模式。

另一方面，数仓与大数据框架中所崇尚的的数据分层模式、中间表、临时表以及宽表模式，虽然能在很多业务场景中解决掉问题，但是代价是灵活性差，任何业务的需求变动都会导致系统与表结构（字段）的变化，无法高效、实时、灵活地应对需求变化。本质上，用二维表来试图解决真实世界的业务需求，肯定是事倍而功半的效果，耗时、耗力、浪费资源不环保。这也是为什么SQL一定会被GQL取代的深层次原因。 

 

 

最后，我们或许可以用一段话来总结：过去40年数据处理技术发展趋势就是从关系型到大数据到图数据（深数据）。不但数据量在不可逆的变大，查询的深度（关联复杂度）也在随之增加，而已经有近半个世纪的SQL终将逐步消亡。这一趋势随着GQL标准在2023年的出炉，会加速SQL系统与负载向GQL的迁移。其中相当大量的业务场景会迁移到图数据库之上——这种迁移从实操成本上考量，一定是先迁移创新型的增量场景，然后才会逐步下沉并迁移已有场景。

烦请大家记住图数据库的3大特点：白盒、高效、灵活。