キャッシュ ポリシー (ホットおよびコールド キャッシュ)
高速なクエリ パフォーマンスを確保するために、多層データ キャッシュ システムが使用されます。 データは信頼性の高いストレージに格納されますが、その一部は処理ノード、SSD、または RAM にキャッシュされ、アクセスを高速化します。
キャッシュ ポリシーを使用すると、キャッシュするデータを選択できます。 ホット データキャッシュ ポリシーを設定することでデータ キャッシュとデータ キャッシュを区別できます。 ホット データは、クエリ パフォーマンスを向上させるためにローカル SSD ストレージに保持されますが、コールド データは信頼性の高いストレージに格納されます。これは、コストは低くなりますが、アクセスに時間がかかります。
キャッシュでは、ホット データにローカル SSD ディスクの 95% が使用されます。 十分な領域がない場合、最新のデータは優先的にキャッシュに保持されます。 残りの 5% は、ホットとして分類されていないデータに使用されます。 この設計により、多くのコールド データを読み込むクエリによって、キャッシュからホット データが削除されなくなります。
最適なクエリ パフォーマンスは、取り込まれたすべてのデータがキャッシュされた場合に実現されます。 ただし、特定のデータは、ホット キャッシュに保持される費用を保証しない可能性があります。 たとえば、アクセス頻度の低い古いログ レコードは、あまり重要でないと見なされる場合があります。 このような場合、多くの場合、チームは、データをウォームに保つために、支払いよりもクエリのパフォーマンスを低くすることを選択します。
管理コマンドを使用して、 database、 table、または 具体化されたビュー レベルでキャッシュ ポリシーを変更します。
Note
従量課金レートの詳細については、「 Eventhouse および KQL データベースの使用量を参照してください。
管理コマンドを使用して、 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
= 56dhot cache policy
= 28d
この例では、過去 28 日間のデータが SSD に格納され、さらに 28 日間のデータが Azure BLOB ストレージに格納されます。 56 日間のデータ全体に対してクエリを実行できます。