RDBMSではなくファイルシステムがログに推奨されるのはなぜですか？
質問はそのタイトルから明確でなければなりません。たとえば、ApacheはアクセスログとエラーログをRDBMSではなくファイルに保存します。これは、Apacheがどの程度の規模で使用されているかに関係なく使用されます。
RDMSの場合、SQLクエリを作成するだけで機能しますが、ファイルの場合は特定の形式を決定してから正規表現を作成するか、パーサーとして操作する必要があります。そして、特別な注意が払われなければ、それらは特定の状況で失敗するかもしれません。
しかし、誰もがログを維持するためにファイルシステムを好むようです。私はこれらの方法のいずれにも偏っていませんが、なぜこのように実践されているのか知りたいです。それはスピードか保守性か何かですか？
データベースで失敗する可能性のあるものが多すぎるため、これらの失敗をログに記録することも重要です。
自律型トランザクションを許可する（またはトランザクションをまったく許可しない）データベースシステムがない場合は、ロギングに別の接続が必要になるため、ロギングのロールバックまたはコミットがアプリケーションのロールバックまたはコミットを妨げることはありません。
起動時に、つまりデータベース接続が確立される前に、ロギングに値する多くのことが発生します。
典型的なセットアップでは、新しいログファイルが毎日作成され、古いログファイルは圧縮され、2週間保持されてから、最終的に削除されます。 RDBMSで同じことを行うのは簡単ではありません。
以前にDBに書き込まれたログを見たことがあります（場合によっては、ログに構成可能なオプションがあり、トレースがファイルに行き、エラーがDBに行き、致命的なエラーがWindowsイベントログに記録されます）。
主な理由は速度とサイズであり、一部のトレースを有効にすると、膨大で膨大な品質のログが生成される可能性があります。サイズがギガバイトのログファイルを調べました。もう1つの主な理由は、ログの読み取りが順次的である必要があることです。特定のエラーやエントリを見つけることを除いて、ログをクエリする必要はありません。ファイルの検索はそのために完全に機能します。
速度が理由の1つです。他は：
- 障害点の排除。ファイルシステムは、DBMSが発生しない状況ではめったに失敗しませんが、データベースには、ファイルシステムには存在しない単純なエラー条件が数多くあります。
- ローテクなアクセシビリティ。本当にうまくいかない場合は、レスキューシェルを起動するか、ディスクを別のシステムにマウントしても、ログファイルを検査するための適切なツールを利用できます。データベースの場合は、データベースサーバーが実行されていなければどこにもいられません。
最初に。
そして、特別な注意が払われなければ、それらは特定の状況で失敗するかもしれません。
注意しないと、データベーストランザクションは失敗しませんか？
テキストファイルへの書き込みにはいくつかの利点がありますが、最も重要なのは
- テキストは人間が読める形式です。誰でも基本的なテキストエディタでログファイルを開いて、メッセージを確認できます。データベースがどのように構成されているかを理解する必要はありません。
- 速度。ディスクへのテキストの書き込みは、データベースサービスがテキストをデータベースのどこに配置するかを把握し、そこに書き込み、トランザクションが完了したことを確認するよりもはるかに高速です。
具体的にはApacheを提起しますので、これについて詳しく説明します。
Apacheはデータベースにログを記録するように構成できますが、そのためには外部 plugin が必要です。このようなプラグインを使用すると、独自のログ分析ソフトウェアを作成する場合にのみ、ログ分析が容易になります。標準の既製のログアナライザーは、ログがファイル内にあると想定しているため、これらを使用することはできません。
私がこれを行っていたとき、信頼性の問題も経験しました：データベースサーバーの書き込みバッファーがいっぱいになった場合（mysqlで実行するユーザーのファイルシステムクォータを使い果たした場合、mysqlで発生する可能性があります）、クエリがキューに入れられるようになります。続行すると、Apacheはそれが完了するのを待機し始め、Webサイトへの要求がハングします。
（もちろん、この問題は修正される可能性があります-私がこれを行ったのは何年も前のことです）
ファイルシステムはデータベースです。確かに、リレーショナルDBMSではなく、より単純な階層型データベースですが、それでもデータベースです。
ファイルシステムへのロギングが一般的である理由は、テキストログがUnixの哲学によく適合しているためです：「テキストはユニバーサルインターフェースです」。
Unixは、テキストログでうまく機能する多くの汎用ツールで開発されていました。テキストログがmysql、Apache、カスタムアプリケーション、長い間サポートされていないサードパーティソフトウェアによって生成されているかどうかは関係ありません。sysadminは、grep、sed、awk、sort、uniq、cut、tailなどの標準的なUnixツールを使用できます。など、すべて同じようにログをトロールします。
すべてのアプリが独自のデータベース、1つはMySQL、もう1つはPostgres、Elasticsearchにログを記録し、別のアプリがELKにログを記録したい場合、別のアプリがMongoDBにのみログを記録できる場合、それぞれのログをトロールするには、20の異なるツールを学習する必要があります応用。テキストは誰もがログインできる普遍的な媒体です。
すべてのログが単一のデータベース（MySQLなど）に送られるように管理したとしても、各アプリケーションが異なるテーブルスキーマでログを記録したい場合があるため、それぞれのログをクエリするためのカスタマイズされたツールを作成する必要があります。応用。そして、何らかの方法ですべてのアプリケーションを詰め込んで単一のスキーマにログを記録した場合、その汎用スキーマでは各アプリケーションの詳細を十分に伝えることができないため、とにかくログテキストを解析する必要があります。
多くの場合、データベースへのロギングは、実際には物事を大幅に容易にするものではありません。
データベースへのロギングは、特定の分析が必要な場合、または特定の監査保持要件に役立ち、特定のデータベーススキーマを設計して、それらの特定の目的のためにデータのみを収集できます。ただし、フォレンジックとデバッグの場合、および特定の目的を考慮せずにログを収集する場合、テキストログは通常、十分な品質を備えているため、専用のツールの学習または作成のコストに値することはあまりありません。
これをいくつかのレイヤーで見てみましょう：
- マシンレイヤー
- オペレーティングシステム層
- サービス層
- アプリケーション層
簡単に言えば：
- マシン層では、ある種のダンプ以外のロギングを実際に行うことはできません。
- OSレイヤーではロギングを実行できますが、実際に使用できるのはファイルシステムのみです。
- サービスはファイルシステムにログを記録できますが、他のサービスの実行を信頼できないため、そこにログを記録できません。
- アプリケーションはサービスとファイルシステムにログを記録できます。
次に、ユースケースに基づくアプローチがあります。
ノード固有のエラーを水平方向にスケーリングされたRDBMSに記録しますか？ここでは、1つのノードのフードをポップオープンしてそこに表示するだけで、特定のノードのエラーを見つけるために追加の作業を行う必要がありますか？一方、アプリケーションレベルのエラーや通知を収集するには、アプリケーションでRDBMSにログを記録する必要があります。
データベースに書き込めないためにRDBMSがそれ自体のロギングを行う必要がある場合はどうなりますか？