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

# Neptune ルックアップキャッシュは読み取りクエリを高速化できます。
<a name="feature-overview-lookup-cache"></a>

Amazon Neptune は、`R5d` インスタンスの NVME ベースの SSD を使うルックアップキャッシュを実装しており、プロパティ値または RDF リテラルを頻繁に繰り返し検索するクエリの読み取りパフォーマンスを向上させます。ルックアップキャッシュは、これらの値をすばやくアクセスできる NVMe SSD ボリュームに一時的に保存します。

多数の頂点とエッジ、または多くの RDF トリプルのプロパティを返す読み取りクエリは、プロパティ値またはリテラルをメモリではなくクラスターストレージボリュームから取得する必要がある場合に、レイテンシーが高くなる可能性があります。たとえば、アイデンティティグラフから多数のフルネームを返す、または不正検出グラフから IP アドレスを返す、実行時間が長い読み取りクエリなどがあります。クエリによって返されるプロパティ値または RDF リテラルの数が増加すると、使用可能なメモリが減少し、クエリの実行が大幅に低下する可能性があります。

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

# ルックアップキャッシュの使用
<a name="feature-overview-lookup-cache-using"></a>

ルックアップキャッシュは、`R5d` インスタンスタイプで、デフォルトで自動的に有効になります。Neptune `R5d` インスタンスの仕様は、`R5` インスタンスに加え、最大 1.8 TB のローカル NVME ベースの SSD ストレージです。ルックアップキャッシュはインスタンス固有であり、利益をもたらすワークロードは Neptune クラスター内の `R5d` インスタンスに限定され、他のワークロードは `R5` または他のインスタンスタイプを使用できます。

Neptune インスタンスでルックアップキャッシュを使用するには、そのインスタンスを `R5d` インスタンスタイプにアップグレードするだけです。そうすると、Neptune は自動的に [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) DB クラスターのパラメータを `1` に設定し (有効になっている場合)、その特定のインスタンスにルックアップキャッシュを作成します。その後、[インスタンスのステータス](access-graph-status.md) API を使ってキャッシュが有効になったことを確認できます。

同様に、特定のインスタンスのルックアップキャッシュを無効にするには、インスタンスを `R5d` インスタンスタイプから同等の `R5` インスタンスタイプにダウングレードします。

`R5d` インスタンスが起動されると、ルックアップキャッシュが有効になり、コールドスタートモードになります。つまり、空です。Neptune は、クエリの処理中にプロパティ値または RDF リテラルを最初にルックアップキャッシュでチェックし、それらが存在しない場合は追加します。これにより、キャッシュが徐々にウォームアップされます。

プロパティ値または RDFリテラルルックアップを必要とする読み取りクエリを R5d *リーダー*インスタンスに送信する場合、キャッシュがウォームアップする間は、読み取りパフォーマンスがわずかに低下します。ただし、キャッシュがウォームアップされると、読み取りパフォーマンスが大幅に向上し、クラスターストレージではなくルックアップがキャッシュにヒットすることに関連する I/O コストも低下することがあります。メモリ使用率も向上します。

*ライター*インスタンスが `R5d` の場合、書き込み操作ごとにルックアップキャッシュを自動的にウォームアップします。この方法では、書き込みクエリのレイテンシーがわずかに増加しますが、ルックアップキャッシュはより効率的にウォームアップします。次に、プロパティ値または RDFリテラルルックアップを必要とする読み取りクエリをライターインスタンスに転送すると、値が既にキャッシュされているため、すぐに読み取りパフォーマンスが向上します。

また、バルクローダを `R5d` で実行すると、ライターインスタンスでは、キャッシュのためにパフォーマンスがわずかに低下していることに気付くかもしれません。

ルックアップキャッシュは各ノードに固有であるため、ホスト置換によってキャッシュがコールドスタートにリセットされます。

DB クラスター内のすべてのインスタンスのルックアップキャッシュを一時的に無効にするには、[neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) DB クラスターのパラメータを `0` に設定します (無効になっている場合)。ただし、一般的には、特定のインスタンスのキャッシュを `R5d` から `R5` インスタンスタイプスケールダウンして無効にする方が理にかなっています。