Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

データパージ

データパージとは

データパージは、非アクティブなレコードや古くなったレコードをデータベースから完全に削除するメカニズムです。増加速度が明らかに速く、短期間でかなりのデータ量に達する可能性があるエンティティについて、これを検討する必要があります。すべてのパージ戦略は、ビジネス要件や法的要件に応じて常に調整する必要があります。

この記事では、主にデータベースのエンティティからのデータパージについて説明しますが、ファイルシステムやメールなどのその他のタイプのストレージでも同様の方法を検討することができます。

メリット

パージ戦略の主なメリットは、実行時のパフォーマンス省コストの2つです。

非アクティブなデータや古いデータをシステム内で保持していると、ファイルストレージ領域を消費してシステムパフォーマンスの維持に必要な物理リソース(データベースのメモリや計算能力)が増え、データベースのバックアップや保守が複雑になります。これらはすべて、不必要で高額なハードウェアアップグレードにつながるおそれがあります。

データパージのベストプラクティス

このセクションでは、パージメカニズムのベストプラクティスとして利用することができるデータパージの実装例を示します。

データを準備する

パージアルゴリズムを実装するために必要な情報をデータモデルに確実に含めるため、コントロール列をエンティティに追加してパージ条件を適用できるようにすることが推奨されます。

たとえば、更新タイムスタンプが(サイトプロパティを使用して指定された)しきい値の日数を超過しているすべてのレコードを削除するという条件や、ブーリアン型のコントロール列に基づいてすべてのレコードを削除するという条件があります。

以下は、使用可能なコントロール列の例です。ユースケースに合うものを選んだり、その他のものを追加して適用したりすることができます。

  • LastUpdatedOn(DateTime型): レコードの最終更新時刻を追跡します。(たとえば、サイトプロパティを使用して定義された)タイムスタンプに基づいてレコードをパージするときに使用します。

  • IsActive(ブーリアン型): レコードをアクティブまたは非アクティブとしてマークします。非アクティブなレコードは後でパージできます。

  • IsDeleted(ブーリアン型): 後で削除するレコードをマークします(ソフトデリート)。後で効率的にレコードを削除(パージ)したり復元したりできます。

  • IsDraft(ブーリアン型): 未確定のデータがある場合など、ドラフトのシナリオの場合に便利です。かなり前に作成されたドラフトが最近更新されていない場合など、このフラグを使用してパージするデータを識別することができます。

パージメカニズムを実装する

タイマーを使用してパージプロセスを設定し、パージ条件に基づき、特定のエンティティからレコードを非同期的に削除することができます。パフォーマンス上の理由とタイムアウトの防止のため、パージはグループ単位または一括処理で実行する必要があります。

以下は、パージプロセスロジックの例です。

  1. パージのしきい値を設定する - 繰り返しでパージするレコード数を設定します。このしきい値はサイトプロパティを使用して定義できるため、モジュールを再デプロイせずに調整することができます。

  2. CheckRecordsToPurge - パージするレコードが残っているかどうかを検証します。

  3. パージするレコードがあるか- 前のクエリの出力を検証し、パージするレコードがある場合はパージブランチを実行します。

  4. PurgeRecordsInBulk - 一括DELETEステートメントを実行します。このとき、句を使用して(手順1で設定したパージのしきい値を使用して)パージされるレコード数を制限します。これにより、パージ条件がを実装されます。

  5. WakePurgeData - タイマーを再起動して、パージするレコードがまだあるかどうかを確認します。

様々なエンティティからデータをパージするため、システム全体で複数のタイマーが必要な場合があります。タイマーごとにパージ条件を設定し、そのエンティティに関連付けられたユースケースと連携させます。

一般的なリスクシナリオ

パージ戦略がない

一般的なシナリオとして、アプリケーションデータの大幅な増加が適切に見込まれていなかったために、データパージ戦略が不足している場合があります。この場合、アプリケーションパフォーマンスが徐々に低下する可能性があります。

ビジネス知識と既存のメトリックに基づき、設計フェーズ中にデータの増加を予測します。十分な情報がない場合は慎重に対応し、データの増加量を多めにして検討します。

アプリケーションパフォーマンスが低下するシナリオを防ぐには、アプリケーションパフォーマンス(LifeTime Analyticsなどを使用)とデータベースの増大を定期的に監視し、必要に応じてデータパージメカニズムの実装を検討します。

参照整合性戦略がない

データパージメカニズムを実装する際は、削除フローの順番に直接影響を及ぼすため、モデル内のエンティティ間の関係に対して定義された参照整合性(削除規則)を考慮する必要があります。

エンティティモデルの設計フェーズで、データパージ要件を考慮した複数の関係に対して削除規則の設定を行わなかった場合、パージの実装の維持が複雑で困難になる可能性があります。

Protectを使用する方法
モデル内のすべてのエンティティの関係でDelete Ruleをデフォルト値のProtectのままにした場合、データパージフローがより複雑になったり、不適切な順序でレコードを削除しようとするとデータベース例外が発生したりします。
カスケード削除を使用する方法
Delete RuleDelete(カスケード削除動作)に設定した場合、メインレコードを削除したときにすべての関連レコードが自動的に削除されるため、パージの実装のメリットが最も大きくなります。そのため、データパージの実装を簡略化するため、できる限りカスケード削除規則を使用するようにエンティティモデルを設計する必要があります。一方で、各ユースケースで想定されるシステム動作に配慮するようにしてください。
Ignoreを使用する方法
Delete RuleIgnoreに設定した場合、レコードをメインエンティティから削除し、関連レコードをすべて保持することができます。この方法を使用するとデータパージフローが円滑化されますが、データモデルで不整合が発生する可能性があるため、慎重に使用してください。コンプライアンス上の目的で関連するレコードのみを保持する必要がある場合は、メインレコードの詳細情報の取得や表示はできなくなることに留意してください。

一時データをパージしない

一時データは、すべて定期的にパージする必要があります。ビジネスコンセプトとマスターデータが特定され次第、各プロジェクトでこれらのパージメカニズムについて話し合う必要があります。

以下は、パージが必要な一時データの例です。

  • アクティブではなくなったユーザー - ユーザーを削除する場合は、関連データを慎重に処理してください。Delete RuleDeleteではなくIgnoreに設定した場合、ユーザーの詳細情報の取得や表示はできなくなります。

  • オンライン登録プロセスを開始したものの、プロセスを完了しなかったユーザー - この場合、ユーザーを見込みユーザーとして一定時間保持した後にパージすることがあります。関連するメトリックを外部ソースと同期した後にパージを実行します。

パージスケジュールが適切でない

エンドユーザーに対して提供されるWebリクエストへの影響を最小限にするため、パージプロセスはオフピーク時に実行する必要があります。

データベース保守計画がない

データベースの全体的な正常性にとって保守計画は特に重要です。保守計画では、DB統計とインデックスの定期的な再構築やディスク領域の解放などの多くの重要なルーチン作業を確実に行うようにします。

データパージプロセス中に削除される大量のデータを考慮し、データベース保守計画をパージメカニズムと連携させることが重要です。データベース管理者と相談して、パージのニーズに適した保守計画を作成するようにします。

  • Was this article helpful?