.マテリアライズドビューを作成する

適用対象: ✅Microsoft Fabric✅Azure データ エクスプローラー

具体化されたビューは、ソース テーブルに対する集計クエリです。 これは単一の summarize ステートメントを表します。

コマンドの backfill オプションで示されているように、具体化されたビューを作成するには、次の 2 つの方法があります。

これから具体化されたビューを作成します。

• 具体化されたビューは空で作成されます。 ビューの作成後に取り込まれたレコードのみが含まれます。 この種類の作成はすぐに返され、ビューはすぐにクエリに使用できます。

ソース テーブルの既存のレコードに基づいて、具体化されたビューを作成する:

• 「 具体化されたビューの埋め込みを参照してください。
• ソース テーブル内のレコードの数によっては、作成が完了するまでに時間がかかる場合があります。 ビューは、バックフィルが完了するまでクエリに使用できません。
• このオプションを使用する場合は、create コマンドを asyncする必要があります。 .show operations コマンドを使用して実行を監視できます。
• .cancel operation コマンドを使用して、バックフィル プロセスを取り消すことができます。

アクセス許可

このコマンドを実行するには、少なくとも データベース管理者 アクセス許可が必要です。 具体化されたビューの作成者が管理者になります。

構文

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon tableSourceTableName{クエリ}

構文規則について詳しく知る。

パラメーター

サポートされるプロパティ

with ( PropertyName=PropertyValue) 句では、次のプロパティがサポートされています。 すべてのプロパティは省略可能です。

振り返り期間

ルックバックでは、具体化されたビュー ソース テーブル内の同じグループ化キーの組み合わせの任意の 2 つのレコード間の予想される最大期間を指定します。 ルックバックを設定すると、具体化されたビューのパフォーマンスが大幅に向上します。

たとえば、Web サービスの各セッションの最後のイベントを格納するために使用される具体化されたビューを考えてみましょう。 ビューは次のように定義されます。

Events | summarize arg_max(ReceivedTime, *) by SessionId

セッションが 1 日以上続かないことが明らかな場合は、パフォーマンスを向上させるために、 lookback_column と lookback の期間を設定できます。

.create materialized-view with(lookback=1d, lookback_column = "ReceivedTime") SessionEvents on table Events
{
    Events
    | summarize arg_max(ReceivedTime, *) by SessionId
}

具体化されたビューにルックバックを設定すると、具体化時にスキャンされるビューの部分が減少します。 具体化されたビュー全体をスキャンする代わりに、ルックバック期間内に含まれる部分のみが具体化時に デルタ と組み合わされます。 詳細については、「 具体化されたビューのしくみ」を参照してください。 この手順では具体化されたビューのパフォーマンスを大幅に向上させることができますが、間違ったルックバック期間を設定すると、レコードが重複する可能性があります。 前の例では、同じ SessionIdのレコードの 2 日後にレコードが取り込まれる場合、具体化されたビューには、その SessionIdの重複レコードが含まれます。

ルックバック列

ルックバック期間は、マテリアライズド ビューの datetime 列に対して常に相対的です。 この列を定義するには、次の 2 つの方法があります。

• デフォルト： ソース テーブル内のレコードの ingestion_time() に対する相対値。 レコードは、現在のレコードに対するルックバック期間の後にソース テーブルに取り込まれるレコードに対してのみ重複除去されます。 この種のルックバックは、 arg_max、 arg_min、または take_any 具体化されたビューに対してのみ有効であり、インジェスト時間を保持するビューに対してのみ有効です。 詳細については、「 具体化されたビューの制限事項と既知の問題」を参照してください。 既定のオプションを構成するには、lookback プロパティを指定せずに lookback_column プロパティを設定します。

• lookback_column: 具体化されたビューの datetime 列に対する相対値。 ルックバックは、 lookback_column プロパティを使用して、具体化されたビュー定義で明示的に指定されます。 lookbackプロパティとlookback_columnプロパティの両方を設定することで、ルックバック列オプションを構成できます。

  • 具体化されたビュー集計のグループ化キーの 1 つであるdatetime列にlookback_columnを定義する必要はありません。 lookback_columnは、グループ化キーの一部ではない別のdatetime列を参照する場合にのみ役立ちます。
  • lookback_columnが定義されると、その値を変更することはできません。
  • 列にlookback_column値がある場合、datetime(null)を使用すると重複する可能性があります。 このような場合、グループ化キーの特定の組み合わせに対して、ビューは 1 つのレコードに datetime(null) 値を持ち、もう 1 つは null 以外の値になります。

具体化されたビューにマテリアライズド ビューを作成する

別の具体化されたビューに対して具体化されたビューを作成できるのは、ソースマテリアライズド ビューが take_any(*) 集計 (重複除去) である場合のみです。 詳細については、「 具体化されたビューの具体化されたビュー および Examplesを参照してください。

構文：

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon materialized-viewSourceMaterializedViewName{クエリ}

パラメーター:

例

• 今後取り込まれたレコードのみを具体化する空の arg_max ビューを作成します。

  .create materialized-view ArgMax on table T
  {
      T | summarize arg_max(Timestamp, *) by User
  }
  

• asyncを使用して、バックフィル オプションを使用して日次集計の具体化されたビューを作成します。

  .create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
  {
      T 
      | extend Day = bin(Timestamp, 1d)
      | summarize count(), dcount(User), max(Duration) by Customer, Day 
  } 
  

• backfillとeffectiveDateTimeを使用して具体化されたビューを作成します。 ビューは、datetime からのレコードのみに基づいて作成されます。

  .create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
  {
      T 
      | extend Day = bin(Timestamp, 1d)
      | summarize count(), dcount(User), max(Duration) by Customer, Day
  } 
  

• 6 時間のルックバックを使用して、 EventId 列に基づいてソース テーブルを重複除去する具体化されたビューを作成します。 レコードは、現在のレコードの 6 時間前に取り込まれたレコードに対してのみ重複除去されます。

  .create materialized-view with(lookback=6h) DeduplicatedTable on table T
  {
      T
      | summarize take_any(*) by EventId
  }
  

• DeduplicatedTableマテリアライズド ビューに基づいてダウンサンプリングマテリアライズド ビューを作成します。

  .create materialized-view DailyUsage on materialized-view DeduplicatedTable
  {
      DeduplicatedTable
      | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
  }
  

• 6 時間のルックバックを使用して、 EventId 列に基づいてソース テーブルを重複除去する具体化されたビューを作成します。 レコードは、 Timestamp が現在のレコードと最大 6 時間の差を持つレコードに重複除去されます。

  .create materialized-view with(lookback=6h, lookback_column = "Timestamp") LatestEventID on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  }
  

• summarizeが最後の演算子である限り、定義には、summarize ステートメントの前に追加の演算子を含めることができます。

  .create materialized-view CustomerUsage on table T 
  {
      T 
      | where Customer in ("Customer1", "Customer2", "CustomerN")
      | parse Url with "https://contoso.com/" Api "/" *
      | extend Month = startofmonth(Timestamp)
      | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
  }
  

• ディメンション テーブルと結合する具体化されたビューを次に示します。

  .create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
  {
      T
      | lookup DimUsers on User  
      | summarize arg_max(Timestamp, *) by User 
  }
  
  .create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
  {
      DimUsers | project User, Age, Address
      | join kind=rightouter hint.strategy=broadcast T on User
      | summarize arg_max(Timestamp, *) by User 
  }
  

解説

Query parameter (クエリ パラメーター)

次のルールでは、具体化されたビューのクエリ パラメーターで使用されるクエリが制限されます。

• クエリは、具体化されたビューのソースである 1 つのファクト テーブルを参照する必要があります。 1 つの summarize 演算子と、1 つ以上の aggregation 関数を含める必要があります 式によって 1 つ以上のグループによって集計されます。 summarize演算子は、常にクエリの最後の演算子である必要があります。

  1 つの arg_max/arg_min/take_any 集計のみを含むマテリアライズド ビューは、これらの集計を他の集計 ( count/dcount/avg など) と共に含む具体化されたビューよりも優れたパフォーマンスを発揮する場合があります。 これは、一部の最適化は、このような具体化されたビューにのみ関連するためです。 ビューに混合集計関数が含まれている場合は適用されません ( ミックス は、同じビュー内の arg_max/arg_min/take_any とその他の集計の両方を意味します)。

• クエリには、now() に依存する演算子を含めることはできません。 たとえば、クエリに where Timestamp > ago(5d) を含めることはできません。 具体化されたビューのアイテム保持ポリシーを使用して、ビューがカバーする期間を制限します。

• 具体化されたビュー クエリでは、 sort、 top-nested、 top、 partition、 serializeの演算子はサポートされていません。

• 複合集計は、具体化されたビューの定義ではサポートされていません。 たとえば、 SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Idを使用する代わりに、具体化されたビューを次のように定義 SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id。 クエリの表示中に、 MaterializedViewName | project Id, Result=a/bを実行します。 計算列 (a/b) を含むビューの必要な出力は、ストアド関数にカプセル化できます。 具体化されたビューに直接アクセスするのではなく、ストアド関数にアクセスします。

• external_table() と externaldata への参照はサポートされていません。

• 具体化されたビュー クエリには、偽装を必要とする吹き出しを含めることはできません。 具体的には、偽装を使用するすべてのクエリ接続プラグインは許可されません。

• ビューのソース テーブルに加えて、クエリは 1 つ以上の dimension テーブルを参照できます。 ディメンション テーブルは、ビュー プロパティで明示的に呼び出す必要があります。 ディメンション テーブルと結合するときは、次の動作を理解することが重要です。

  • ビューのソース テーブル (ファクト テーブル) のレコードは、1 回だけ具体化されます。 ディメンション テーブルの更新は、ファクト テーブルから既に処理されているレコードには影響しません。

  • ファクト テーブルとディメンション テーブルの間でインジェストの待機時間が異なると、ビューの結果に影響する可能性があります。

    例: ビュー定義には、ディメンション テーブルとの内部結合が含まれます。 具体化時には、ディメンション レコードは完全には取り込まれませんでしたが、ファクト テーブルに既に取り込まれます。 このレコードはビューから削除され、再び処理されることはありません。

    同様に、結合が外部結合の場合、ファクト テーブルのレコードが処理され、ディメンション テーブルの列に null 値で表示されるように追加されます。 ビューに既に追加されている (null 値を持つ) レコードは再び処理されません。 ディメンション テーブルの列の値は null のままです。

サポートされている集計関数

サポートされている集計関数は次のとおりです。

• count
• countif
• dcount
• dcountif
• min
• max
• avg
• avgif
• sum
• sumif
• arg_max
• arg_min
• take_any
• take_anyif
• hll
• make_set
• make_list
• make_bag
• percentile, percentiles
• tdigest

パフォーマンスに関するヒント

• datetime グループ化キーを使用する: グループ化キーの 1 つとして datetime 列を持つ具体化されたビューは、そうでないビューよりも効率的です。 理由は、datetime グループ化キーがある場合にのみ、一部の最適化を適用できることです。 datetime group-by キーを追加しても集計のセマンティクスが変更されない場合は、追加することをお勧めします。 これは、 datetime 列が一意のエンティティごとに 変更できない 場合にのみ実行できます。

  たとえば、次のような集計の場合です。

      SourceTable | summarize take_any(*) by EventId
  

  EventId常に同じTimestamp値を持っているため、Timestampを追加しても集計のセマンティクスが変更されない場合は、ビューを次のように定義することをお勧めします。

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  ヒント

  datetime グループ化キーの到着が遅れたデータは、具体化されたビューのパフォーマンスに悪影響を及ぼす可能性があります。 たとえば、具体化されたビューでグループ化されたキーの 1 つとして bin(Timestamp, 1d) が使用され、新しく取り込まれたレコードがソース テーブルに古い Timestamp 値があるとします。 これらのレコードは、具体化されたビューに悪影響を与える可能性があります。

  到着が遅れたレコードがソース テーブルに取り込まれると予想される場合は、具体化されたビューのキャッシュ ポリシーを適宜調整します。 たとえば、タイムスタンプが 6 か月前のレコードがソース テーブルに取り込まれると予想される場合、具体化プロセスでは、前の 6 か月間、具体化されたビューをスキャンする必要があります。 この期間がコールド キャッシュ内にある場合、具体化ではキャッシュ ミスが発生し、ビューのパフォーマンスに悪影響を及ぼします。

  このような到着遅延レコードが予期されない場合は、具体化されたビュー クエリで行うことをお勧めします。 これらのレコードをフィルター処理するか、タイムスタンプ値を現在の時刻に正規化します。

• ルックバック期間を定義する: シナリオに該当する場合、 lookback プロパティを追加すると、クエリのパフォーマンスが大幅に向上する可能性があります。 詳細については、「 ルックバック期間」を参照してください。

• グループ化キーとしてフィルター処理するために頻繁に使用される列を追加する: 具体化されたビューのクエリは、マテリアライズド ビューのグループ化キーのいずれかでフィルター処理されるときに最適化されます。 クエリ パターンが、マテリアライズド ビュー内の一意のエンティティに従って変更できない列でフィルター処理されることが多いことがわかっている場合は、具体化されたビューのグループ化キーに含めます。

  たとえば、具体化されたビューでは、多くの場合、arg_maxでフィルター処理されるResourceId値によってSubscriptionIdが公開されます。 ResourceId値が常に同じSubscriptionId値に属していると仮定して、具体化されたビュー クエリを次のように定義します。

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
  }
  

  上記の定義は、次よりも優先されます。

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by ResourceId 
  }
  

• 必要に応じて更新ポリシーを使用する: 具体化されたビューには、ディメンション テーブルの変換、正規化、および参照を含めることができます。 ただし、これらの操作を update ポリシーに移動することをお勧めします。 具体化されたビューの集計のみを残します。

  たとえば、次の更新ポリシーを定義することをお勧めします。

  .alter-merge table Target policy update 
  @'[{"IsEnabled": true, 
      "Source": "SourceTable", 
      "Query": 
          "SourceTable 
          | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
          | lookup DimResources on ResourceId
          | mv-expand Events
      "IsTransactional": false}]'  
  

  次の具体化されたビューを定義します。

  .create materialized-view Usage on table Events
  {
      Target 
      | summarize count() by ResourceId 
  }
  

  代わりに、マテリアライズド ビュー クエリの一部として更新ポリシーを含めると、パフォーマンスが低下する可能性があるため、推奨されません。

  .create materialized-view Usage on table SourceTable
  {
      SourceTable
      | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
      | lookup DimResources on ResourceId
      | mv-expand Events
      | summarize count() by ResourceId
  }
  

具体化されたビューをバックフィルする

backfill プロパティを使用して具体化されたビューを作成する場合、具体化されたビューはソース テーブルで使用可能なレコードに基づいて作成されます。 または、 effectiveDateTimeを使用する場合は、それらのレコードのサブセットに基づいて作成されます。

バックグラウンドでは、バックフィル プロセスによりデータが分割されて複数のバッチにバックフィルされ、いくつかの取り込み操作が実行されてビューがバックフィルされます。 ソース テーブル内のレコードの数が多い場合、プロセスの完了に時間がかかる場合があります。 プロセスの期間は、データベース サイズによって異なります。 .show operations コマンドを使用して、バックフィルの進行状況を追跡します。

バックフィル プロセス時に発生する一時的な失敗の場合は、再試行されます。 すべての再試行が使い果たされると、コマンドは失敗し、create コマンドを手動で再実行する必要があります。

ソース テーブル内のレコードの数が number-of-nodes X 200 million を超える場合 (クエリの複雑さに応じて、さらに少ない場合があります) は、バックフィルを使用しないことをお勧めします。 別の方法として、移動エクステントによる バックフィル オプションがあります。

コールド キャッシュ内のデータでは、バックフィル オプションの使用はサポートされていません。 必要に応じて、ビューの作成時にホット キャッシュ期間を長くします。 これにはスケールアウトが必要な場合があります。

ビューの作成でエラーが発生した場合は、次のプロパティを変更してみてください。

• MaxSourceRecordsForSingleIngest: 既定では、バックフィル中の各取り込み操作のソース レコードの数は、ノードあたり 200 万です。 このプロパティを目的のレコード数に設定することで、この既定値を変更できます。 (値は、各取り込み操作の 合計 レコード数です)。

  この値を小さくすると、メモリ制限やクエリタイムアウトで作成が失敗した場合に役立ちます。 この値を大きくすると、データベースが既定よりも多くのレコードに対して集計関数を実行できる場合に、ビューの作成を高速化できます。

• Concurrency: バックフィル プロセスの一部として実行される取り込み操作は、同時に実行されます。 既定では、コンカレンシーは min(number_of_nodes * 2, 5) です。 このプロパティは、コンカレンシーを増減するように設定できます。 データベースの CPU 使用率が低い場合にのみ、この値を増やすことをお勧めします。これは、増加がデータベースの CPU 消費量に大きく影響する可能性があるためです。

たとえば、次のコマンドは、 2020-01-01から具体化されたビューをバックフィルします。 各取り込み操作のレコードの最大数は 300 万です。 このコマンドは、 2のコンカレンシーを使用して取り込み操作を実行します。

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
} 

具体化されたビューに datetime グループ化キーが含まれている場合、バックフィル プロセスでは、datetime 列に基づく 拡張作成時刻 のオーバーライドがサポートされます。 これは、たとえば、古いレコードを最近のレコードより前に削除する場合に役立ちます。これは、 再入ポリシー がエクステントの作成時間に基づいているためです。 updateExtentsCreationTime プロパティは、ビューに、bin()関数を使用する datetime グループ化キーが含まれている場合にのみサポートされます。 たとえば、次のバックフィルでは、 Timestamp グループ化キーに基づいて作成時間が割り当てられます。

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
} 

エクステントの移動によるバックフィル

移動エクステントによるバックフィルオプションは、既存のテーブルに基づいて具体化されたビューをバックフィルします。これは、必ずしもマテリアライズド ビューのソース テーブルであるとは限りません。 指定したテーブルから基になる具体化されたビュー テーブルにエクステントを 移動 バックフィルを実現します。 このプロセスは、次のことを意味します。

• 指定したテーブル内のデータは、具体化されたビュー スキーマと同じスキーマを持つ必要があります。
• 指定したテーブル内のレコードは、そのままビューに移動されます。 これらは、具体化されたビューの定義に基づいて重複除去されると見なされます。

たとえば、具体化されたビューに次の集計があるとします。

T | summarize arg_max(Timestamp, *) by EventId

その後、移動エクステント操作のソース テーブル内のレコードは、既に EventID によって重複除去されている必要があります。

操作では .move エクステントが使用されるため、バックフィル中に指定したテーブルからレコードが 削除されます (移動され、コピーされません)。

移動エクステントによるバックフィルは、 具体化されたビューでサポートされているすべての集計関数ではサポートされていません。 ビューに格納されている基になるデータが集計自体と異なる avg()、 dcount()などの集計では失敗します。

具体化されたビューは、指定されたテーブルに基づいて ''のみ'' バックフィルされます。 ビューのソース テーブル内のレコードの具体化は、既定ではビューの作成時刻から開始されます。

具体化されたビューのソース テーブルがデータを継続的に取り込む場合、移動エクステントを使用してビューを作成すると、データが失われる可能性があります。 これは、ソース テーブルに取り込まれたレコードが、バックフィル元のテーブルを準備してからビューが作成されるまでの短い時間に、具体化されたビューに含まれていないためです。 このシナリオを処理するには、ソース テーブルに対する具体化されたビューの開始日時に source_ingestion_time_from プロパティを設定します。

ユース ケース

移動エクステントによるバックフィルのオプションは、次の 2 つの主なシナリオで役立ちます。

• 具体化されたビューの重複除去されたソース データを含むテーブルが既にあり、マテリアライズド ビューのみを使用しているため、ビューの作成後にこのテーブルにこれらのレコードが必要ない場合。

• 具体化されたビューのソース テーブルが非常に大きく、ソース テーブルに基づくビューのバックフィルが、前述の制限のためにうまく機能しない場合。 この場合は、クエリ コマンドから最も を使用して、バックフィル プロセスを一時テーブルに調整できます。 一時テーブルにバックフィルのすべてのレコードが含まれている場合は、そのテーブルに基づいて具体化されたビューを作成します。

例:

• 次の例では、テーブル DeduplicatedTable には、 EventId インスタンスごとに 1 つのレコードが含まれており、具体化されたビューのベースラインとして使用されます。 具体化されたビューには、ビューの作成後に取り込まれる T 内のレコードのみが含まれます。

  .create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  } 
  

• effectiveDateTime プロパティが move_extents_from プロパティと共に指定されている場合、DeduplicatedTable値が MaxCreatedOn より大きいeffectiveDateTime内のエクステントのみがバックフィルに含まれます (具体化されたビューに移動されます)。

  .create async materialized-view with 
      (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
      MV on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  } 
  

• 次の例では、移動エクステントによるバックフィルオプションで source_ingestion_time_from プロパティを使用する方法を示します。 source_ingestion_time_fromとmove_extents_fromの両方を使用すると、具体化されたビューが 2 つのソースからバックフィルされることを示します。

  • move_extents_from テーブル: 次の例でDeduplicatedTableします。 このテーブルには、バックフィルするすべての履歴データが含まれている必要があります。 必要に応じて、effectiveDateTime プロパティを使用して、DeduplicatedTable値がMaxCreatedOnより大きいエクステントのみをeffectiveDateTimeに含めることができます。

  • 具体化されたビューのソース テーブル: 次の例で T 。 このテーブルのバックフィルには、 ingestion_time() 値が source_ingestion_time_fromより大きいレコードのみが含まれます。

    source_ingestion_time_from プロパティは、(DeduplicatedTable) からバックフィルするテーブルを準備してからビューが作成されるまでの短い時間で、データ損失の可能性を処理するためにのみ使用する必要があります。 このプロパティは、過去にあまり大きく設定しないでください。 そうすると、具体化されたビューが大幅に遅れ、追いつくのが難しい場合があります。

  次の例では、現在の時刻が 2020-01-01 03:00されていると仮定します。 テーブル DeduplicatedTable は、T の重複除去されたテーブルです。 これには、2020-01-01 00:00 まで重複除去されたすべての履歴データが含まれます。 create コマンドは、移動エクステントを使用して具体化されたビューをバックフィルするためにDeduplicatedTableを使用します。 create コマンドには、T以降に取り込まれた2020-01-01内のすべてのレコードも含まれます。

  .create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  } 
  

具体化されたビューの作成を取り消す

バックフィル オプションを使用している場合は、具体化されたビューの作成プロセスをキャンセルできます。 このアクションは、作成に時間がかかりすぎて、実行中に停止したい場合に便利です。

作成プロセスをすぐに取り消すことはできません。 cancel コマンドは具体化を停止するように通知します。作成時には、取り消しが要求されたかどうかが定期的に確認されます。 cancel コマンドは、具体化されたビューの作成プロセスが取り消されるまで最大 10 分間待機します。 取り消しが成功したかどうかを報告します。

取り消しが 10 分以内に成功せず、キャンセル コマンドによってエラーが報告された場合でも、具体化されたビューは作成プロセスの後半でキャンセルされる可能性があります。 .show operations コマンドは操作が取り消されたかどうかを示します。

.cancel operation コマンドの発行時に操作が進行中でなくなった場合、コマンドはエラーを報告します。

構文

.cancel operation operationId

構文規則について詳しく知る。

パラメーター

出力

例

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

取り消しが 10 分以内に完了しなかった場合、 CancellationState は失敗を示します。 その後、作成を取り消すことができます。

関連コンテンツ

• 具体化されたビュー
• 具体化されたビューのユース ケース
• .alter materialized-view
• .drop materialized-view
• .show materialized-view(s)