論理的な削除の概要

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

個々のレコードを削除する機能がサポートされています。 レコードの削除は、通常、次のいずれかの方法を使用して実行されます。

• これらのレコードを含むストレージ成果物も削除されることをシステムが保証するレコードを削除するには、 .purge
• このような保証なしでレコードを削除するには、この記事の説明に従って .delete を使用します。このコマンドはレコードを削除済みとしてマークしますが、必ずしもストレージ成果物からデータを削除するとは限りません。 この削除方法は、消去よりも高速です。

コマンドの使用方法については、「 Syntax」を参照してください。

ユース ケース

この削除方法は、個々のレコードの計画外の削除にのみ使用する必要があります。 たとえば、IoT デバイスで破損したテレメトリが一部の時間報告されている場合は、この方法を使用して破損したデータを削除することを検討する必要があります。

重複除去または更新のためにレコードを頻繁に削除する必要がある場合は、具体化されたビューを使用することをお勧めします。 「データの重複除去について具体化されたビューか論理的な削除のいずれかを選択する」を参照してください。

削除プロセス

論理的な削除プロセスは、次の手順を使用して実行されます。

1. 述語クエリの実行: テーブルがスキャンされ、削除するレコードを含むデータ エクステントが識別されます。 識別されるエクステントは、述語クエリによって返される 1 つ以上のレコードを持つエクステントです。
2. エクステントの置換: 識別されたエクステントは、元のデータ BLOB を指す新しいエクステントに置き換えられ、レコードごとに削除されたかどうかを示す bool 型の新しい非表示列を持っています。 完了後、新しいデータが取り込まれなかった場合に、もう一度実行しても述語クエリからレコードは返されません。

制限と考慮事項

• 削除プロセスは最終処理であり、元に戻すことはできません。 操作後にストレージ成果物が削除されない場合もありますが、このプロセスを元に戻したり、削除されたデータを復旧したりすることはできません。

• ネイティブ テーブルと具体化されたビューでは、論理的な削除がサポートされています。 外部テーブルではサポートされていません。

• 論理的な削除を実行する前に、クエリを実行し、結果が予想される結果と一致しているかどうかを確認して、述語を検証します。 whatif モードでコマンドを実行することもできます。このモードでは、削除される予定のレコードの数が返されます。

• 同じテーブルに対して複数の論理的な削除を並列で実行しないでください。これにより、一部またはすべてのコマンドでエラーが発生するおそれがあります。 ただし、異なるテーブルに対して複数の論理的な削除操作を並列で実行することはできます。

• 同じテーブルに対して、論理的な削除および消去コマンドを並列で実行しないでください。 最初に 1 つのコマンドが完了するまで待ち、もう一方のコマンドを実行します。

• 論理的な削除は、クラスター URI ( https://[YourClusterName].[region].kusto.windows.net) に対して実行されます。 このコマンドを実行するには、関連するデータベースに対するデータベース管理者のアクセス許可が必要です。

• 具体化されたビューのソース テーブルであるテーブルからレコードを削除すると具体化されたビューに影響する可能性があります。 削除されたレコードがまだ 具体化サイクルによって処理されていない場合これらのレコードは処理されないため、ビューに表示されません。 同様に、レコードが既に処理されている場合、削除は具体化されたビューには影響しません。

• 述語の制限事項:

  • 少なくとも 1 つの where 演算子を含む必要があります。
  • レコードの削除元のテーブルのみを参照できます。
  • 使用できるのは、 extend、 order、 project、 take 、 whereの各演算子のみです。 toscalar()内では、summarize演算子も使用できます。

削除のパフォーマンス

削除プロセスのパフォーマンスに影響する可能性がある主な考慮事項は次のとおりです。

• 述語クエリの実行: この手順のパフォーマンスは、述語自体のパフォーマンスと非常に似ています。 述語によっては若干速かったり遅かったりする場合がありますが、違いは重要ではないと予想されます。
• エクステントの置換: この手順のパフォーマンスは、次によって異なります。
  • クラスター内のデータ エクステント全体のレコード分布
  • クラスター内のノードの数

.purge とは異なり、.delete コマンドにより、データは再び取り込まれません。 述語クエリによって返されたレコードが削除済みとしてマークされるだけなので、はるかに高速になります。

削除後のクエリのパフォーマンス

レコードの削除後に、クエリのパフォーマンスが大きく変化することは想定されません。

削除されたレコードを除外するすべてのクエリに自動的に追加されるフィルターが効率的であるため、パフォーマンスの低下は予想されません。

ただし、クエリのパフォーマンスが向上する保証もありません。 パフォーマンスの向上は、一部の種類のクエリで発生する可能性があります。一部のクエリでは発生しない場合があります。 クエリのパフォーマンスを向上させるために、ほとんどのレコードが削除されるエクステントは、削除されていないレコードのみを含む新しいエクステントに置き換えることで、定期的に圧縮されます。

COGS (売却済商品の原価) への影響

ほとんどの場合、レコードを削除しても COGS は変更されません。

• 実際にはレコードが削除されないので、減少はありません。 レコードは、bool 型の非表示列を使用して削除済みとしてマークされるだけで、そのサイズはごくわずかです。
• ほとんどの場合、.delete 操作で追加のリソースをプロビジョニングする必要はないので、増加はありません。
• 場合によって、大部分のレコードが削除されるエクステントは、削除されていないレコードのみを含む新しいエクステントに置き換えることで、定期的に圧縮されます。 これにより、削除されたレコードが多数含まれる古いストレージ成果物が削除されます。 新しいエクステントはより小さいため、ストレージ アカウントとホット キャッシュの両方で消費容量は少なくなります。 ただし、ほとんどの場合、COGS に対するこの影響はごくわずかです。