クエリ結果のキャッシュ
Kusto には、クエリ結果のキャッシュが含まれています。 クエリを発行する際に、キャッシュされた結果を取得することを選択できます。 クエリの結果をキャッシュから返すことができれば、クエリのパフォーマンスが向上し、リソースの消費量が少なくなります。 ただし、このパフォーマンスには、結果の一部の "鮮度の低下" という犠牲が伴います。
キャッシュの使用
クエリ結果キャッシュを使用するには、クエリの一部として query_results_cache_max_age
オプションを設定します。 このオプションは、クエリ テキスト内に、またはクライアント リクエスト プロパティとして設定できます。 次に例を示します。
set query_results_cache_max_age = time(5m);
GithubEvent
| where CreatedAt > ago(180d)
| summarize arg_max(CreatedAt, Type) by Id
オプション値は timespan
です。これは、クエリの開始時刻から測定された、結果キャッシュの最大 "経過時間" を示すものです。 設定されたタイムスパンを超えると、キャッシュ エントリは廃止され、再度使用されることはありません。 値を 0 に設定することは、オプションを設定しないことと同じです。
クエリ間の互換性
同一のクエリ
クエリ結果のキャッシュから返される結果は、以前にキャッシュされたクエリと "同一" であると見なされたクエリに対するもののみとなります。 次の条件がすべて満たされている場合、2 つのクエリは同一であると見なされます。
- 2 つのクエリには、同じ表現が使用されます (UTF-8 文字列として)。
- 2 つのクエリが同じデータベースに対して行われます。
- 2 つのクエリで、同じクライアント要求プロパティが共有されます。 次のプロパティは、キャッシュの目的で無視されます。
互換性のないクエリ
次のいずれかの条件に該当する場合、クエリ結果はキャッシュされません。
- このクエリは、RestrictedViewAccess ポリシーが有効になっているテーブルを参照します。
- このクエリでは、RowLevelSecurity ポリシーが有効になっているテーブルを参照します。
- クエリでは、次の関数のいずれかを使用します。
- クエリがアクセスするのは、外部テーブルまたは外部データです。
- このクエリでは、evaluate plugin 演算子が使用されます。
有効なキャッシュ エントリがありません
時間制約を満たすキャッシュされた結果が見つからなかった場合、またはキャッシュ内の "同一" クエリからキャッシュされた結果がない場合は、次の場合に限り、クエリが実行され、その結果がキャッシュされます。
- クエリの実行が成功しました。
- クエリ結果のサイズが 16 MB を超えていません。
キャッシュからの結果
サービスでは、クエリ結果がキャッシュから提供されていることをどのように示しますか?
クエリに応答するとき、Kusto からは、Key
列と Value
列を含む別の ExtendedProperties 応答テーブルが送信されます。
キャッシュされたクエリ結果では、そのテーブルに別の行が追加されます。
- 行の
Key
列には、文字列ServerCache
が含まれる - 行の
Value
列には、次の 2 つのフィールドを持つプロパティ バッグが含まれるOriginalClientRequestId
- 元の要求の ClientRequestId を指定する。OriginalStartedOn
- 元の要求の実行開始時刻を指定します。
配布
キャッシュはクラスター ノードによって共有されません。 どのノードも独自のプライベート ストレージに専用のキャッシュを備えています。 2 つの同一のクエリが別々のノードに配置されると、クエリが実行され、両方のノードにキャッシュされます。 このプロセスは、脆弱な整合性が使用されている場合に発生する可能性があります。 クエリの整合性を affinitizedweakconsistency
に設定することで、同じクエリ ヘッドに配置される同じクエリの整合性を脆弱にすることができるため、キャッシュのヒット率が向上します。
管理
次の管理および監視コマンドがサポートされています。
- クエリ結果キャッシュの表示: クエリ結果キャッシュに関連する統計情報を返します。
- クエリ結果キャッシュのクリア: クエリ結果キャッシュをクリアします。
- クエリ キャッシュ エントリの更新:
query_results_cache_force_refresh
(OptionQueryResultsCacheForceRefresh) クライアント要求プロパティを使用して、特定のクエリ キャッシュ エントリを更新できます。true
に設定すると、このコマンドは、既存のキャッシュが存在する場合もクエリ結果キャッシュを強制的に更新します。 このプロセスは、クエリの結果をクエリに使用できるようにする必要があるシナリオで役立ちます。 このプロパティは 'query_results_cache_max_age' と組み合わせて使用し、ClientRequestProperties オブジェクトで送信する必要があります。 このプロパティを 'set' ステートメントの一部にすることはできません。
容量
キャッシュ容量は現在、クラスター ノードあたり 1 GB に固定されています。 削除ポリシーは LRU です。
シャード レベルのクエリ結果のキャッシュ
クエリ結果のキャッシュは、まったく同じクエリがすばやく連続して複数回実行され、わずかに古いデータを返すことを許容できる場合に効果的です。 ただし、ライブ ダッシュボードのような一部のシナリオでは、最新の結果が必要になります。
たとえば、10 秒ごとに実行され、過去 1 時間にわたるクエリは、ストレージ (シャード) レベルで中間クエリ結果をキャッシュすることでメリットが得られます。
シャード レベルのクエリ結果のキャッシュは、Query results cache
が使用されているときに、自動的に有効になります。 Query results cache
と同じキャッシュを共有するため、同じ容量と削除ポリシーが適用されます。
構文
set
query_results_cache_per_shard
; Query
Note
このオプションは、クエリ テキストまたはクライアント要求プロパティとして設定できます。
構文規則について詳しく知る。
例
set query_results_cache_per_shard;
GithubEvent
| where CreatedAt > ago(180d)
| summarize arg_max(CreatedAt, Type) by Id
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示