スケーラブルなアプリのために NoSQL データベースにログを記録した経験はありますか? ロギング用の NoSQL データベースについて調査したところ、MongoDB が適切な選択であることがわかりました。また、非常に簡単なオプションと思われるlog4mongo-netを見つけました。
この種のアプローチをお勧めしますか?他の提案はありますか?
スケーラブルなアプリのために NoSQL データベースにログを記録した経験はありますか? ロギング用の NoSQL データベースについて調査したところ、MongoDB が適切な選択であることがわかりました。また、非常に簡単なオプションと思われるlog4mongo-netを見つけました。
この種のアプローチをお勧めしますか?他の提案はありますか?
過去18か月で最先端技術が大幅に変化し、はるかに優れた代替案が存在するため、この受け入れられた回答を改訂することにしました。
新しい答え
MongoDBは、スケーラブルなロギングソリューションの標準以下の選択肢です。これには通常の理由があります(たとえば、負荷がかかった状態での書き込みパフォーマンス)。もう1つ提案したいのは、ロギングソリューションの単一のユースケースのみを解決するということです。
強力なロギングソリューションは、少なくとも次の段階をカバーする必要があります。
選択肢としてのMongoDBは、ストレージのユースケースのみを解決します(多少不十分ですが)。完全なチェーンが分析されると、より適切な解決策があります。
@KazukiOhtaはいくつかのオプションについて言及しています。最近の私の好みのエンドツーエンドソリューションには、次のものが含まれます。
ログデータストレージのためのElasticSearchの基本的な使用法は、ロギングと検索のユースケースに現在の最高のNoSQLソリューションを使用します。Logstash-Forwarder / Logstash / ElasticSearch / Kibana3がElasticSearchの傘下にあるという事実は、さらに説得力のある議論になります。
LogstashはGraphiteプロキシとしても機能できるため、(ログだけでなく)メトリックの収集と分析に関連する問題に対して非常に類似したチェーンを構築できます。
古い答え
MongoDBの上限付きコレクションは非常に人気があり、ロギングに適していますが、「スキーマレス」であるという追加のボーナスがあります。これは通常、ロギングにセマンティックに適合します。多くの場合、私たちはプロジェクトに何をうまくログインさせたいか、または本番環境で特定の問題が見つかった後でしかわかりません。このような場合、リレーショナルデータベースや厳密なスキーマを変更するのは難しい傾向があり、それらを「柔軟」にしようとすると、単に「遅く」なり、使用や理解が困難になる傾向があります。
しかし、暗闇の中でログを管理し、レーザーを使用して宇宙から来たように見せたい場合は、インフラストラクチャ全体の一部としてMongoDBを使用するが、一般的な拡張可能な形式、専用のログ収集サーバー、分散アーキテクチャ、ファンキーなUI。
多くの企業がMongoDBを使用してアプリケーションログを保存しているのを見てきました。そのスキーマフリーネスは、スキーマが時々変更される傾向があるアプリケーションログに対して非常に柔軟です。また、上限付きコレクション機能は、古いデータを自動的に削除してデータをメモリに収めるために非常に便利です。
人々は通常のGroupingまたはMapReduceによってログを集約しますが、それほど速くはありません。特に、MongoDBのMapReduceは単一のスレッド内でのみ機能し、JavaScriptの実行オーバーヘッドは膨大です。新しい集約フレームワークは、この問題を解決する可能性があります。
ロギングにMongoDBを使用する場合、懸念されるのは、高い書き込みスループットによるロックの競合です。MongoDBの挿入はデフォルトでファイアアンドフォーゲットスタイルですが、多くのinsert()を呼び出すと、書き込みロックの競合が激しくなります。これは、アプリケーションのパフォーマンスに影響を与え、リーダーが保存されたログを集約/フィルタリングできなくなる可能性があります。
1つの解決策は、 Fluentd、Logstash、Flumeなどのログコレクターフレームワークを使用することです。これらのデーモンは、すべてのアプリケーションノードで起動されることになっており、アプリプロセスからログを取得します。
ログをバッファリングし、MongoDB / PostgreSQLなどの他のシステムにデータを非同期的に書き込みます。書き込みはバッチで行われるため、アプリから直接書き込むよりもはるかに効率的です。このリンクは、PHPプログラムからFluentdにログを入れる方法を説明しています。
MongoDB+Fluentdに関するチュートリアルをいくつか紹介します。
MongoDBの問題は、データ量がメモリサイズを超えると速度が低下し始めることです。その時点で、ApacheHadoopやCassandraなどの他のソリューションに切り替えることができます。上記の分散ロギングレイヤーがある場合は、成長するにつれてすぐに別のソリューションに切り替えることができます。このチュートリアルでは、Fluentdを使用してログをHDFSに保存する方法について説明します。
アプリが生成するログ メッセージの種類を指定する必要があります。単純なログ メッセージを大量にログに記録するだけの場合は、拡張性に優れているため、MongoDB が非常に適しています。しかし、複雑な認証や多くの階層が必要な場合は、従来の rdbms を使用します。