翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Neptune ルックアップキャッシュのユースケース
<a name="feature-overview-lookup-cache-when-to-use"></a>

ルックアップキャッシュは、非常に多数の頂点とエッジ、または RDF トリプルのプロパティを読み取りクエリが返す場合にのみ役立ちます。

クエリのパフォーマンスを最適化するために、Amazon Neptune は `R5d` インスタンスタイプを用いてそのようなプロパティ値またはリテラル用の大きなキャッシュを作成します。キャッシュからそれらを取得することは、クラスターストレージボリュームからそれらを取得するよりもはるかに高速です。

経験則として、次の 3 つの条件がすべて満たされた場合にのみ、ルックアップキャッシュを有効にすることをお勧めします。
+ 読み取りクエリのレイテンシーの増加が観察されている。
+ 読み取りクエリを実行する際に `BufferCacheHitRatio` [CloudWatch メトリクス](cw-metrics.md#cw-metrics-available)に除外が見られる ([Amazon CloudWatch を使用した Neptune のモニタリング](cloudwatch.md)を参照)。
+ 読み取りクエリは、結果をレンダリングする前に戻り値をマテリアライズするのに多くの時間を費やしている（クエリでマテリアライズされているプロパティ値の数を確認する方法については、以下の Gremlin-profile の例を参照してください）。

**注記**  
この機能は上記の特定のシナリオで*のみ*役に立ちます。たとえば、ルックアップキャッシュは集計クエリにまったく役立ちません。ルックアップキャッシュの恩恵を受けるクエリを実行していない限り、同等で安価な `R5` インスタンスタイプの代わりに `R5d` インスタンスタイプを使う理由はありません。

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 が実行しなければならない項ルックアップの数に正比例します。