View a markdown version of this page

Neptune 查找缓存的用例 - Amazon Neptune

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

Neptune 查找缓存的用例

只有当读取查询返回非常大量的顶点和边缘或 RDF 三元组的属性时，查找缓存才会有所帮助。

为了优化查询性能，Amazon Neptune 使用 R5d 实例类型为此类属性值或文本创建大型缓存。这样，从缓存中检索它们要比从集群存储卷中检索它们快得多。

根据经验，只有满足以下所有三个条件时，才值得启用查找缓存：

  • 您会一直在观察到读取查询的延迟时间增加。

  • 在运行读取查询时，您还会发现BufferCacheHitRatioCloudWatch 指标有所下降（请参阅使用亚马逊监控 Neptune CloudWatch）。

  • 在呈现结果之前，您的读取查询会花费大量时间来实现返回值（有关确定查询要实现多少属性值的方法，请参阅以下 Gremlin-profile 示例）。

注意

此特征仅在上述特定情况下有用。例如，查找缓存根本无助于聚合查询。除非您运行的查询会受益于查找缓存，否则没有理由使用 R5d 实例类型来代替等效且成本更低的 R5 实例类型。

如果您使用的是 Gremlin，则可以使用 Gremlin profile API 来评测查询的实体化成本。在“索引操作”下，它显示了在执行过程中实体化的项数量：

Index Operations
Query execution:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 5273
Serialization:
    # of statement index ops: 200
    # of unique statement index ops: 140
    Duplication ratio: 1.43
    # of terms materialized: 32693

实体化的非数字项的数量与 Neptune 必须执行的项查找数量成正比。