論理的な削除の概要

データ プラットフォームとして、Azure Data Explorer は、個々のレコードを削除する機能がサポートしています。 レコードの削除は、通常、次のいずれかの方法を使用して行われます。

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

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

ユース ケース

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

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

削除プロセス

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

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

制限と考慮事項

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

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

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

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

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

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

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

• 述語の制限事項:

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

削除のパフォーマンス

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

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

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

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

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

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

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

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

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

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