翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Neptune ルックアップキャッシュは読み取りクエリを高速化できます。
Amazon Neptune は、R5d
インスタンスの NVMeベースの を使用するルックアップキャッシュを実装SSDし、プロパティ値またはRDFリテラルを頻繁に繰り返し検索するクエリの読み取りパフォーマンスを向上させます。ルックアップキャッシュは、これらの値をNVMeSSDボリュームに一時的に保存し、すばやくアクセスできます。
この機能は、Amazon Neptune エンジンバージョン 1.0.4.2.R2 (2021-06-01) で始めることで使用できます。
プロパティ値またはリテラルをメモリではなくクラスターストレージボリュームから取得する必要がある場合、多数の頂点とエッジ、または多数のRDFトリプルのプロパティを返す読み取りクエリは、レイテンシーが高くなる可能性があります。たとえば、アイデンティティグラフから多数のフルネームを返す、または不正検出グラフから IP アドレスを返す、実行時間が長い読み取りクエリなどがあります。クエリによって返されるプロパティ値またはRDFリテラルの数が増えると、使用可能なメモリが減少し、クエリの実行が大幅に低下する可能性があります。
Neptune ルックアップキャッシュのユースケース
ルックアップキャッシュは、読み取りクエリが非常に多数の頂点とエッジ、またはRDFトリプルのプロパティを返す場合にのみ役立ちます。
クエリのパフォーマンスを最適化するために、Amazon Neptune は R5d
インスタンスタイプを用いてそのようなプロパティ値またはリテラル用の大きなキャッシュを作成します。キャッシュからそれらを取得することは、クラスターストレージボリュームからそれらを取得するよりもはるかに高速です。
経験則として、次の 3 つの条件がすべて満たされた場合にのみ、ルックアップキャッシュを有効にすることをお勧めします。
読み取りクエリのレイテンシーの増加が観察されている。
また、読み取りクエリを実行するときに
BufferCacheHitRatio
CloudWatch メトリクスの低下も観察されます (「」を参照Amazon を使用した Neptune のモニタリング CloudWatch)。読み取りクエリは、結果をレンダリングする前に戻り値をマテリアライズするのに多くの時間を費やしている(クエリでマテリアライズされているプロパティ値の数を確認する方法については、以下の Gremlin-profile の例を参照してください)。
注記
この機能は上記の特定のシナリオでのみ役に立ちます。たとえば、ルックアップキャッシュは集計クエリにまったく役立ちません。ルックアップキャッシュの恩恵を受けるクエリを実行していない限り、同等で安価な R5
インスタンスタイプの代わりに R5d
インスタンスタイプを使う理由はありません。
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 が実行しなければならない項ルックアップの数に正比例します。
ルックアップキャッシュの使用
ルックアップキャッシュは、R5d
インスタンスタイプで、デフォルトで自動的に有効になります。Neptune R5d
インスタンスは、R5
インスタンスと同じ仕様に加えて、最大 1.8 TB のローカル NVMeベースのSSDストレージを備えています。ルックアップキャッシュはインスタンス固有であり、利益をもたらすワークロードは Neptune クラスター内の R5d
インスタンスに限定され、他のワークロードは R5
または他のインスタンスタイプを使用できます。
Neptune インスタンスでルックアップキャッシュを使用するには、そのインスタンスを R5d
インスタンスタイプにアップグレードするだけです。これを行うと、Neptune は自動的に neptune_lookup_cache DB クラスターパラメータを 1
(有効) に設定し、その特定のインスタンスにルックアップキャッシュを作成します。その後、 を使用してインスタンスのステータスAPI、キャッシュが有効になっていることを確認できます。
同様に、特定のインスタンスのルックアップキャッシュを無効にするには、インスタンスを R5d
インスタンスタイプから同等の R5
インスタンスタイプにダウングレードします。
R5d
インスタンスが起動されると、ルックアップキャッシュが有効になり、コールドスタートモードになります。つまり、空です。Neptune は、クエリの処理中に最初にルックアップキャッシュでプロパティ値またはRDFリテラルをチェックし、まだ存在しない場合は追加します。これにより、キャッシュが徐々にウォームアップされます。
プロパティ値またはリRDFテラルルックアップを必要とする読み取りクエリを R5d リーダーインスタンスに送信すると、キャッシュのウォームアップ中に読み取りパフォーマンスがわずかに低下します。ただし、キャッシュがウォームアップされると、読み取りパフォーマンスが大幅に向上し、クラスターストレージではなくルックアップがキャッシュにヒットすることに関連する I/O コストも低下することがあります。メモリ使用率も向上します。
ライターインスタンスが R5d
の場合、書き込み操作ごとにルックアップキャッシュを自動的にウォームアップします。この方法では、書き込みクエリのレイテンシーがわずかに増加しますが、ルックアップキャッシュはより効率的にウォームアップします。次に、プロパティ値またはリRDFテラルルックアップを必要とする読み取りクエリをライターインスタンスに転送すると、値が既にそこにキャッシュされているため、すぐに読み取りパフォーマンスが向上します。
また、バルクローダを R5d
で実行すると、ライターインスタンスでは、キャッシュのためにパフォーマンスがわずかに低下していることに気付くかもしれません。
ルックアップキャッシュは各ノードに固有であるため、ホスト置換によってキャッシュがコールドスタートにリセットされます。
DB クラスターパラメータを 0
(無効) に設定することで、neptune_lookup_cacheDB クラスター内のすべてのインスタンスのルックアップキャッシュを一時的に無効にできます。ただし、一般的には、特定のインスタンスのキャッシュを R5d
から R5
インスタンスタイプスケールダウンして無効にする方が理にかなっています。