知识图谱如何实现万亿边规模并节省98%成本？（附Stardog基准测试）

我们的最新基准测试报告——《万亿边知识图》，首次展示了一个由物化数据和跨越混合多云数据源的虚拟图构成的大规模知识图。我们证明，构建一个拥有1万亿条边的知识图是可行的——作为对比，这相当于谷歌知识图（5000亿三元组）规模的两倍——并且能够实现亚秒级的查询响应时间，同时使用的分布式基础设施相比将所有数据存储在单一位置的传统方法，可节省高达98%的成本。这有望开启数据管理的新纪元，使知识图成为驱动企业盈利和竞争优势的核心数据基础设施组件。

我们的最新基准测试报告——《万亿边知识图》，首次展示了一个由物化数据和跨越混合多云数据源的虚拟图构成的大规模知识图。我们证明，构建一个拥有1万亿条边的知识图是可行的——作为对比，这相当于谷歌知识图（5000亿三元组）规模的两倍——并且能够实现亚秒级的查询响应时间，同时使用的分布式基础设施相比将所有数据存储在单一位置的传统方法，可节省高达98%的成本。这有望开启数据管理的新纪元，使知识图成为驱动企业盈利和竞争优势的核心数据基础设施组件。

在现代典型企业中，数据环境由分布在众多供应商处的本地和云端数据源组合而成。虽然这为企业带来了运营和商业利益，但也增加了统一数据和从数据资产中获取洞察的复杂性。Stardog的企业知识图平台通过基于数据含义（而非简单的物理共置）来连接数据，从而解决了这一问题。我们使用虚拟图连接到数据原位，而无需将所有数据摄取到单一来源中。

在现代典型企业中，数据环境由分布在众多供应商处的本地和云端数据源组合而成。虽然这为企业带来了运营和商业利益，但也增加了统一数据和从数据资产中获取洞察的复杂性。Stardog的企业知识图平台通过基于数据含义（而非简单的物理共置）来连接数据，从而解决了这一问题。我们使用虚拟图连接到数据原位，而无需将所有数据摄取到单一来源中。

关于这种方法，我们常听到的一个担忧是虚拟化数据的延迟问题。人们担心虚拟化源会导致性能不佳。本次基准测试证明，使用虚拟化源不会导致性能下降，Stardog知识图能够提供与使用完全物化数据的图数据库相一致的亚秒级查询时间。即使在如此巨大的规模下也是如此——并且Stardog还通过减少所需使用的服务器数量，带来了显著降低运营成本的额外优势。

关于这种方法，我们常听到的一个担忧是虚拟化数据的延迟问题。人们担心虚拟化源会导致性能不佳。本次基准测试证明，使用虚拟化源不会导致性能下降，Stardog知识图能够提供与使用完全物化数据的图数据库相一致的亚秒级查询时间。即使在如此巨大的规模下也是如此——并且Stardog还通过减少所需使用的服务器数量，带来了显著降低运营成本的额外优势。

下文您将看到我们基准测试中一些关键发现的预览。要阅读完整报告，请点击此处！

下文您将看到我们基准测试中一些关键发现的预览。要阅读完整报告，请点击此处！

可扩展至1万亿三元组

本次演示的目的是创建一个拥有1万亿条边的单一统一知识图，并对其运行结构化的图查询。实际上，数据分布在多个异构数据源中，这反映了大企业的常见情况。为了匹配企业的分布式特性，我们创建了一个环境，将我们的1万亿边图分布在三个系统中：Stardog、AWS中的Amazon Redshift以及Azure中的SQL Server（见下图）。Stardog通过根据需要访问Redshift和SQL Server来执行SPARQL图查询，并向最终用户隐藏了数据分布的复杂性。

本次演示的目的是创建一个拥有1万亿条边的单一统一知识图，并对其运行结构化的图查询。实际上，数据分布在多个异构数据源中，这反映了大企业的常见情况。为了匹配企业的分布式特性，我们创建了一个环境，将我们的1万亿边图分布在三个系统中：Stardog、AWS中的Amazon Redshift以及Azure中的SQL Server（见下图）。Stardog通过根据需要访问Redshift和SQL Server来执行SPARQL图查询，并向最终用户隐藏了数据分布的复杂性。

为了展示Stardog系统的可扩展性，我们选择了柏林SPARQL基准测试，该基准通常用于衡量支持SPARQL查询应答的系统的性能。该基准套件围绕一个电子商务用例构建，其中一组产品由不同供应商提供，不同消费者发布了关于产品的评论。

为了展示Stardog系统的可扩展性，我们选择了柏林SPARQL基准测试，该基准通常用于衡量支持SPARQL查询应答的系统的性能。该基准套件围绕一个电子商务用例构建，其中一组产品由不同供应商提供，不同消费者发布了关于产品的评论。

BSBM数据集包含八个主要类（表），并且可以在不同规模下生成数据。数据以产品为导向，包含产品、产品特性、提供报价的供应商、评论等信息。

BSBM数据集包含八个主要类（表），并且可以在不同规模下生成数据。数据以产品为导向，包含产品、产品特性、提供报价的供应商、评论等信息。

通常，所有数据都会被加载到单一的存储系统中，但我们将数据分区为三部分，并分别加载到Stardog、AWS中的Amazon Redshift以及Azure中的SQL Server中。Stardog支持超过100种不同数据存储的连接器。此基准测试环境对应了企业可能为知识图存储数据的方式：一部分在图数据库中，其余部分在两个云提供商的两个常见数据库中。

通常，所有数据都会被加载到单一的存储系统中，但我们将数据分区为三部分，并分别加载到Stardog、AWS中的Amazon Redshift以及Azure中的SQL Server中。Stardog支持超过100种不同数据存储的连接器。此基准测试环境对应了企业可能为知识图存储数据的方式：一部分在图数据库中，其余部分在两个云提供商的两个常见数据库中。

BSBM数据集同时提供RDF图版本和关系型版本。我们使用RDF表示法在Stardog中物化图数据，并使用关系型版本将数据加载到Redshift和SQL Server中。然后，我们使用Stardog映射语法在Stardog中定义了虚拟图功能，将关系型数据源映射为RDF格式。因此，数据无需从关系型源移动到Stardog中，但Stardog可以响应用户提交的SPARQL查询，自动将全部或部分查询转换为针对外部数据源的SQL。

BSBM数据集同时提供RDF图版本和关系型版本。我们使用RDF表示法在Stardog中物化图数据，并使用关系型版本将数据加载到Redshift和SQL Server中。然后，我们使用Stardog映射语法在Stardog中定义了虚拟图功能，将关系型数据源映射为RDF格式。因此，数据无需从关系型源移动到Stardog中，但Stardog可以响应用户提交的SPARQL查询，自动将全部或部分查询转换为针对外部数据源的SQL。

分布在三个数据源上的数据规模如下表所示：

分布在三个数据源上的数据规模如下表所示：

在分布式真实世界数据上表现卓越

下表显示了每个查询的平均执行时间。在运行实际测试之前，我们运行了500次随机查询组合的迭代，以预热系统和缓存。然后，我们在无缓存的情况下执行了20个查询组合（每个组合包含25个随机查询实例），以计算每个查询的平均执行时间。所有查询的平均执行时间（除一个外）均在一秒以内。低于一秒的平均查询执行时间表明，在此规模下性能不是问题。

下表显示了每个查询的平均执行时间。在运行实际测试之前，我们运行了500次随机查询组合的迭代，以预热系统和缓存。然后，我们在无缓存的情况下执行了20个查询组合（每个组合包含25个随机查询实例），以计算每个查询的平均执行时间。所有查询的平均执行时间（除一个外）均在一秒以内。低于一秒的平均查询执行时间表明，在此规模下性能不是问题。

我们的成果首次展示了在1万亿边规模下的分布式知识图实现。典型的图数据库基准测试规模要小得多。已报道的Ontotext GraphDb（170亿边）、Neo4j（200亿边）和TigerGraph（670亿三元组）的最大基准测试规模要小一个数量级。

我们的成果首次展示了在1万亿边规模下的分布式知识图实现。典型的图数据库基准测试规模要小得多。已报道的Ontotext GraphDb（170亿边）、Neo4j（200亿边）和TigerGraph（670亿三元组）的最大基准测试规模要小一个数量级。

一些基于RDF的系统已经发布了针对1万亿三元组图的基准测试结果，例如Cambridge Semantics、Oracle和Cray。我们在此取得的结果与其他厂商发布的结果存在一些关键差异。

一些基于RDF的系统已经发布了针对1万亿三元组图的基准测试结果，例如Cambridge Semantics、Oracle和Cray。我们在此取得的结果与其他厂商发布的结果存在一些关键差异。

在所有先前的基准测试结果中，所有数据都被加载到单一位置。将所有数据复制到单一数据库的方法实际上与数据仓库没有区别。相比之下，我们的设置查询数据时，数据存储在其设计存放的位置，无需创建新的副本，这使得数据沿袭和可追溯性变得直接明了，同时也加快了客户获得洞察的时间。

在所有先前的基准测试结果中，所有数据都被加载到单一位置。将所有数据复制到单一数据库的方法实际上与数据仓库没有区别。相比之下，我们的设置查询数据时，数据存储在其设计存放的位置，无需创建新的副本，这使得数据沿袭和可追溯性变得直接明了，同时也加快了客户获得洞察的时间。

上述提到的所有基准测试都使用莱海大学基准测试。LUBM基准测试中有14个固定查询。在基准测试期间，完全相同的查询会执行多次，这使得缓存结果变得容易得多。相比之下，在BSBM中，由于每个查询组合都是完全随机的，没有查询被执行超过一次。这更好地模拟了企业工作负载。

上述提到的所有基准测试都使用莱海大学基准测试。LUBM基准测试中有14个固定查询。在基准测试期间，完全相同的查询会执行多次，这使得缓存结果变得容易得多。相比之下，在BSBM中，由于每个查询组合都是完全随机的，没有查询被执行超过一次。这更好地模拟了企业工作负载。

成本效益提升98%

所有先前的基准测试结果都利用了非常大量的服务器来实现万亿三元组的规模。例如，Cambridge Semantics的基准测试使用了Google计算平台中一个由200台n1-highmem-32类型服务器实例组成的集群。每台服务器拥有208GB内存和32个vCPU，对应16个硬件核心上的32个Intel超线程。在撰写本文时，n1系列计算引擎的成本为$0.031611/vCPU-小时。因此，Cambridge Semantics集群的成本为$202/小时。

所有先前的基准测试结果都利用了非常大量的服务器来实现万亿三元组的规模。例如，Cambridge Semantics的基准测试使用了Google计算平台中一个由200台n1-highmem-32类型服务器实例组成的集群。每台服务器拥有208GB内存和32个vCPU，对应16个硬件核心上的32个Intel超线程。在撰写本文时，n1系列计算引擎的成本为$0.031611/vCPU-小时。因此，Cambridge Semantics集群的成本为$202/小时。

相比之下，我们使用了一台拥有192GB内存的Stardog服务器来加载数据，并切换到一台拥有976GB内存的机器进行查询。我们用于Stardog的服务器成本为$6.60/小时，而AnzoGraph集群的成本为$378/小时。即使将Redshift和SQL Server的成本考虑在内（额外约$2/小时），我们的分布式设置的运营成本也比AnzoGraph设置低一个数量级（98%）。当然，这还低估了运营单台服务器与运营200节点集群在开发运维和其他支持人员方面的持续运营成本差异。

相比之下，我们使用了一台拥有192GB内存的Stardog服务器来加载数据，并切换到一台拥有976GB内存的机器进行查询。我们用于Stardog的服务器成本为$6.60/小时，而AnzoGraph集群的成本为$378/小时。即使将Redshift和SQL Server的成本考虑在内（额外约$2/小时），我们的分布式设置的运营成本也比AnzoGraph设置低一个数量级（98%）。当然，这还低估了运营单台服务器与运营200节点集群在开发运维和其他支持人员方面的持续运营成本差异。

阅读完整报告

以上只是本基准测试报告内容的预览。查看完整报告以了解我们所有的发现：万亿边知识图。

以上只是本基准测试报告内容的预览。查看完整报告以了解我们所有的发现：万亿边知识图。

---

标签:

• 云
• 虚拟图

常见问题（FAQ）

知识图谱达到1万亿边规模时，查询性能如何？

Stardog基准测试证明，在1万亿边知识图谱上可实现亚秒级查询响应时间，即使数据分布在混合多云环境中。

虚拟图技术会影响知识图谱的查询速度吗？

不会。测试表明使用虚拟化源不会导致性能下降，Stardog能提供与完全物化数据相一致的亚秒级查询性能。

分布式知识图谱相比传统方法能节省多少成本？

通过分布式虚拟图架构，相比将所有数据存储在单一位置的传统方法，可节省高达98%的基础设施成本。