なぜRDBMSではなくファイルシステムがログに優先されるのですか？

質問はそのタイトルから明確でなければなりません。たとえば、Apacheは、使用されている規模に関係なく、RDBMSではなくファイルにアクセスログとエラーログを保存します。

RDMSの場合はSQLクエリを記述するだけで機能しますが、ファイルの場合は特定の形式を決定し、正規表現を記述するか、パーサーとして操作する必要があります。そして、細心の注意を払わないと、特定の状況で失敗することさえあります。

しかし、誰もがログを維持するためにファイルシステムを好むようです。私はこれらの方法のいずれにも偏っていませんが、なぜこのように実践されているのか知りたいです。それはスピードや保守性などですか？

1. データベースで失敗する可能性のあるものが多すぎると、これらの失敗をログに記録することも重要です。

2. 自律型トランザクションを許可する（またはトランザクションをまったく許可しない）データベースシステムがない限り、ログ記録でのロールバックまたはコミットがアプリケーションでのロールバックまたはコミットを妨げないように、ログ記録には個別の接続が必要です。

3. 起動中、つまりデータベース接続が確立される前に、ロギングする価値のある多くのことが起こります。

4. 通常のセットアップでは、新しいログファイルが毎日作成され、古いログファイルは圧縮されて2週間保持された後、最終的に削除されます。RDBMSで同じことを行うのは簡単ではありません。

以前にDBに書き込まれたログを見たことがあります（また、ログの構成可能なオプションを取得する場合があります。トレースはファイルに行き、DBにはエラー、Windowsイベントログには致命的です）。

主な理由は速度とサイズです。一部のトレースを有効にすると、非常に膨大な品質のログが生成されます。ログファイルのサイズはギガバイトです。もう1つの主な理由は、ログの読み取りがシーケンシャルである必要があることです。特定のエラーまたはエントリを見つける場合を除き、ログをクエリする必要はありません。

速度が理由の1つです。その他は：

• 障害点を排除します。DBMSが失敗しない条件下では、ファイルシステムが失敗することはめったにありませんが、データベースには、ファイルシステムには存在しない単純なエラー条件がたくさんあります。
• ローテクのアクセシビリティ。事態が本当に悪化した場合は、レスキューシェルを起動するか、ディスクを別のシステムにマウントしても、ログファイルを検査するための適切なツールを使用できます。データベースの場合、データベースサーバーが実行されていなければどこにもいません。

最初に。

そして、細心の注意を払わないと、特定の状況で失敗することさえあります。

注意しないとデータベーストランザクションが失敗することはありませんか？

テキストファイルへの書き込みには多くの利点がありますが、最も重要なのは

• テキストは人間が読める形式です。誰でも基本的なテキストエディタでログファイルを開き、メッセージが何であるかを確認できます。データベースがどのように構成されているかを理解する必要はありません。
• 速度。ディスクへのテキストの書き込みは、データベースサービスがテキストをデータベース内のどこに移動するかを判断し、そこに書き込み、トランザクションが完了したことを確認するよりもはるかに高速です。

あなたは特にApacheを提起しているので、これについて詳しく説明します。

Apacheはデータベースにログを記録するように設定できますが、そのためには外部プラグインが必要です。このようなプラグインを使用すると、独自のログ分析ソフトウェアを作成する場合にのみ、ログ分析が簡単になります。標準の既製のログアナライザーは、ログがファイルにあると想定しているため、これらを使用することはできません。

これを行っているときに、信頼性の問題も発生しました：データベースサーバーの書き込みバッファがいっぱいになると（実行するユーザーのファイルシステムクォータを使い果たすとmysqlで発生する可能性があります）、クエリがキューに入れられるまで待ちます先に進むと、Apacheが終了するのを待機し始め、Webサイトへの要求がハングします。

（この問題はもちろん修正されるかもしれません-私がこれをやったのは何年も前でした）

ファイルシステムはデータベースです。実際、リレーショナルDBMSではなく、より単純な階層型データベースですが、それでもデータベースです。

ファイルシステムへのログ記録が一般的である理由は、テキストログがUnixの哲学「テキストは普遍的なインターフェースである」によく適合するためです。

Unixは、テキストログで適切に機能する多くの汎用ツールを使用して開発しました。テキストログがmysql、apache、カスタムアプリケーション、長年サポートされていないサードパーティソフトウェアによって生成されたかどうかは関係ありません。sysadminはgrep、sed、awk、sort、uniq、cut、tailなどの標準Unixツールを使用できますなど、すべて同じようにログをトロールします。

すべてのアプリが独自のデータベース、MySQL、Postgres、Elasticsearch、ELK、MongoDBにしかログを記録できない場合、それぞれのログをトロールするための20の異なるツールを学習する必要があります応用。テキストは誰でもログインできる普遍的な媒体です。

すべてのログが単一のデータベース（MySQLなど）に記録されるように管理している場合でも、各アプリケーションが異なるテーブルスキーマでログを記録したい場合があるため、それぞれのログをクエリするためのカスタマイズツールを作成する必要があります応用。また、何らかの方法ですべてのアプリケーションを1つのスキーマに記録するように詰め込んだ場合、その汎用スキーマでは各アプリケーションの完全なストーリーを実際に伝えることができなかったため、とにかくログテキストを解析する必要があります。

多くの場合、データベースへのログ記録は実際にはそれほど簡単にはなりません。

データベースへのロギングは、特定の分析を念頭に置いている場合、または特定のデータベーススキーマを設計して特定の目的のデータのみを収集する特定の監査保持要件がある場合に役立ちます。しかし、フォレンジックおよびデバッグの場合、および特定の目的を考慮せずにログを収集する場合、通常、テキストログは十分に優れているため、専用ツールの学習や作成のコストは価値がありません。

これをいくつかのレイヤーで見てみましょう。

1. マシン層
2. オペレーティングシステム層
3. サービス層
4. アプリケーション層

簡単に言うと：

• マシン層では、何らかのダンプ以外のロギングを実際に行うことはできません。
• OS層ではロギングを実行できますが、実際に使用できるのはファイルシステムのみです。
• サービスはファイルシステムにログを記録できますが、他のサービスの実行を信頼できないため、そこにログを記録できません。
• アプリケーションは、サービスとファイルシステムにログを記録できます。

次に、ユースケースベースのアプローチがあります。

ノード固有のエラーを水平方向にスケーリングされたRDBMSに記録します。特定のノードのエラーを見つけるために余分な作業を行う必要がある場合、1つのノードのフードをポップしてそこに表示できますか？一方、アプリケーションは、RDBMSにログを記録して、アプリケーションレベルのエラーと通知を収集する必要があります。

データベースに書き込むことができないため、RDBMSがそれ自体のロギングを行う必要がある場合はどうなりますか？

複雑。RDBMSを追加すると、システム全体の天文学的な複雑さが増します。そして、複雑さを管理する能力は、プログラマーとソースコードプロデューサーを区別する主なものです。

それはスピードや保守性などですか？

速度。