51

この件に関する O'Reilly の記事を読んだ後、Stack Overflow にこの問題についての考えを尋ねてみました。

4

6 に答える 6

62

ローカルでディスクに書き込み、次にデータベースに定期的にバッチ挿入します (例: ログのロールオーバー時)。優先度の低い別のプロセスでそれを行います。より効率的に、より堅牢に...

(ちなみに、データベース ログ テーブルに「ログ イベントが発生したマシン」の列が含まれていることを確認してください。非常に便利です!)

于 2008-11-14T15:05:17.733 に答える
9

サーバーエラーのかなりの割合がデータベースとの通信の問題に関係していることを考えると、私はノーと言います。データベースが別のマシン上にある場合、ネットワーク接続は、ログに記録できなかったエラーの別の原因になります。

サーバー エラーをデータベースに記録する場合、データベースにアクセスできない場合に備えて、ローカルに (イベント ログやファイルなどに) 書き込みを行うバックアップ ロガーを用意しておくことが重要です。

于 2008-11-14T15:02:59.750 に答える
2

読み取りと書き込みに RAM を使用する適切にセットアップされたデータベースについて考えてみませんか? これはディスクへの書き込みよりもはるかに高速であり、多数のクライアントにサービスを提供するときに見られるディスク IO のボトルネックはありません。これは、OS が現在実行中のすべての IO を使用しているスレッドを待機するように指示するためにスレッドがロックダウンし始めるときに発生します。ハンドル。

このデータを証明するベンチマークはありませんが、私の最新のアプリケーションはデータベース ロギングを使用しています。これらの回答の 1 つで述べたように、これにはフェールセーフがあります。データベース接続を作成できない場合は、ローカル データベース (h2 かな?) を作成し、そこに書き込みます。次に、データベース接続を定期的にチェックして、接続を再確立し、ローカル データベースをダンプして、リモート データベースにプッシュします。

HA サイトがない場合は、営業時間外にこれを行うことができます。

将来的には、ベンチマークを開発して私の主張を実証したいと考えています。

幸運を！

于 2012-07-19T03:22:55.643 に答える
2

データベースにログが必要な場合は、おそらく悪い考えではありませんが、ログ ファイルのエントリが多い場合は、この記事のアドバイスに従わないことをお勧めします。主な問題は、ファイル システムが、データベースはもちろん、ビジーなサイトからのログに追いつくのに問題があることです。本当にこれを行いたい場合は、ログ ファイルが最初にディスクに書き込まれた後で、ログ ファイルをデータベースにロードする方法を検討します。

于 2008-11-14T15:05:49.013 に答える