スケジュールされたアプリケーションがあり、別のデータベース テーブルからデータを取得し、メイン アプリケーション データベース テーブルにダンプします。このテーブルのレコード数は毎日増加し、発生するトランザクション イベント データであるため、毎日増加すると想定しています。このデータは、各レコードを取得して必要な分析を行い、各レコードを処理済みとしてマークするメイン アプリケーションによる処理に使用されます。
将来的にデータベースのサイズを抑えるために、どのようなソリューションを提供できますか?
この状況であなたならどうしますか？
いくつかのエンタープライズ アプリケーションを観察したところ、ユーザーが「60 日より古い」レコードなどをテキスト ファイルにアーカイブできるオプションが提供されました。処理されたレコードをテキスト ファイルにアーカイブするオプションを提供し、データベースからレコードを削除します。テキスト ファイルは後で必要に応じてインポートできますか? これは解決策ですか？
あなたの会社にはどのような過去のデータ報告のニーズがありますか？アーカイブされたデータをテキストファイルにドロップすることは、将来そのデータからレポートできるようにする必要がないことを前提として、すべてうまくいきます。ただし、テキストファイルに含めるということは、必要なときにオンデマンドでデータベースにインポートするための手動プロセスが必要になることを意味します。
より良いオプションは、アーカイブデータをトランザクション処理（OLTP）に使用されず、代わりに分析処理データベース（OLAP）の基盤として使用されるデータウェアハウスデータベースに移動することです。このアーカイブされたデータを報告するときが来たら、準備は完了です。このアーカイブデータベースでデータを構造化する方法に注意する場合は、すべてのデータをOLAPキューブに集約するのが非常に簡単であるはずです。これにより、そのデータからのレポートがはるかに高速かつ柔軟になります。
しかし、繰り返しになりますが...データを報告するかどうか、およびその報告がどれだけ過去にさかのぼるかによって異なります。
その古いデータに時々アクセスする必要がある場合、それをテキストにアーカイブしてからテキストからロードするプロセスを構築することは、おそらく優れたソリューションではありません。ハードディスクは安いです。
古いデータを集計できます。たとえば、現在トランザクション データがミリ秒単位であるが、古いデータをレポートするときにそれを日単位で取得する場合、アーカイブ プロセスとしてデータを「日単位」に集約することを検討してください。数十万行を毎日数行に折りたたむことができる場合があります。
また、新しいディスクを簡単に追加してそれらのディスクにテーブルを作成できるプロセスで、最新のトランザクションを 1 つのディスク セットに保持し、アーカイブされたデータを他のディスクに保持できる適切なパーティション分割スキームも検討してください。
過去のデータをどこまで分析するかにもよりますが、パフォーマンスを落とさずにデータベースに残しておく方法があります。
頭に浮かぶ解決策は、問題のテーブルを分割することです。私の会社には、月ごとに分割されたデータを含むデータベース テーブルがあり、各テーブルには約 2,000 万行が含まれています。パーティショニングにより、このデータを単一のテーブルに格納するよりもはるかに実用的に使用できます。現在、唯一の実際の制約はディスク容量です。これは、最近の安さを考えると問題ではありません。
ただし、一部のデータベースではパーティショニングがサポートされていないことはわかっています。この場合、データを区切りファイルに保存するのが適切な解決策になると思います。
私見、それはユーザーが過去のデータを分析する必要がある可能性に依存します。可能性が高い場合は、適切なインデックスを作成し、すべてのデータをメイン データベースに保持してください。
そうでない場合は、TXT にドロップします。もちろん、それが発生する時間は構成可能でなければなりません。