图数据库 | 23、如何评测图系统 — 评测内容？

XAI嬴图

于 2025-02-26 18:33:54 发布

阅读量988

点赞数 7

文章标签：数据库图数据库图计算云原生

本文链接：https://blog.youkuaiyun.com/Ultipa/article/details/145845739

版权

“作为第三代人工智能代表的图系统的核心就是图增强智能、白盒化与可解释性，建模过程完全可以透明化。另外，图系统也不需要追求算法垄断，作为一种通用的底层系统，它向客户提供的应该是优越的算力、白盒化的算法，而不是黑盒化的模型和算法。”

图系统评测内容并没有所谓的标准答案，但是会有一些典型的测试内容及流程，本节主要向读者介绍这些内容与具体步骤，以供借鉴。

评测内容一般可分为9个部分：

构图（建模）能力；

数据的导入、导出能力；

元数据处理能力；

深度查询能力；

图算法能力；

二次开发支持；

可视化支持；

系统安全性；

运维支持能力。

关于构图能力，评测主要关注以下几点：

·图数据库建模能力、建模复杂度、灵活性等；

·建模是否能直观、便捷地反映业务需求；

·从数据源到按照建模的规则生成图数据的时耗、复杂度、资源消耗情况；

·是否支持可视化建模工具、可扩展性，是否支持多种建模方式等。

关于图系统建模有一点非常重要，很多人把建模的能力作为一种秘密武器，认为图的模型不应该公开，老夫认为这个思路非常不可取。

模型如果黑盒化、不透明、不可解释，最终伤害的一定是所有人，而且会重走基于深度学习、神经元网络的第二代人工智能系统的老路。

作为第三代人工智能代表的图系统的核心就是图增强智能、白盒化与可解释性，建模过程完全可以透明化。另外，图系统也不需要追求算法垄断，作为一种通用的底层系统，它向客户提供的应该是优越的算力、白盒化的算法，而不是黑盒化的模型和算法。

以行业数据应用为例，一种是固定模式构图，即需求方提出具体的构图方式，图系统来实现并满足；另一种是灵活构图，即客户描述业务场景，由图系统运维服务方来设计构图模式。下面分别看一下这两种模式的构图测试内容。

模式1：固定模式构图

以某交易数据集为例，如表1所示，构图需求非常明确，其中点、边数据都已经生成，可以直接通过被评测的图系统能否满足相应的构图需求，并比较多套系统最终实现的效果来进行评判打分。

和构图相关的评判细则，主要关注以下几点：

·是否100%与需求吻合；

·建模过程和步骤的简易程度（工具使用简单，步骤越少，速度越快得分越高）；

·源数据大小与入库后大小比较（数据膨胀系数、膨胀比率）；

·当前图系统是否提供其他有益的功能。

模式2：灵活构图

如果评测方不对具体的构图模式做出限定，而只是描述应用层的业务需求，那么任何图系统完全可以自由发挥。

尽管对于某一个具体的业务场景而言，一种构图方式可能会明显优于另一种构图，特别是从资源占用、时效性、系统稳定性维度来评测——一般称最优的那种构图方式为“最佳实践”（bestpractice）。很多时候，POC和评测的过程也是寻找最佳实践的过程。

在之前的文章中，老夫就介绍过灵活构图的可能性。需要指出的是，异构图与多边图的能力可以看作同构图与单边图的超集，前者可以向后兼容，而后者则没有办法向前兼容。

换句话说，支持异构、多边图的系统的“构图”能力是超越同构或单边图系统的。

表2列出了一种典型的异构数据构图需求，区别于表1中明确的点、边分配模式，表2只是在前置条件部分陈述了现有的源数据情况，以及预期结果和评测标准，具体的构图方式完全由图系统的架构师来决定。

虽然现在已经知道像这种类似于工商图谱的数据集应该用边来直观地表达每一笔投资（股权）的关系、转账关系、担保关系或供销关系，但是我们的确看到过有一些系统把交易通过顶点（以及看起来非常冗余的一对衔接边）来表达。

前者的优点在于直观、计算复杂度低，后者则需要更复杂的（低效）计算模式来完成类似的工作。

在图系统甚至任何数据库系统或大数据框架的体系架构迭代过程中，类似走弯路的例子比比皆是。

接下来需要评测系统的数据接入能力，通常评测如下几个方面：

·多源数据接入、多格式数据接入能力；

·海量数据的导入加载能力；

·数据输出能力。

表3将列出了一种典型的数据导入测试需求，表4则列出了较可能的数据输出评测需求。

在数据接入部分，还可能测试当前图系统的数据加载边界，即在当前软硬件条件下，探索系统可以存储及计算的最大数据量。

这样的测试并不常见，一般存在于内部测试中，对于图系统的开发者而言，需要以第一手的方式了解和评估自己构建的系统的存储容量与计算能力的上限。

需要指出的是，对于最大可加载数据的测试（表5），有几个要点需要关注：

·极限测试可以帮助发现当前系统的存储极限，并为架构优化提供思路，例如通过进行架构优化（特别是在分布式架构中对于分片逻辑、数据备份、日志、中间数据的优化）、数据结构的优化、数据压缩、缓存优化等，可以在同样的硬件条件下，更高效地存储更多数据，形成实际单位价格（平均价格）更低廉的图数据存储；

·海量数据的加载会暴露数据加载（入库）中存在的一些问题，例如并发规模不够、缓存查询效率快速变差，以及其他数据库设计缺陷——在小规模数据量级中可能无法发现类似问题；

·理论上，底层硬件的配置限定了实际可存储数据的最大数量，例如，每张1TB的硬盘实际可存储的数据不应超过50%，至少还要预留一定的存储空间给缓存数据、增量数据。

在极限测试中，各项指标都在承压，这时也是发现系统边界的最佳时刻，例如插入1亿点边的挑战和10亿、100亿的时候，会从量变产生质变，承压后的系统也可能会发生各种类似于OOM（内存溢出）等导致系统快速宕机的问题，而这也是设计和开发任何具备高稳定性的系统必须经过的磨炼。

元数据处理类操作是图系统中最基础的操作，主要集中在对点、边及其属性的增、删、改、查等操作。

区别与传统数据库系统，图系统中也会面向点的出入度作为变量进行计算，例如查询到全图中所有度在某个区间的顶点并进行增、删、改等操作。

表6中的测试内容围绕批量处理元数据展开，可视作对日常业务场景的一种有效模拟。

深度查询是图系统最具特色，也是其区别于其他全部数据库系统和大数据框架最主要的地方。

相关查询操作的评测在不同的领域有不同的着眼点，例如在GAP测试中把所有的查询都以图算法的方式呈现，包括广度优先查询也被视作一种算法。

本文深度查询分为如下几类进行更有针对性的评测，而图算法相关的评测作为相对独立的一大类单列。深度查询评测场景分类如下：

1）K邻查询（统计K度邻居）。

2）路径查询，分为广度优先查询、询深度优先查询、环路查询、组网查询。其中广度优先查询又分为最短路径查询、全路径查询和展开查询。

3）模板查询，分为模板K邻和模板路径。

4）更为复杂的组合查询，分为基于全文搜索的路径或K邻查询、多点到多点复杂路径查询等。

以上各类场景的划分并非严格按照某种非此即彼的关系，任何一种评测因为时间和投入成本等限制都无法覆盖全部的场景，但是可以有代表性地说明图系统可以完成的很多复杂工作的程度。

表7～表7-12分别列出了如下几类典型深度查询的测试场景与需求。

·多度邻居查询（BFS搜索），见下表7。

·广度优先查询（BFS），见下表8。

·最短路径查询（BFS），见下表9。

·深度优先路径查询（DFS搜索），见下表10。

·复杂组合查询（深度链路查询），见下表11。

·环路查询（DFS），见下表12。

图系统对于二次开发的支持也是非常重要的一种能力，例如可编程接口（API/SDK）的支持能力，自定义模型开发支持、定制化算法支持等。表13列出了一种典型的简单客制化（也就是自定义）模型开发能力的测试需求。

图算法是图系统评测中占比仅次于深度查询的一类。目前已知的全球范围内的图系统生产厂家、第三方评测机构和企业级客户对于图算法相关的评测内容主要分为如下几类：

1）自评、学术界、第三方机构：BFS（广度优先算法）、CC（联通分量算法）、PR（网页排序算法）、BC（中介中心性）、TC（三角形计算）、SSSP（单源最短路径）和LPA（经典标签传播算法）。

2）工业界（区别于以上算法）：全图出入度计算、相似度算法、增强LPA、鲁汶社区算法、随机游走及图嵌入算法、变量计算。老夫在《图数据库原理、架构与应用》的第4章中，详细介绍过每一类图算法的逻辑和应用场景，这里以GAP测试标准、增强LPA（表14）及Node2Vec（表15）算法为例来介绍图算法评测的一些要点。