次の方法で共有

キャッシュ ポリシー (ホットおよびコールド キャッシュ)

  • [アーティクル]

Azure Data Explorer では、多層データ キャッシュ システムを使用して、高速なクエリ パフォーマンスを実現します。 データは Azure Blob Storage などの信頼性の高いストレージに格納されますが、その一部は処理ノード、SSD、または RAM にキャッシュされ、アクセスが高速化されます。

リアルタイム インテリジェンスは、多層データ キャッシュ システムを使用して、高速なクエリ パフォーマンスを保証します。 データは OneLake などの信頼性の高いストレージに格納されますが、その一部は処理ノード、SSD、または RAM にキャッシュされ、アクセスが高速化されます。

キャッシュ ポリシーを使用すると、キャッシュするデータを選択できます。 ホット データキャッシュ ポリシーを設定することでデータ キャッシュとデータ キャッシュを区別できます。 ホット データは、クエリ パフォーマンスを向上させるためにローカル SSD ストレージに保持されますが、コールド データは信頼性の高いストレージに格納されます。これは、コストは低くなりますが、アクセスに時間がかかります。

キャッシュでは、ホット データにローカル SSD ディスクの 95% が使用されます。 十分な領域がない場合、最新のデータは優先的にキャッシュに保持されます。 残りの 5% は、ホットとして分類されていないデータに使用されます。 この設計により、多くのコールド データを読み込むクエリによって、キャッシュからホット データが削除されなくなります。

最適なクエリ パフォーマンスは、取り込まれたすべてのデータがキャッシュされた場合に実現されます。 ただし、特定のデータは、ホット キャッシュに保持される費用を保証しない可能性があります。 たとえば、アクセス頻度の低い古いログ レコードは、あまり重要でないと見なされる場合があります。 このような場合、多くの場合、チームは、データをウォームに保つために、支払いよりもクエリのパフォーマンスを低くすることを選択します。

管理コマンドを使用して、 database、 table、または 具体化されたビュー レベルでキャッシュ ポリシーを変更します。

管理コマンドを使用して、 cluster、 database、 table、または 具体化されたビュー レベルでキャッシュ ポリシー変更します。

ヒント

クラスターは、クラスターの合計 RAM に収まる中間結果セットを含むアドホック クエリ用に設計されています。 map-reduce などの大規模なジョブでは、中間結果を永続的なストレージに格納すると便利です。 これを行うには、 連続するエクスポート ジョブを作成します。 この機能を使用すると、HDInsight や Azure Databricks のようなサービスを使用して、実行時間の長いバッチ クエリを実行できます。

キャッシュ ポリシーの適用方法

データが取り込まれると、システムはインジェストの日時と、作成されたエクステントを追跡します。 エクステントのインジェスト日時値 (または、エクステントが複数の既存のエクステントから構築された場合は最大値) は、キャッシュ ポリシーの評価に使用されます。

Note

インジェストの日付と時刻の値は、インジェスト プロパティ creationTime を使用して指定できます。 指定する場合、ターゲット テーブルの有効な エクステント マージ ポリシーの Lookback プロパティが、creationTime に指定した値と整合していることを確認します。

既定では、有効なポリシーは null であり、すべてのデータがホットとして見なされます。 テーブル レベルでの null ポリシーは、ポリシーがデータベースから継承されることを意味します。 null ではないテーブル レベルのポリシーは、データベース レベルのポリシーをオーバーライドします。

ホット キャッシュへのクエリをスコープする

クエリを実行する場合は、ホット キャッシュ内のデータに対してのみクエリを実行するようにスコープを制限できます。

Note

データ スコープは、テーブルや具体化されたビューなどのキャッシュ ポリシーをサポートするエンティティにのみ適用されます。 外部テーブルや行ストア内のデータなど、他のエンティティでは無視されます。

次のいくつかのクエリが考えられます。

  • query_datascope と呼ばれるクライアント要求プロパティをクエリに追加します。 指定できる値: default、all、hotcache。
  • setクエリ テキストに次のステートメントset query_datascope='...'を使用します。 指定できる値は、クライアント要求プロパティの場合と同じです。
  • クエリ本文のテーブル参照の直後に datascope=... テキストを追加します。 設定可能な値は all および hotcache です。

default 値は、クラスターの既定の設定を使用して、クエリですべてのデータをカバーする必要があるかどうかを示します。

異なるメソッド間に不一致がある場合、set はクライアント要求プロパティよりも優先されます。 テーブル参照の値の指定は、両方よりも優先されます。

たとえば、次のクエリでは、すべてのテーブル参照でホット キャッシュ データのみが使用されます。ただし、"T" への 2 番目の参照を除き、すべてのデータにスコープが設定されます。

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

キャッシュ ポリシーとアイテム保持ポリシー

キャッシュ ポリシーは、 再入ポリシーとは無関係です:

  • キャッシュ ポリシーは、リソースに優先順位を付ける方法を定義します。 重要なデータに対するクエリの方が高速です。
  • 保有保持ポリシーでは、テーブル/データベース内のクエリ可能なデータの範囲 (具体的には SoftDeletePeriod) を定義します。

予想されるクエリ パターンに基づいて、コストとパフォーマンスの最適なバランスを実現するには、このポリシーを構成します。

例:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

この例では、過去 28 日間のデータがクラスター SSD 上に置かれ、さらに 28 日間のデータが Azure Blob Storage に格納されます。 56 日間のデータ全体に対してクエリを実行できます。

関連するコンテンツ