データの保持と削除

保持はイベント契約の一部です。テーブルがどのくらいの期間有用であるか、テーブルにどの識別子が含まれるか、法的義務や顧客との約束により実稼働データを送信する前にライフサイクルを短縮する必要があるかどうかを決定します。

テーブルごとに保持を設定する

異なる目的を持つテーブルが 1 つの偶然のポリシーを継承しないようにしてください。大量の運用イベントには、少量の請求マイルストーンや監査記録よりも短い期間が必要な場合があります。

Tables API を使用して、保持期間を設定またはクリアします。

curl -X PATCH https://api.telemetry.sh/tables/api_requests/retention \
  -H "Authorization: Bearer $TELEMETRY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "retention_days": 30 }'

の テーブル API リファレンス 現在のリクエストとレスポンスの契約を文書化します。

行またはテーブルを削除する

選択的削除では、影響を受ける保存データが非同期的に再書き込みされます。テーブル全体を削除すると、クリーンアップの進行中にテーブルが通常の使用から削除されます。削除は破壊的であるため、最初に読み取り専用クエリを使用して正確なテーブルと述語を解決します。

SELECT COUNT(*) AS rows_to_delete
FROM product_events
WHERE account_id = 'account_123';

次に、「」で説明されているサポートされている削除エンドポイントを使用します。 API 参照の削除。削除リクエストを担当するシステム内にターゲットテーブル、述語、リクエスタ、承認、および完了の証拠を保持します。プライベート行の内容をそのレコードにコピーしないでください。

削除可能性を考慮した設計

テーブルがサブジェクトレベルの削除をサポートする必要がある場合は、安定した不透明なアカウントおよびユーザー識別子を使用してください。自由形式のテキストと一貫性のない識別子により、該当するすべての行を安全に見つけることが困難になります。

そもそも、シークレット、支払いデータ、リクエスト本文、または生のプロンプトを送信することは避けてください。削除はデータの最小化に代わるものではありません。

ライフサイクルを確認する

保持期間を変更した後、テーブルのメタデータを取得し、保存されているポリシーを確認します。削除後、操作が完了するまで正確な述語をクエリします。削除された履歴を予期していたダッシュボードと保存されたクエリを検証します。

新しい識別子、イベント ソース、リージョン、または顧客コミットメントが導入された場合は、保持を確認します。続けて 機密データの秘匿化 そして パーティション列.