Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

データアーカイブ

データアーカイブとは

データアーカイブは、長期間保存するデータを特定し、プライマリストレージからセカンダリストレージへ移動するプロセスです。アーカイブの対象となるデータには、日常業務には関係しなくなったものの組織にとってまだ重要であり、将来参照が必要になる可能性のあるデータや、規制準拠のために保持する必要があるデータが含まれます。

データアーカイブは、大量のデータを処理している場合に重要な作業であり、起こりうるパフォーマンスへの影響の軽減に役立ちます。

この記事では、プライマリストレージをメインカタログと呼び、セカンダリストレージをアーカイブカタログと呼びます。

メリット

データアーカイブ戦略がもたらすエンドユーザー側の主なメリットは、実行時のパフォーマンスです。メインカタログ内のデータ量が減るため、クエリの実行時間が短縮し、アプリケーションの反応が速くなります。

IT部門側の主なメリットは、必要なリソースのパフォーマンス省コストです。メインカタログ内のデータ量が減るため、バックアップ操作とリカバリ操作が速くなり、ディザスタリカバリのコストと所要時間が減り、潜在的なシステムダウンタイムが短縮します。(OutSystemsデータベースの代わりに)アーカイブされた情報を保存する専用のアーカイブシステムを使用すると、全体的なストレージコストを減らすことができます。

データアーカイブのベストプラクティス

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

データを準備する

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

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

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

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

  • IsActive(ブーリアン型): レコードをアクティブまたは非アクティブとしてマークします。非アクティブなレコードをアーカイブするかどうかの決定については、会社で話し合う必要があります。

  • IsArchived(ブーリアン型): すでにアーカイブされたレコードをマークします。これらのレコードは後でメインカタログからパージできます。

  • IsDraft(ブーリアン型): 未確定のデータがある場合など、ドラフトのシナリオの場合に便利です。このフラグを使用して、不完全なデータがアーカイブされないようにします。

アーカイブメカニズムを実装する

アーカイブされたレコードをすぐ利用できるようにしておく必要があるかどうかに応じて、2種類のアーカイブ方法を検討する必要があります。

  • 軽量アーカイブ: アーカイブされたデータをアーカイブされていないデータとともに検索したり表示したりできます。

  • 履歴アーカイブ: アーカイブされたデータへのアクセスはできず、監査用や履歴用としてのみ使用できます。

軽量アーカイブ

アーカイブされたデータをアーカイブカタログ内で検索可能にし、最終的にメインカタログへのリカバリが必要な場合は、この方法を検討する必要があります。

このセクションでは、メインアプリケーションおよびプロセスへの影響を最小限に抑え、OutSystemsでの実装や保守が容易な軽量アーカイブのアーキテクチャとメカニズムについて詳しく説明します。

手順1. メインモジュールとメインカタログエンティティをミラーリングするアーカイブカタログを作成する

メインカタログ内のデータソースモジュールを特定します。

  • アーカイブするメインエンティティを特定します。

  • メインエンティティにIsArchivedアトリビュートを追加します。

  • 詳細なエンティティで適切な削除規則を選択します。

  • IsArchivedアトリビュートにインデックスを追加します。

アーカイブカタログ側のデータソースモジュールを、マッピングや更新がしやすい方法でミラーリングします。

  • エンティティのみをコピーします。

  • ID、インデックス、IsArchivedアトリビュートのIs AutoNumberプロパティを「No」に設定します。

  • 外部キーのDelete Ruleプロパティを「Ignore」に設定します。

  • アーカイブの検索基準に基づいてインデックスを追加します。

影響を最小限に抑えるには、異なるテーブルスペースやディスクにスキーマを設定します(オンプレミスインストールの場合は、複数データベースカタログおよびスキーマ機能を利用できます)。

手順2. メインデータをアーカイブカタログに保存するためのアーカイブプロセスを実装する新しいモジュールを作成する

このモジュール(例: 「Archiving Engine」)には、以下のようなすべてのアーカイブおよびパージロジックを実装します。

  • アーカイブ基準ビジネスルール。

  • ソースエンティティ内のデータをアーカイブカタログにミラーリングする定期的なアーカイブプロセス。

  • アーカイブされたデータの定期的なパージ。

  • 参照によるアーカイブされたデータの復元。

アーカイブの頻度やしきい値などの簡単な構成は、サイトプロパティを使用して指定することができ、Service Centerコンソールを使用して実行時にそれらを更新することができます。より複雑なアーカイブメカニズムの構成が必要な場合は、専用のバックオフィスを実装する必要があります。

3. 検索機能と復元機能をエンドユーザーに公開する新しいモジュールを作成する

このモジュール(例: 「Archive Search」)には、エンドユーザーがアーカイブされたデータを操作できるようにするUIを実装します。

  • アーカイブされたデータをメインカタログに復元します。
  • アーカイブエンティティ内のデータを直接検索します。

データ量が多いため、アーカイブカタログのパフォーマンスはメインカタログより劣ります。レスポンスタイムに関するエンドユーザーの期待を管理するには、エンドユーザーがアーカイブされたデータを操作するかどうかを明示的に設定する必要があるトグルを実装します。

手順4. アーカイブプロセスを非同期的に実行するためのタイマーを作成する

「Archiving Engine」モジュールに実装されたアーカイブプロセスを実行するタイマーを作成します。

以下は、アーカイブプロセスロジックの例です。

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

  2. CheckRecordsToArchive - アーカイブするレコードが残っているかどうかを検証します。

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

  4. MoveIntoArchiveCatalog_InBulk - メインカタログからアーカイブカタログへの一括INSERT INTO SELECTステートメントを実行します。このとき、句を使用して(手順1で設定したアーカイブのしきい値を使用して)アーカイブされるレコード数を制限します。これにより、アーカイブ条件が実装されます。

  5. MainCatalog_SetArchivedFlag_InBulk - 一括更新を実行して、前の手順でアーカイブされたレコードのIsArchivedフラグを設定します。

  6. WakeArchiveData - タイマーを再起動して、アーカイブするレコードがまだあるかどうかを確認します。

タイマーは次のように構成してください。

  • オフピーク時に実行するようにスケジュールを設定します。
  • エラー時の回復機能を用意します。
  • 繰り返しの処理を避けます。

最適化のヒント: 開始時はアーカイブのインデックス化をオフにし、後でインデックスを再構築します。この最適化はOutSystemsのデフォルトでは設定されておらず、データベース管理者のサポートが必要な場合があります。

手順5. アーカイブされたデータをメインカタログからパージする

アーカイブ済みのデータをメインカタログから削除します。独立したログ実行タイマーを使用して独自のスケジュールを設定し、オフピーク時に実行します。

詳細については、データパージのベストプラクティスをご覧ください。

履歴アーカイブ

履歴や法律上の必要性からデータをアーカイブし、これらのデータが必要になることがほとんどない場合は、この方法を検討する必要があります。

手順1. 複数のOutSystemsアプリケーションのアーカイブとして機能する一元的な開発インフラコンポーネントを作成する

このコンポーネント(例: 「Archive_Lib」)は、開発インフラ内の複数のOutSystemsアプリケーションにわたって一元的な汎用アーカイブカタログリポジトリとして使用されます。

アーカイブされたレコードはメタデータアトリビュート(タグ)とともにJSON形式で保存され、一連の自己完結型画面で検索したり取得したりできます。以下は、コンポーネントの仕様案です。

このソリューションを使用すると、アーカイブリポジトリをエンティティごとに設計・管理しなくてすみます。一方で、この方法を使用すると、アーカイブされたエンティティの同一グループにすべてのデータをアーカイブすることを考慮する必要があります。これらは増加するため、監査が目的の場合でもパフォーマンスのボトルネックになる可能性があります。保守コストはかかりますが、アーカイブコンポーネントのクローンをビジネスアプリケーションのセットごとに1つずつ作成することができます。

手順2. 各OutSystemsアプリケーションで、中央アーカイブによるアーカイブプロセスを実装する

中央アーカイブへのレコードの移動は、各ビジネスアプリケーションで行います。アーカイブ基準はアプリケーションごとに変えることができます(非アクティブなレコード、最終更新タイムスタンプ、作成日など)。

ただし、アーカイブにレコードを追加するたびに、同じトランザクションスコープでデータを元の場所からパージし、データが失われないようにする必要があります。

アーカイブの場所

この記事では、OutSystemsデータベースを使用してアーカイブ戦略を実現する方法を主に説明します。オンプレミスインストールの場合は、複数データベースカタログおよびスキーマ機能を利用して専用のデータベースカタログでアーカイブメカニズムを構成する必要があります。

OutSystems以外でデータをアーカイブする場合は、データレイクやクラウドストレージサービスなどの複数のソリューションが市場で提供されています。OutSystemsはエンタープライズアーキテクチャに応じて、既存のシステムと容易に連携することができます。

一般的なリスクシナリオ

アーカイブ戦略がない

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

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

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

アーカイブポリシーが適切でない

データをアーカイブする周期が適切でない場合、メインカタログ内に不要なデータが残り、メインカタログ全体のパフォーマンスに影響を及ぼします。

また、データの増加パターンが異なるにもかかわらず、すべてのエンティティに同じアーカイブポリシーを適用している場合もよくあります。

ビジネス要件を話し合ってより効果的なアーカイブポリシーを決定し、各エンティティのライフサイクルに応じて異なるアーカイブポリシーを検討するようにします。

アーカイブカタログにインデックスがない

アーカイブカタログには大量の情報が保存されており、参照される頻度はメインカタログほど多くありません。一般的に、アーカイブにクエリを実行して情報を取得するのは時間がかかるとエンドユーザーから認識されているため、開発チームはアーカイブエンティティの最適化を行わない傾向があります。

しかし、適切なインデックスの構築などの最適化を行っていない場合、エンドユーザーエクスペリエンスが徐々に低下し、最終的にタイムアウトが発生してエンドユーザーが情報を取得できなくなる可能性があります。

アーカイブカタログの最適化を常に維持し、できる限り速く情報を返すようにします。

パージをせずにアーカイブしている

アーカイブカタログにパージ戦略がない場合、データが増加するとアーカイブカタログの速度が低下します。

アーカイブされたデータが不要になったら、パージする必要があります。詳細については、「データパージ」をご覧ください。

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

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

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

  • Was this article helpful?