2

アプリケーションからのログ エントリを格納するデータベース内のテーブルを設計しています。このデザインについていつも以上に考えさせられることがいくつかあります。

  • ただし、これらのログ エントリは実行時にシステムが決定を下すために使用されるため、比較的高速にアクセスできる必要があります。
  • 彼らはまた、彼らの数が多くなるという問題を抱えています（私の見積もりでは、毎月1250万人が追加されています）.
  • 決定処理には、せいぜい過去 30 日から 45 日以上は必要ありません。
  • サポートと法的な問題のために、それらすべてを 45 日よりずっと長く、おそらく少なくとも 2 年間保持する必要があります。
  • テーブルの設計は非常に単純で、すべて単純な型 (blob などはありません) であり、可能な場合はデータベース エンジンを使用して既定のデータ (多くても 1 つの外部キー) を配置します。
  • 違いがある場合、データベースは Microsoft SQL Server 2005 になります。

私が考えていたのは、それらをライブテーブル/データベースに書き込んでから、ETLソリューションを使用して「古い」エントリをアーカイブテーブル/データベースに移動することです。これは大きく、低速のハードウェア上にあります。

私の質問は、これが可能な限りうまく機能することを確認するためのデータベース/テーブルの設計に関するヒント、トリック、または提案を知っていますか? また、それが悪いアイデアだと思う場合は、私に知らせてください。より良いアイデアは何であると思いますか。

4

4 に答える 4

3

一部のデータベースは「パーティション」を提供します (Oracle など)。パーティションは、同じ定義を持つ複数のテーブルを 1 つにまとめたビューのようなものです。新しいデータをさまざまなテーブルに並べ替える基準を定義できます (たとえば、月または週 %6)。

ユーザーの観点からは、これは 1 つのテーブルにすぎません。データベース PoV から見ると、それはいくつかの独立したテーブルであるため、完全なテーブル コマンド (切り捨て、ドロップ、テーブルからの削除 (条件なし)、ロード/ダンプなど) を効率的な方法で実行できます。

パーティションを作成できない場合は、ビューで同様の効果が得られます。この場合、複数のテーブルを 1 つのビューに収集し、このビューを月に 1 回再定義して、古いデータを含む 1 つのテーブルを残りから「解放」することができます。これで、このテーブルを効率的にアーカイブし、クリアして、大きな作業が完了したときにビューに再度アタッチすることができます。これは、パフォーマンスの向上に大きく役立つはずです。

[編集] SQL Server 2005 以降 (Enterprise Edition) はパーティションをサポートしています。ミッチ・ウィートに感謝

于 2009-01-28T09:36:28.083 に答える
1

大きなテーブルはすぐに遅くなり、ETL を使用して大きなテーブルから日付に基づいてデータを取得し、古い行を削除すると、パフォーマンスのオーバーヘッドが大きくなります。これに対する答えは、複数のテーブルを使用することです。数値に基づいて、おそらく 1 つのテーブル/月です。もちろん、クエリ内でテーブル名を生成するためのロジックが必要になります。

Triggers を使用して「CurrentMonthAudit」テーブルにデータを入力することに同意します。月末に、そのテーブルの名前を MonthAuditYYYYMM に変更できます。ETL を使用して古いテーブルをメイン サーバーから簡単に移動でき、各テーブルを管理しやすくなります。これは、約 2 億 5000 万行の単一のテーブルを管理しようとするよりもはるかに優れていると信じてください。

于 2009-01-28T10:06:46.790 に答える
1

最初の適切な決定は、すべてをできるだけシンプルに保つことです。

レコードが時系列順に配置されている単純な書き込み専用トランザクション ログ ファイルのパターンで、私は幸運に恵まれました。次に、古いデータを切り替えるためのいくつかのオプションがあります。シンプルさを念頭に置いている限り、月ごとに異なるテーブルがあっても、クエリごとに管理できます。何らかの種類のレプリケーションを運用している場合、レプリケートされたテーブルをロールアウトしてアーカイブとして機能させることができます。次に、毎月 1 日に新しい空のテーブルから始めます。

通常、私はこのようなことを行うリレーショナル設計の結果にぞっとしますが、ここで扱っている理由から、書き込み専用の時系列ログ テーブルは通常の設計パターンの例外であることがわかりました。

ただし、トリガーには近づかないでください。可能な限り。最も簡単な解決策は、ここで話しているタイプのプライマリ テーブルであり、シンプルで堅牢な既成の実績のあるレプリケーション メカニズムを備えています。

(ところで - 大きなテーブルが適切に設計されていれば、すぐに遅くなることはありません - ゆっくりと遅くなります。)

于 2009-01-28T10:17:22.260 に答える
0

最近のログ レコードを検索する必要がない場合は、データベースをまったく使用しないという別のオプションがあります。代わりに、ログ情報をファイルに書き込み、ファイル名を毎晩ローテーションします。ファイルが書き込まれたら、バックグラウンド ジョブを開始して、データをアーカイブ データベースに直接インポートできます。

特にログファイルの場合、データベースが常に最適なオプションであるとは限りません:)

于 2009-01-28T12:21:45.380 に答える