ファイルI/Oについて

Question

MySQLのデータベースログを常時解析してデータの更新を検知する手法を学びました。データベースのログといってもファイルなのですから工夫しない限り常時監視という手法はかなり高いI/Oコストや解析コストがかかると思います。
さらに実際のプロダクトではデータベースの吐き出すログは非常にデータサイズが大きいと思います。

ここで質問なのですが例えばマルチスレッディングのプログラムでいくつものスレッドでファイルを読み通り専門にして参照し、異なるファイルのインデックス地点(例えばログファイルのうち何行目か、など)を参照させてファイル解析のスループットをあげるといったことは可能なのでしょうか？

その手法では、データベースログの読み取り始める箇所をばらばらにしておいて(なんらかの並列処理で)一気に読み始めていち早くアップデートに関するログを解析する。。。といったものでしたがデータベースログの知識に乏しいため実際にどのように実装しているのか想像できませんでした。そもそも一つのファイルなのだから単一スレッドで読んでいくスピードが実質最速なのかなとも思いますので学んだ手法がどのようなことをいっているのかわかりません。。。。

どなたかアドバイスをよろしくお願いいたします。

Answer 1

ファイルサイズが大きくても、更新内容を読み取るのに毎回ファイル先頭から読み直す必要はないです。開いたファイルの読み取り位置ををファイル終端に移動しておき、ファイルの変更を検知したら増分を読み取る、というやりかたを普通はします (要するにtail -fでやっているのと全く同じことです)。Swatchのようなツールがこの手法を使っています。

なおこの場合、ディスクI/Oやバッファリングの影響が非常に大きいため、マルチスレッドにしても速度面のメリットは全くなく、シングルスレッドでかまわないと思います。またこの手法自体、多用すればパフォーマンスに影響しますので、ある程度規模が大きいのならほかの方たちが回答しておられるような手法も検討されるべきとおもいます。

Answer 2

何を何でどう学んだかのがわからないので既知の話かもしれませんが…

本気でログ解析を行う場合は、ログを吐くホスト上では行わず、ログ収集サーバへログを飛ばし、さらにログ解析サーバで解析する事が多いと思います。

今風にやるなら「Elasticsearch」「Logstash」「Kibana」の組み合わせで、がっつりやったり、「fluentd」でとりあえず集めてあとは自前で…とかでしょうか

Answer 3

独自でログを分析するとデータベース・サーバは性能劣化すると思われますが、それは許容されるということでしょうか？

通常はデータベース・サーバの性能劣化を避けるために、アプリケーション・サーバ側に追跡の仕組みを入れるものですが、コードの修正が困難でRDBMS側で対応させたい時は「監査」と呼ばれる機構を使って、ユーザの操作を追跡したりします。MySQLにもその手のプラグインはあるようですよ。

6.3.12.1 監査ログプラグインのインストール - MySQL5.6リファレンスマニュアル

McAfee MySQL Audit Plugin で MySQL の監査ログを採取する