翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Neptune エンジンバージョン 1.4.0.0 (2024-11-06)
2024-11-06 の時点で、エンジンバージョン 1.4.0.0 は一般にデプロイされています。新しいリリースがすべてのリージョンで利用可能になるまでに数日かかります。
注記
エンジンリリース 1.3.0.0 では、カスタムパラメータグループとカスタムクラスターパラメータグループに新しい形式が導入されました。そのため、1.3.0.0 より前のエンジンバージョンからエンジンバージョン 1.3.0.0 以降にアップグレードする場合は、パラメータグループファミリー neptune1.3
を使用している既存のカスタムパラメータグループとカスタムクラスターパラメータグループをすべて再作成する必要があります。以前のリリースではパラメータグループファミリー neptune1
または neptune1.2
を使用していましたが、これらのパラメータグループはリリース 1.3.0.0 以降では動作しません。詳細については、「Amazon Neptune パラメータグループ」を参照してください。
警告
クエリプランキャッシュは、クエリで数値型パラメータの重複使用を処理するバグにより、数値パラメータ値を含むパラメータ化されたクエリを実行するユースケースでは一時的にサポートされていません。例えば:
MATCH (n:movie) WHERE n.runtime>=$minutes RETURN n UNION MATCH (n:show) WHERE n.duration>=$minutes RETURN n parameters={"minutes":130}
ステートメントまたはディクショナリインデックスに対して多くのインデックス検索を行うクエリでは、5% のパフォーマンス低下が発生する可能性があります。例えば、すべての頂点の数を取得したり、すべての頂点id
の を取得したりしても影響を受けません。すべての頂点のすべてのプロパティを取得すると、最大 5% の回帰が表示される可能性があります。
このエンジンリリースの新機能
-
明示的な ID なしでエッジがプロパティグラフに追加されると、サーバーはデフォルトで UUID ベースのエッジ ID を割り当てます。これはディクショナリに保存されます。これで、新しいクラスターパラメータ を設定することで
neptune_enable_server_generated_edge_id = 1
、サーバーは内部管理の 8 バイト整数を使用して IDs を割り当てます。ディクショナリオーバーヘッドはありません。これにより、ストレージを節約し、クエリを変更することなくクエリのパフォーマンスが向上します。この機能は現在、Gremlin クエリ言語経由の挿入でのみサポートされています。 -
DFE エンジンのネストされたトラバーサルでの Gremlin limit() ステップ実行のサポートが追加されました。
g.V().project("foo").by(out().order().by(T.id).limit(1))
このエンジンリリースの改良点
全般的な改善
-
Neptune は、トランザクションが完了し、復旧にログが不要になると、大きなトランザクションに保持されている UNDO ストレージを自動的に再利用します。
-
グローバルデータベース存続可能レプリカのサポート。この機能により、セカンダリクラスターはプライマリクラスターでのライターインスタンスの再起動中に読み取りリクエストを引き続き処理できます。以前は、ライターインスタンスが再起動すると、セカンダリクラスター内のすべてのリーダーインスタンスも再起動していました。このリリースでは、セカンダリクラスターリーダーインスタンスは、ライターインスタンスの再起動中も引き続き読み取りリクエストを処理し、クラスターの読み取り可用性を向上させます。
-
監査ログが同期的に書き込まれるようになりました。これにより、すべてのクエリがログに記録されます。これは、特に大規模なクエリ (>100 KB) または高スループットワークロード (>1000 qps) のパフォーマンスに影響する可能性があります。
Gremlin の改善
-
デフォルトでは、クエリごとのタイムアウトはクラスターレベルのタイムアウトよりも小さくなります。以前のリリースでは、このチェックが導入されましたが、ラボモードパラメータStrictTimeoutValidation」を使用して明示的に有効にする必要がありました。このリリースでは、StrictTimeoutValidation」はデフォルトで有効になり、古い動作を維持するために明示的に無効にする必要があります。
openCypher の改善
-
以前のリリースでは、ラボモードパラメータ を介して有効になる、拡張日時形式のサポートが導入されました
DatetimeMillisecond
。この拡張日時形式のサポートは、デフォルトで有効になりました。
SPARQLの改善
-
クエリアクセス許可の新しい明示的な IAM アクション。
Previously: COPY: WriteDataViaQuery & ReadDataViaQuery MOVE: WriteDataViaQuery & DeleteDataViaQuery DELETEINSERT: ReadDataViaQuery & DeleteDataViaQuery Now, COPY: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery MOVE: WriteDataViaQuery & ReadDataViaQuery & DeleteDataViaQuery DELETEINSERT: ReadDataViaQuery, WriteDataViaQuery if there is INSERT clause, DeleteDataViaQuery if there is DELETE clause.
このエンジンリリースで修正された不具合
一般的な修正
-
スケールアップ中にデータベースが再起動する可能性があるサーバーレスインスタンスの問題を修正しました。
-
監査ログファイルの管理に関連する問題を修正しました。これにより、ダウンロードやローテーションのためにログファイルにアクセスできなくなり、場合によっては CPU の使用が増加する可能性があります。
-
DFE エンジンでマップ出力生成の最適化遅延に関連するクエリの問題を修正しました。
-
監査ログとスロークエリログの間でタイムスタンプが一致しない問題を修正しました。
Gremlin の修正
-
Gremlin WebSocket 接続管理で、接続アイドルタイムアウトを超える時間実行されているクエリが途中で終了する問題を解決しました。これは、特に AIOHTTP トランスポートを使用する Python Gremlin クライアントに影響しました。
openCypher の修正
-
collect(distinct(n)) クエリコンストラクト中に null 値が存在する場合に内部障害例外が発生する collect ステップの問題を修正しました。
-
クエリプランキャッシュが有効になっていると、クエリで が発生する
NullPointerException
可能性がある問題を修正しました。 -
クエリに LIMIT 句が含まれている場合に、必要以上のデータを評価する問題を修正しました。
-
クエリプランキャッシュでパラメータ化されたクエリで範囲オペレーション (<、<=、>、>=) を使用すると、結果が重複する問題を修正しました。
-
ボルト接続を使用して UNION および UNIONALL 操作を実行すると、結果列が変換される問題を修正しました。
このリリースでサポートされるクエリ言語バージョン
DB クラスターをバージョン 1.4.0.0 にアップグレードする前に、プロジェクトが次のクエリ言語バージョンと互換性があることを確認してください。
サポートされている最も古いバージョンの Gremlin:
3.7.1
サポートされている最も新しいバージョンの Gremlin:
3.7.1
openCypher バージョン:
Neptune-9.0.20190305-1.0
SPARQL バージョン:
1.1
エンジンリリース 1.4.0.0 へのアップグレードパス
このリリースへは、エンジンリリース 1.2.0.0 以降からアップグレードできます。
このリリースへのアップグレード
DB クラスターで、このリリースへのアップグレードパスがあるエンジンバージョンを実行している場合は、今すぐアップグレードできます。対象となるクラスターは、 コンソールの DB クラスターオペレーションまたは SDK を使用してアップグレードできます。次の CLI コマンドは、対象のクラスターをすぐにアップグレードします。
Linux、OS X、Unix の場合:
aws neptune modify-db-cluster \ --db-cluster-identifier
(your-neptune-cluster)
\ --engine-version 1.4.0.0 \ --allow-major-version-upgrade \ --apply-immediately
Windows の場合:
aws neptune modify-db-cluster ^ --db-cluster-identifier
(your-neptune-cluster)
^ --engine-version 1.4.0.0 ^ --allow-major-version-upgrade ^ --apply-immediately
--apply-immediately
の代わりに --no-apply-immediately
と指定することができます。メジャーバージョンアップグレードを実行するには、 allow-major-version-upgrade パラメータが必要です。また、エンジンバージョンを含めるようにしてください。そうしないと、エンジンが別のバージョンにアップグレードされる可能性があります。
クラスターでカスタムクラスターパラメータグループを使用する場合は、必ずこのパラメータを含めて、それを指定してください。
--db-cluster-parameter-group-name
(name of the custom DB cluster parameter group)
同様に、クラスター内のインスタンスがカスタム DB のパラメータグループを使用している場合は、必ずこのパラメータを指定して、次のようになります。
--db-instance-parameter-group-name
(name of the custom instance parameter group)
アップグレードの前に必ずテストする
新しいメジャーまたはマイナーバージョンの Neptune エンジンがリリースされたら、アップグレードする前に、まず最初に Neptune アプリケーションをテストしてください。マイナーアップグレードでも、コードに影響する新しい機能や動作が導入される可能性があります。
まず、現在のバージョンのリリースノートページと対象バージョンのリリースノートページを比較して、クエリ言語のバージョンに変更があるか、その他の重大な変更がないかを確認します。
本番 DB クラスターをアップグレードする前に新しいバージョンをテストする最善の方法は、本番クラスターをクローンして、クローンで新しいエンジンバージョンを実行することです。その後、本番 DB クラスターに影響を与えずに、クローンに対してクエリを実行できます。
アップグレードの前に必ずスナップショットを手動で作成してください
アップグレードの前に必ず DB クラスターの手動スナップショットを作成することを強く推奨します。自動スナップショットを作成しても短期的な保護しか得られませんが、手動スナップショットは明示的に削除するまで使用できます。
場合によっては、Neptune がアップグレードプロセスの一環として手動スナップショットを作成することもありますが、これを頼りにすべきではなく、どのような場合でも独自の手動スナップショットを作成する必要があります。
DB クラスターをアップグレード前の状態に戻す必要がないことが確実な場合は、自分で作成した手動スナップショットと、Neptune が作成した手動スナップショットを明示的に削除できます。Neptune が手動スナップショットを作成する場合、その名前は preupgrade
で始まり、その後に DB クラスターの名前、ソースエンジンのバージョン、ターゲットエンジンのバージョン、および日付が続きます。
注記
保留中のアクションの処理中にアップグレードを試みた場合、次のようなエラーが発生する可能性があります。
We're sorry, your request to modify DB cluster (cluster identifier) has failed. Cannot modify engine version because instance (instance identifier) is running on an old configuration. Apply any pending maintenance actions on the instance before proceeding with the upgrade.
このエラーが発生した場合は、保留中のアクションが終了するのを待つか、すぐにメンテナンスウィンドウをトリガーして、前回のアップグレードを完了させます。
お使いのエンジンバージョンのアップグレードの詳細については、Amazon Neptune DB クラスターのメンテナンス を参照してください。ご質問やご不明点がございましたら、 コミュニティフォーラムおよび AWS プレミアム