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

# Neptune 查找缓存的用例
<a name="feature-overview-lookup-cache-when-to-use"></a>

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

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

根据经验，只有满足以下所有三个条件时，才值得启用查找缓存：
+ 您会一直在观察到读取查询的延迟时间增加。
+ 在运行读取查询时，您还会发现`BufferCacheHitRatio`[CloudWatch 指标](cw-metrics.md#cw-metrics-available)有所下降（请参阅[使用亚马逊监控 Neptune CloudWatch](cloudwatch.md)）。
+ 在呈现结果之前，您的读取查询会花费大量时间来实现返回值（有关确定查询要实现多少属性值的方法，请参阅以下 Gremlin-profile 示例）。

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

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

```
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 必须执行的项查找数量成正比。