AnalyticDB:ページングキャッシュ (ディープページングクエリのパフォーマンス最適化)

キャッシュデータベースの設定

ページングキャッシュ機能を使用してクエリ結果をキャッシュする前に、ページングクエリ用の一時キャッシュテーブルを格納するデータベースを指定することを推奨します。データベースを指定しない場合、一時キャッシュテーブルは接続されている内部データベースに格納されます。ページングキャッシュ機能を有効にすると、一時キャッシュテーブルが自動的に作成されます。

たとえば、paging_cache データベースをキャッシュデータベースとして指定できます。他のデータベースを指定することもできます。

SET ADB_CONFIG PAGING_CACHE_SCHEMA=paging_cache;

ページングクエリに対するページングキャッシュ機能の有効化

複数のページングクエリが同じ SQL パターンを共有する場合、SQL ステートメントにヒントを追加してパフォーマンスを向上させることができます。ヒントを含むページングクエリを初めて開始すると、システムはページングクエリの結果を格納するための一時キャッシュテーブルを作成します。同じ SQL パターンを共有する後続のページングクエリを開始する際に、同じヒントを SQL ステートメントに追加できます。これにより、システムはデータベースへの繰り返しアクセスを必要とせず、一時キャッシュテーブルからデータを読み取ります。

キャッシュテーブルに関する情報のクエリ

現在のクラスター内のすべてのページングクエリのキャッシュテーブルに関する情報 (ページング ID、キャッシュサイズ、キャッシュステータスなど) をクエリできます。

SELECT * FROM INFORMATION_SCHEMA.KEPLER_PAGING_CACHE_STATUS_MERGED;

キャッシュテーブルの最大数の指定

現在のクラスター内のキャッシュテーブルの最大数を指定できます。デフォルト値： 32。

SET ADB_CONFIG PAGING_CACHE_MAX_TABLE_COUNT=32;

キャッシュテーブルの総数が上限を超えているときにキャッシュテーブルを作成しようとすると、エラーが発生します。エラーメッセージの例：

Paging cache count exceeds the limit. Please clean up unused caches or increase the related parameter using SET ADB_CONFIG PAGING_CACHE_MAX_TABLE_COUNT=xxx.

エラーメッセージに基づいて、不要になったキャッシュデータをクリアするか、キャッシュテーブルの最大数を増やしてください。

キャッシュテーブルの有効期間の指定

キャッシュテーブルの有効期間を指定できます。単位：秒。有効期間が終了すると、キャッシュテーブルは無効になります。同じ SQL パターンを共有する後続のページングクエリを開始すると、システムはデータベースにアクセスし、キャッシュテーブルを更新します。ほとんどの場合、レポートの同時実行制御シナリオでキャッシュテーブルの有効期間を指定できます。

たとえば、/*paging_cache_enabled=true, paging_cache_validity_interval=300*/ ヒントを使用して、キャッシュテーブルが作成後 300 秒間有効になるように設定できます。ステートメントの例：

/*paging_cache_enabled=true, paging_cache_validity_interval=300*/ SELECT * FROM t_order ORDER BY id LIMIT 0, 100;

ページングクエリのキャッシュデータのクリア

ページングキャッシュ機能を使用してページングされたクエリ結果をキャッシュする場合、キャッシュデータは AnalyticDB for MySQL のホットストレージ領域にキャッシュされます。特定のキャッシュデータが不要になった場合は、キャッシュデータをクリアして、使用可能なストレージを増やすことができます。

手動クリア

• SQL パターンで指定されたページングクエリのキャッシュデータ

  /*paging_cache_enabled=true, invalidate_paging_cache=true*/ ヒントを使用して、SQL パターンで指定されたページングクエリのキャッシュデータをクリアします。

  ステートメントの例：

  /*paging_cache_enabled=true,invalidate_paging_cache=true*/ SELECT * FROM t_order ORDER BY id LIMIT 0, 100;

• paging_id パラメーターで指定されたページングクエリのキャッシュデータ

  paging_id パラメーターで指定されたページングクエリのキャッシュデータをクリアします。

  ステートメントの例：

  CLEAN_PAGING_CACHE paging123;

  説明

  paging_id パラメーターの値を取得する方法については、本トピックの「キャッシュテーブルに関する情報のクエリ」セクションをご参照ください。

自動クリア

キャッシュの有効期限を指定して、指定された時間範囲内にアクセスされなかったページングクエリのキャッシュデータをクリアできます。デフォルト値： 3600。単位：秒。デフォルトでは、1 時間以内にアクセスされなかったキャッシュデータは自動的にクリアされます。

SET ADB_CONFIG PAGING_CACHE_EXPIRATION_TIME=3600;

代替策：キーセットページネーション

ビジネスシナリオがカーソルベースのナビゲーション (たとえば、任意のページにジャンプするのではなく、次のページや前のページに移動する) をサポートしている場合、従来の OFFSET ベースのページネーションの代替としてキーセットページネーションを使用できます。OFFSET を使用して行をスキップする代わりに、キーセットページネーションは WHERE 句を使用して、最後に取得した値に基づいて行をフィルター処理します。これにより、ディープページにおけるグローバルソートとノード間のデータシャッフルのオーバーヘッドを回避できます。

たとえば、id 列が主キーであり、現在のページの最後の id の値が 1000 であると仮定します。次の SQL ステートメントを使用して、次のページをクエリします。

-- 従来のディープページネーション (低速)
SELECT * FROM t_order ORDER BY id LIMIT 1000, 100;

-- キーセットページネーション (高速、推奨)
SELECT * FROM t_order WHERE id > 1000 ORDER BY id LIMIT 100;

キーセットページネーション方式では、多数の行をソートしたりスキップしたりすることなく、インデックスから直接次の行のバッチのみを取得します。これにより、ディープページネーションによって引き起こされるパフォーマンスの低下が解消されます。クエリのパフォーマンスは、ページネーションの深さに関係なく一定に保たれます。

一般的なエラーとトラブルシューティング

Paging cache prepare failed, and cache is not available

エラーメッセージ：

Paging cache prepare failed, and cache is not available. Please use /*paging_cache_enabled=true,invalidate_paging_cache=true*/ to clean the unavailable cache or set a specific pagingId with /*paging_id=xxx*/ to gen a new cache. Note that the old and new cache data may be inconsistent.

原因：ページングキャッシュ機能を使用してデータをクエリする際、ノードの再起動やスケーリングなどの例外が発生することがあります。ページングクエリが作成に失敗したキャッシュテーブルにヒットした場合、サーバーはデータベースにアクセスせず、キャッシュテーブルを自動的に再作成しません。サーバーはエラーをスローします。

解決策：データの整合性を確保するために、次の操作を実行することを推奨します。データ書き出しシナリオでは、書き出したデータと利用できないキャッシュデータをクリアしてから、ページングクエリを再実行してキャッシュテーブルを再作成することを推奨します。他のシナリオでは、利用できないキャッシュデータをクリアするか、paging_id パラメーターに新しい値を指定してから、ページングクエリを再実行してキャッシュテーブルを再作成することを推奨します。