实验案例由 Luca Sinico (InfoCamere 软件开发人员) 负责编写 

实验概述

InfoCamere 于二零一六年下半年展开图形数据库领域的检验工作，工作的目的是对该技术的主要特性进行调查; 在概念和性能方面比较市场上的一些可用产品以及关系解决方案;并检查一些InfoCamere应用程序的图形数据库的采用可能性。这项工作是基于意大利企业注册摘要获得的数据集，并包含有关企业参股的数据。图的节点可以是自然人或公司，并且收集关于面额，公司的股本，注册国家，唯一的财政标识符等的数据。图的边缘代表其中的股权参与。

在我们的工作中，我们检查了两种主要类型的图形数据模型，即“属性图”和“RDF”。尽管RDF（W3C标准）代表了实现链接数据和语义Web的有效方法，尽管它以图形的形式组织数据，但是我们发现属性图模型（一种“行业标准”）能更好地满足我们的要求。实际上，它允许在边上定义属性。而RDF不允许直接使用它。另外，针对RDF（SPARQL）提出的标准查询语言对于通常由支持“属性图”模型的DBMS提供的查询语言显示出一些限制。两个简单的例子是缺少最短路径计算函数，并且可能为可变长度路径搜索表示最大深度级别。

数据进入图形数据库的流程如图2所示。从存储意大利商业注册的复杂关系数据库开始，通过用户需求或更新操作不断产生一些标题搜索。标题搜索保存通过组合不同表中的不同记录获得的汇总数据，这对于某些应用是有用的。正因为如此，这些数据放在关系数据库上以支持其操作。由于这个第二关系数据库主要集中在与公司参股相关的方面，图形数据库从中获取数据。

查询

我们开发的查询可以被这些数据集上的应用程序所使用，也可以稍微强调数据库管理系统的能力。特别是我们开发了一些标准查询和一些更具体的查询。
鉴于一个特定的公司，由其“财政ID”确定，我们要求其员工;它的参与;或两者同时;从而通过将搜索限制到仅一个深度级别。但是，我们也要求直接和间接参与一家公司（同样也是为了同事）。这对应于没有深度限制的图的探索。此外，由于数据集构成一个图（而不是“简单”树），两家公司之间的路径可能是多个。这使我们要求提供连接两家公司的完整的直接路径列表;或者，也可以是最短的一个。我们还要求两家公司的共同参与（或同事）。数据集的图形性质也导致了另外两个查询的制定：第一个返回与检索到的参与节点一起, 并且检索到的深度值降低; 第二个查询计算每个深度级别的与给定节点的关联公司，但是避免对它们进行多次计数。
查询的开发有助于调查目的和更好的数据探索体验。

图形数据库与关系数据库的比较

我们将数据集导入了三个最知名的图形数据库，分别是ArangoDB v3.0.10; Neo4j v3.0.6;和OrientDB v2.2.11（均为社区版）。我们还将数据集导入了一个众所周知的关系数据库：PostgreSQL v9.6.1。关系型数据库的选择没有强烈的约束，因为性能主要受SQL语言性能的影响。这些产品已经安装在虚拟服务器上，资源适中，因此对于其他类似硬件可用性的公司来说，结果也是有用的。对于每一种查询，我们选择了三个代表三种不同负载的DBMS的三个节点。特别是：一个节点表示一个轻量级的案例，可能较少的返回的结果，或者较短的勘探深度值; 一个节点代表中间的案例; 还有一个重量级的案例。我们不止一次地执行了这些查询，所以我们也研究了延迟加载的缓存之间的性能差异。

由于目前还没有图形数据库的标准查询语言，因此每个图形DBMS都提供自己的查询语言。这促使我们评估各种查询语言的表达性和易用性。

结果

我们收集的结果概括如下：

• 图表数据库提供了一些特意设计的查询语言，这些语言大大有助于描述图遍历查询，也有助于应对该领域的一些典型计算问题。使用SQL或借助存储过程，相同的查询很难以高效的方式实现。
• 虽然关系数据库对较简单的查询执行得很好，但对于图挖掘查询的重量级案例（即那些有大量待分析节点的数据，并需要遍历的高水平的值），分析显示三个图数据库的性能通常要比关系型数据库高出一个或两个数量级。
• ArangoDB显示了良好的导入和查询性能，尤其适用于轻量级和中等工作负载的情况。
• 关于ArangoDB 测试版本的关注点之一就是内存占用 RAM greedy。然而，ArangoDB声称已经用他们新的3.2版本和新的RocksDB存储引擎解决了这个“问题”。

实验结论

由于在研究工作中得到了良好的反馈，在导入和执行时间方面表现良好，文档良好，易于使用和商业价格合理，ArangoDB 在InfoCamere 的一些应用程序中表现出了很好的潜力。最终，我们决定在我们正在开发的演示应用程序中使用ArangoDB。

关于比较实验的一些额外细节可以在这里找到。

英文原文链接