クエリパフォーマンスの最適化 - Amazon Quantum 台帳データベース (Amazon QLDB)

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

クエリパフォーマンスの最適化

重要

サポート終了通知: 既存のお客様は、07/31/2025 のサポート終了QLDBまで Amazon を使用できます。詳細については、「Amazon Ledger QLDB を Amazon Aurora Postgre に移行するSQL」を参照してください。

Amazon QLDB は、高性能なオンライントランザクション処理 (OLTP) ワークロードのニーズに対応することを目的としています。つまり、 QLDBは SQLのようなクエリ機能をサポートしているにもかかわらず、特定のクエリパターンのセットに最適化されています。これらのクエリパターンを操作するには、アプリケーションとそのデータモデルを設計することが重要です。それ以外の場合は、テーブルが大きくなるにつれて、クエリのレイテンシー、トランザクションのタイムアウト、同時実行の競合など、重大なパフォーマンスの問題が発生します。

このセクションでは、 のクエリ制約について説明QLDBし、これらの制約を考慮して最適なクエリを記述するためのガイダンスを提供します。

トランザクションタイムアウト制限

ではQLDB、すべての PartiQL ステートメント (すべてのSELECTクエリを含む) がトランザクションで処理され、トランザクションのタイムアウト制限 が適用されます。トランザクションは、コミットされるまでに最大 30 秒間実行できます。この制限の後、 はトランザクションに対して行われた作業をすべてQLDB拒否し、トランザクションを実行したセッションを破棄します。この制限は、サービスのクライアントがトランザクションを開始し、トランザクションをコミットまたはキャンセルしないことで、セッションがリークするのを防ぎます。

同時実行の競合

QLDB は、オプティミスティック同時実行制御 () を使用して同時実行制御を実装しますOCC。最適でないクエリは、より多くのOCC競合を引き起こす可能性があります。OCC の詳細については、「Amazon QLDB 同時実行モデル」を参照してください。

最適なクエリパターン

ベストプラクティスとして、インデックス付きフィールドまたはドキュメント ID でフィルタリングする WHERE 述語句を使用してステートメントを実行することをお勧めします。QLDB では、ドキュメントを効率的に検索するために、インデックス付きフィールドに等価演算子 (= または IN) が必要です。

以下に、ユーザービューの最適なクエリパターンの例を示します。

--Indexed field (VIN) lookup using the = operator SELECT * FROM VehicleRegistration WHERE VIN = '1N4AL11D75C109151' --Indexed field (VIN) AND non-indexed field (City) lookup SELECT * FROM VehicleRegistration WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle' --Indexed field (VIN) lookup using the IN operator SELECT * FROM VehicleRegistration WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761') --Document ID (r_id) lookup using the BY clause SELECT * FROM VehicleRegistration BY r_id WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'

これらのパターンに従わないクエリはテーブル全体のスキャンを呼び出します。テーブルスキャンは、大きなテーブルのクエリや大きな結果セットを返すクエリに対してトランザクションタイムアウトを引き起こす可能性があります。また、競合するトランザクション とのOCC競合につながる可能性もあります。

高基数インデックス

高基数値を含むフィールドのインデックスを作成することをお勧めします。例えば、VehicleRegistration テーブル内の VINLicensePlateNumber のフィールドは、一意にすることを意図したインデックス付きフィールドです。

ステータスコード、住所の都道府県、郵便番号などの低基数フィールドのインデックス作成は避けてください。このようなフィールドのインデックスを作成すると、クエリによって大きな結果セットが生成され、トランザクションがタイムアウトしたり、意図しないOCC競合が発生したりする可能性があります

コミット済みビュークエリ

コミット済みビューで実行するクエリは、ユーザービュークエリと同じ最適化ガイドラインに従います。テーブル上に作成するインデックスは、コミット済みビューのクエリにも使用されます。

履歴関数クエリ

履歴関数クエリでは、テーブルで作成するインデックスは使用されません。QLDB 履歴はドキュメント ID によってのみインデックス付けされ、現時点では追加の履歴インデックスを作成することはできません。

ベストプラクティスとして、履歴クエリを日付範囲 (開始時刻および終了時刻) とドキュメント ID (metadata.id) の両方で修飾します。開始時刻と終了時刻を含む履歴クエリでは、日付範囲修飾のメリットが得られます。

内部結合クエリ

内部結合クエリでは、少なくとも結合の右側にあるテーブルのインデックス付きフィールドを含む結合条件を使用します。結合インデックスがない場合、結合クエリは複数のテーブルスキャンを呼び出します。結合の左側のテーブルのすべてのドキュメントに対して、クエリは右側のテーブルを完全にスキャンします。ベストプラクティスは、少なくとも 1 つのテーブルに WHERE 等価述語を指定することに加えて、結合している各テーブルにインデックス付けされているフィールドに結合することです。

例えば、次のクエリでは、VehicleRegistrationVehicle のテーブルをそれぞれの VIN フィールドに結合します。その両方にインデックスが付けられます。このクエリには、VehicleRegistration.VIN の等価述語もあります。

SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v ON r.VIN = v.VIN WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

結合クエリの結合基準と等価述語の両方に高基数インデックスを選択します。

回避すべきクエリパターン

以下は、 の大きなテーブルではうまくスケーリングされない最適ではないステートメントの例ですQLDB。クエリは最終的にトランザクションタイムアウトになるため、時間の経過とともに増加するテーブルについては、これらのタイプのクエリに依存しないことを強くお勧めします。テーブルにはサイズの異なるドキュメントが含まれているため、インデックス付けされていないクエリに対して正確な制限を定義することは困難です。

--No predicate clause SELECT * FROM Vehicle --COUNT() is not an optimized function SELECT COUNT(*) FROM Vehicle --Low-cardinality predicate SELECT * FROM Vehicle WHERE Color = 'Silver' --Inequality (>) does not qualify for indexed lookup SELECT * FROM Vehicle WHERE "Year" > 2019 --Inequality (LIKE) SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%' --Inequality (BETWEEN) SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T` --No predicate clause DELETE FROM Vehicle --No document id, and no date range for the history() function SELECT * FROM history(Vehicle)

一般に、 の本番稼働用ユースケースでは、次のタイプのクエリパターンを実行することはお勧めしませんQLDB。

  • オンライン分析処理 (OLAP) クエリ

  • 述語句のない探索的クエリ

  • レポート作成クエリ

  • テキスト検索

代わりに、分析ユースケースに、最適化された目的別データベースサービスへのデータのストリーミングをすることをお勧めします。例えば、Amazon OpenSearch Service にQLDBデータをストリーミングして、ドキュメントに全文検索機能を提供できます。このユースケースを示すサンプルアプリケーションについては、 GitHub リポジトリ aws-samples/amazon-qldb-streaming-amazon- opensearch-service-sample-pythonを参照してください。ストリームの詳細についてはQLDB、「」を参照してくださいAmazon からのジャーナルデータのストリーミング QLDB

パフォーマンスのモニタリング

QLDB ドライバーは、消費された I/O 使用状況とタイミング情報をステートメントの結果オブジェクトに提供します。これらのメトリクスを使用して、非効率な PartiQL ステートメントを特定できます。詳細については、「PartiQL ステートメントの統計の取得」を参照してください。

Amazon を使用して CloudWatch 、データオペレーションの台帳のパフォーマンスを追跡することもできます。指定された LedgerNameCommandType に対する CommandLatency メトリクスをモニタリングします。詳細については、「Amazon によるモニタリング CloudWatch」を参照してください。QLDB がコマンドを使用してデータオペレーションを管理する方法については、「」を参照してくださいドライバーによるセッション管理