0

log4net新しい Web プロジェクトで使用する予定です。私の経験では、ログ テーブルがどれだけ大きくなるかがわかります。また、エラーや例外が繰り返されることにも気付きます。たとえば、132.000 を超えるレコードを持つログ テーブルにクエリを実行したところ、distinct を使用したところ、2.500 レコードのみが一意 (~2%) であり、他のレコード (~98%) は単なる重複であることがわかりました。そのため、ロギングを改善するためにこのアイデアを思いつきました。

同じレコードを挿入しようとするたびに更新される新しい列がいくつかありますcounter。updated_dt

例外の原因となったユーザーを追跡する場合は、user_logNN 関係をマップするために、または log_user テーブルを作成する必要があります。

このモデルを作成すると、これらすべての長いテキストを比較しようとすると、システムが遅くなり、非効率になる可能性があります...ここでのトリックはhash column、メッセージと例外をハッシュし、それにインデックスを構成する 16 または 32 のバイナリも必要です。 . HASHBYTES私たちは私たちを助けるために使用できます。私は DB の専門家ではありませんが、同様のレコードを見つけるためのより迅速な方法になると思います。また、ハッシュは一意性を保証しないため、同様のレコードをはるかに高速にローカライズし、後でメッセージまたは例外を直接比較して一意であることを確認するのに役立ちます。

これは理論的/実際的な解決策ですが、うまくいくのでしょうか、それともより複雑になりますか? 除外している側面や、他に考慮すべき点は何ですか? トリガーは挿入または更新の仕事をしますが、トリガーはそれを行うための最良の方法ですか?

4

2 に答える 2

1

正直に言うと、132,000 レコードのログ テーブルにはあま​​り関心がありません。ログ テーブルには、数十億とは言わないまでも、数百万のレコードを見てきました。数分ごとに 132,000 レコードをログアウトしている場合は、少しトーンダウンすることをお勧めします。

アイデアは面白いと思いますが、私の主な懸念事項は次のとおりです。

  • これを行うと、実際にアプリケーションのパフォーマンスが低下する可能性があります。Log4Net ADO.NET アペンダーは同期的です。つまり、INSERT を必要以上に複雑にすると (つまり、データが既に存在するかどうかを調べる、ハッシュ コードを計算するなど)、ロギングを呼び出すスレッドがブロックされます。それは良いことではありません！この書き込みをステージング テーブルのようなものに修正し、ジョブなどで帯域外で実行することもできますが、今では、はるかに単純な何かのために一連の可動部分を作成しています。
  • 他のことに時間を費やしたほうがよいかもしれません。ストレージは安価で、開発者の時間はかからず、ログへのアクセスが非常に高速である必要もないため、非正規化モデルで問題ありません。

考え？

于 2012-10-19T22:28:39.297 に答える
1

はい、できます。それは良い考えであり、うまくいくでしょう。複数のスレッドまたはプロセスから挿入する場合は、同時実行の問題に注意してください。おそらく、ロックを詳細に調査する必要があります。ロックヒント（あなたの場合UPDLOCK, HOLDLOCK, ROWLOCK）とMERGEステートメントを調べる必要があります。これらは、ディメンション テーブルを維持するために使用できます。

別の方法として、ファイルにログを記録して圧縮することもできます。典型的な圧縮アルゴリズムは、このタイプの正確な冗長性を排除するのに非常に優れています。

于 2012-10-19T21:40:38.867 に答える