クエリの一貫性

クエリの一貫性とは、クエリと更新の同期方法を指します。 クエリの一貫性には、次の 2 つのモードがサポートされています。

• 強力な一貫性: 強力な整合性により、データの追加、削除、スキーマの変更など、最新の更新プログラムにすぐにアクセスできます。 強力な整合性は、既定の整合性モードです。 同期のため、この整合性モードは、コンカレンシーの観点から弱い整合性モードよりもわずかに低いパフォーマンスを発揮します。

• 弱い整合性: 整合性が弱い場合、クエリ結果に最新のデータベース更新が反映されるまでに遅延が発生する可能性があります。 通常、この遅延の範囲は 1 分から 2 分です。 弱い整合性では、強力な一貫性よりも高いクエリコンカレンシー率をサポートできます。

たとえば、データベース内のテーブルに 1 分ごとに 1000 個のレコードが取り込まれる場合、厳密な整合性で実行されているテーブルに対するクエリは、最近取り込まれたレコードにアクセスできます。一方、弱い整合性で実行されているテーブルに対するクエリは、過去数分間の一部のレコードにアクセスできない可能性があります。

注意

既定では、クエリは強力な整合性で実行されます。 より高いクエリコンカレンシーをサポートするために必要な場合にのみ、弱い整合性に切り替えることをお勧めします。

強力な一貫性のためのユース ケース

過去数分間にデータベースで発生した更新に強い依存関係がある場合は、強力な一貫性を使用します。

たとえば、次のクエリは、5 分間のエラー レコードの数をカウントし、カウントが 0 より大きいアラートをトリガーします。 このユース ケースは強力な一貫性で処理するのが最適です。分析情報が変更される可能性があるため、過去数分間に取り込まれたレコードにはアクセスできません。これは、一貫性が弱い場合と同様です。

my_table
| where timestamp between(ago(5m)..now())
| where level == "error"
| count

さらに、データベース メタデータが大きい場合は、強力な一貫性を使用する必要があります。 例えば。 データベースには何百万もの データ エクステント があり、弱い整合性を使用すると、クエリ ヘッドが永続ストレージから広範なメタデータ成果物をダウンロードおよび逆シリアル化する結果になり、ダウンロードおよび関連する操作で一時的な障害が発生する可能性が高くなる可能性があります。

一貫性が弱いユース ケース

過去数分間にデータベースで発生した更新に強い依存関係がなく、クエリのコンカレンシーが高い必要がある場合は、弱い整合性を使用します。

たとえば、次のクエリでは、過去 90 日間の 1 週間あたりのエラー レコード数がカウントされます。 過去数分間に取り込まれたレコードに影響を与える可能性が低い分析情報は省略されるため、この場合は弱い一貫性が適切です。

my_table
| where timestamp between(ago(90d) .. now())
| where level == "error"
| summarize count() by level, startofweek(Timestamp)

弱い整合性モード

次の表は、弱いクエリ整合性の 4 つのモードをまとめたものです。

モード	説明
ランダム	クエリは、弱く一貫性のあるクエリ ヘッドとして機能できるクラスター内のいずれかのノードにランダムにルーティングされます。
データベース別のアフィニティ	同じデータベース内のクエリは、同じ弱い整合性のクエリ ヘッドにルーティングされ、そのデータベースに対して一貫した実行が保証されます。
クエリ テキスト別のアフィニティ	同じクエリ テキスト ハッシュを持つクエリは、同じ弱い整合性のクエリ ヘッドにルーティングされます。これは、クエリ キャッシュを利用するのに役立ちます。
セッション ID 別のアフィニティ	同じセッション ID ハッシュを持つクエリは、弱く一貫性のある同じクエリ ヘッドにルーティングされ、セッション内で一貫した実行が保証されます。

データベース別のアフィニティ

データベース モード別のアフィニティにより、同じデータベースに対して実行されているクエリは、必ずしも最新バージョンのデータベースとは限りませんが、同じバージョンのデータベースに対して実行されます。 このモードは、特定のデータベース内で一貫した実行を確保することが重要な場合に便利です。 ただし、 データベース間のクエリの数に不均衡があるため、このモードでは負荷分散が不均一になる可能性があります。

クエリ テキスト別のアフィニティ

クエリテキストモードによるアフィニティは、クエリが クエリ結果キャッシュを利用する場合に役立ちます。 このモードでは、同じ ID によって頻繁に実行される繰り返しクエリが同じクエリ ヘッドにルーティングされるため、キャッシュされた結果の恩恵を受けることができ、クラスターの負荷が軽減されます。

セッション ID 別のアフィニティ

セッション ID モードによるアフィニティにより、同じユーザー アクティビティまたはセッションに属するクエリは、必ずしも最新のデータベースとは限りませんが、同じバージョンのデータベースに対して実行されます。 このモードを使用するには、各クエリのクライアント要求プロパティでセッション ID を明示的に指定する必要があります。 このモードは、セッション内で一貫した実行が不可欠なシナリオで役立ちます。

クエリの整合性を指定する方法

クエリ整合性モードは、クライアントが要求を送信するか、サーバー側ポリシーを使用して指定できます。 どちらも指定されていない場合は、厳密な整合性の既定のモードが適用されます。

• 要求を送信するクライアント: クライアント要求プロパティをqueryconsistency使用します。 このメソッドは、特定のクエリのクエリ整合性モードを設定し、既定またはサーバー側のポリシーによって決定される全体的な有効な整合性モードには影響しません。 詳細については、「 クライアント要求のプロパティ」を参照してください。

• サーバー側ポリシー: クエリ整合性ポリシーの プロパティを使用QueryConsistencyします。 このメソッドは、ワークロード グループ レベルでクエリ整合性モードを設定します。これにより、ユーザーがクライアント要求プロパティで整合性モードを指定する必要がなくなり、必要な整合性モードを適用できます。 詳細については、「 クエリ整合性ポリシー」を参照してください。

注意

Kusto .NET SDK を使用している場合は、接続文字列を使用してクエリの一貫性を設定できます。 この設定は、その特定の接続文字列を介して送信されるすべてのクエリに適用されます。 詳細については、「 接続文字列のプロパティ」を参照してください。

関連コンテンツ

• 弱い整合性で実行されているクエリのパラメーターをカスタマイズするには、 クエリの弱い整合性ポリシーを使用します。