Neptune 图形数据模型 - Amazon Neptune
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Neptune 图形数据模型

Amazon Neptune 图形数据的基本单位是一个四个位置的(四元组)元素,类似于资源描述框架 (RDF) 四元组。以下是 Neptune 四元组的四个位置:

  • subject    (S)

  • predicate  (P)

  • object     (O)

  • graph      (G)

每个四元组都是一个语句,对一个或多个资源进行断言。一个语句可以断言两个资源之间是否存在关系,或者可以将一个属性(键/值对)附加到某个资源。您可以将四元组谓词值通常视为语句的动词。它描述了正在定义的关系或属性的类型。对象是关系的目标,或者是属性的值。示例如下:

  • 可以通过将源顶点标识符存储在 S 位置、将目标顶点标识符存储在 O 位置并将边缘标签存储在 P 位置来表示两个顶点之间的关系。

  • 可以通过将元素标识符存储在 S 位置、将属性键存储在 P 位置并将属性值存储在 O 位置来表示属性。

图形位置 G 在不同堆栈中的使用方式不同。对于 Neptune 中的 RDF 数据,G位置包含命名图标识符. 对于 Gremlin 中的属性图形,它用于有边缘时存储边缘 ID 值。在所有其他情况下,它默认为固定值。

四元组语句中面向用户的值通常单独存储在字典索引中,其中引用它们的语句索引使用 8 字节的 long 词条标识符。这一情况的例外是数值,包括 datedatetime 值(采用从纪元开始的毫秒值表示)。这些可以直接在语句索引中内联存储。

一组共享资源标识符的四元组语句创建一个图形。

如何将语句编制 Neptune 中的索引

当您查询四元组的图形时,对于每个四元组位置,您可以指定一个值约束,也可以不指定。查询将返回与您指定的值约束相匹配的所有四元组。

Neptune 使用索引来解析查询。正如 Andreas Harth 和 Stefan Decker 在其 2005 年的论文针对从 Web 查询 RDF 优化索引结构中观察到的,对于 4 个四元组位置,有 16(2 的 4 次方)种可能的访问模式。您可以有效地查询所有 16 种模式,而无需使用 6 个四元组语句索引进行扫描和筛选。每个四元组语句索引都使用一个由以不同顺序连接的四个位置值组成的键。

Access Pattern Index key order ---------------------------------------------------- --------------- 1. ???? (No constraints; returns every quad) SPOG 2. SPOG (Every position is constrained) SPOG 3. SPO? (S, P, and O are constrained; G is not) SPOG 4. SP?? (S and P are constrained; O and G are not) SPOG 5. S??? (S is constrained; P, O, and G are not) SPOG 6. ?POG (P, O, and G are constrained; S is not) POGS 7. ?PO? (P and O are constrained; S and G are not) POGS 8. ?P?? (P is constrained; S, O, and G are not) POGS 9. ?P?G (P and G are constrained; S and O are not) GPSO 10. SP?G (S, P, and G are constrained; O is not) GPSO 11. S??G (S and G are constrained; P and O are not) GPSO 12. ???G (G is constrained; S, P, and O are not) GPSO 13. S?OG (S, O, and G are constrained; P is not) OGSP 14. ??OG (O and G are constrained; S and P are not) OGSP 15. ??O? (O is constrained; S, P, and G are not) OGSP 16. S?O? (S and O are constrained; P and G are not) OSGP

默认情况下,Neptune 仅创建并维护这六个索引中的三个:

  • SPOG –   使用 Subject + Predicate + Object + Graph 组成的密钥。

  • POGS –   使用 Predicate + Object + Graph + Subject 组成的密钥。

  • GPSO –   使用 Graph + Predicate + Subject + Object 组成的密钥。

这三个索引处理许多最常见的访问模式。仅维护三个完整语句索引而不是六个会显著减少支持无需扫描和筛选的快速访问所需的资源。例如,只要绑定了位置的前缀(例如顶点或顶点和属性标识符),SPOG 索引就允许高效查找。当仅绑定了存储在 P 位置中的边缘或属性标签时,POGS 索引才允许高效访问。

用于查找语句的低级别 API 获取语句模式,此时部分位置已知,而其余位置留下由索引搜索来发现。通过根据语句索引之一的索引键顺序,将已知位置复合到键前缀,Neptune 执行范围扫描来检索与已知位置匹配的所有属性。

但是,Neptune 所做的其中一项声明指数默认情况下创建是反向遍历OSGPindex,它可以在对象和主题之间收集谓词。相反,默认情况下,Neptune 在用于执行联合扫描的单独索引中跟踪不同谓词。{all P x POGS}. 当您使用 Gremlin 时,谓词对应于属性或边缘标签。

如果图形中的不同谓词数太大,默认 Neptune 访问策略可能会效率低下。例如在 Gremlin 中,没有给出边缘标签的 in() 步骤或内部使用 in() 的任何步骤(例如 both()drop())可能会效率非常低下。

使用实验室模式启用 OSGP 索引创建

如果您的数据模型创建了大量不同的谓语,则可能会遇到性能下降和运营成本较高的问题,在使用实验室模式下,从而显著改进这些问题。OSPG 索引此外,Neptune 默认维护的三个指数。

注意

从以下功能开始可用。Neptune 引擎版本 1.0.0.0.200463.0.

启用 OSPG 指数可能有一些缺点:

  • 插入速率最多可能会降低 23%。

  • 使用的存储最多会增加 20%。

  • 均匀接触所有索引的读取查询(这是非常少有的情况)的延迟可能会增加。

但是,一般来说,为具有大量不同谓词的数据库集群启用 OSGP 索引是值得的。基于对象的搜索(例如,查找指向某个顶点的所有传入边缘,或者连接到指定对象的所有主题)将变得高效,因此删除顶点的效率也会更高。

重要

您只能首先在空数据库集群中启用 OSGP 索引,然后再将任何数据加载到其中。

 

Neptune 数据模型中的 Gremlin 声明

Gremlin 属性图数据在 SPOG 模型中使用三类语句表示,即:

有关 Gremlin 查询中如何使用这些信息的解释,请参阅了解 Gremlin 查询在 Neptune 中的工作原理.