Neptune 图形数据模型 - Amazon Neptune
字典索引策略Gremlin 数据模型
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

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 值。在所有其他情况下，它默认为固定值。

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

面向用户的值的字典

Neptune 不会将大多数面向用户的值直接存储在其维护的各种索引中。相反，它将这些值分别存储在字典中，并在索引中用 8 字节的标识符替换它们。

  • 所有会进入 S、P 或 G 索引的面向用户的值都以这种方式存储在字典中。

  • 在 O 索引中，数值直接存储在索引中（内联）。这包括 date 和 datetime 值（以从纪元开始的毫秒数表示）。

  • 进入 O 索引中的所有其它面向用户的值都存储在字典中，并在索引中用 ID 表示。

字典包含面向用户的值与 value_to_id 索引中 8 字节 ID 的正向映射。

它将存储 8 字节 ID 与两个索引之一中的值的反向映射，具体取决于值的大小：

  • id_to_value 索引将 ID 映射到在内部编码后小于 767 字节的面向用户的值。

  • id_to_blob 索引将 ID 映射到更大的面向用户的值。

如何在 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.  S??G  (S and G are constrained; P and O are not)       SPOG

   7.  ?POG  (P, O, and G are constrained; S is not)          POGS
   8.  ?PO?  (P and O are constrained; S and G are not)       POGS
   9.  ?P??  (P is constrained; S, O, and G are not)          POGS

  10.  ?P?G  (P and G are constrained; S and O are not)       GPSO
  11.  SP?G  (S, P, and G are constrained; O is 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 默认情况下没有创建的语句索引之一是反向遍历 OSGP 索引，该索引可跨对象和主题收集谓词。相反，默认情况下，Neptune 在用于执行 {all P x POGS} 联合扫描的单独索引中跟踪不同谓词。当您使用 Gremlin 时，谓词对应于属性或边缘标签。

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

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

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

注意

此特征从 Neptune 引擎版本 1.0.1.0.200463.0 开始推出。

启用 OSGP 索引可能有一些缺点：

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

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

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

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

重要

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

 

Neptune 数据模型中的 Gremlin 语句

在 SPOG 模型中，Gremlin 属性图数据使用三个语句类来表示，即：

有关如何在 Gremlin 查询中使用它们的说明，请参阅了解 Gremlin 查询在 Neptune 中的工作方式。