俺流テキストデータベース #8 負荷計測 jq編

Pocket
LINEで送る
GREE にシェア
LinkedIn にシェア

テキストデータベースを採用すると、WEBサービスを作る時の環境構築が非常に楽になります。
 

SQLモジュール設定やテーブル設定などの事前作業が楽になる事はもちろん、開発途中でテーブルの仕様変更などかなり簡単な対応で行う事ができるようになります。
 

もちろん、データ構造アルゴリズムの大幅変更は、プログラムも含めた見直しが必要になるのは当たり前ですが、charバイト数などの設定ミスや、不具合、トラブルなども皆無になるので、ありがたい環境に感謝するエンジニアも多いでしょう。
 

前回行なったログ形式のデータアクセスは、csvと同じ構造なのでawkで行なったのですが、今回は大容量jsonデータをjqコマンドで速度計測してみたいと思います。
 

ソースコード

事前に大容量JSONデータとして、前回使用したnginx-error-logをjsonに変換してみます。
 

 

同一階層にlogフォルダを作ってその中に”log.json”というファイルを作ってcsvデータをjsonフォーマットに変換してみました。
 

統一性が少ないデータなので、日付、時間、タイプ、その他ぐらいの分類で、これに当てはまらないものは、rawデータとして、整形しています。
 

レコード数は、”916,253″(91.6万)レコードで、ファイル容量は、 “141MB”あるので、計測サンプルとしてはまあまあの容量でしょう。
 

 

最初は、jqコマンドを使って、計測してみましょう。
 

実行

jqで総数の確認

 

lengthでちゃんと行数と同じ値が取れますね。素敵です。
 

日付一覧の取得

 

配列で取得できて、便利に使えますが、uniqコマンドの方が件数なども表示できて便利です。
 

5.5秒ぐらいのレスポンスです。
WEBページで使おうとすると、このままでは難しいですね。
 

jqのスピードについての見解

jqコマンドのスピードが遅いのは、ファイルに格納されている全てのデータをメモリに配置してから評価が開始するので、そのアーキテクチャの基礎部分がボトルネックになっているようですね。
 

前回のawkとはデータが違うので、今回のデータで行数表示速度と比較すると以下の通りです。
 

 

圧倒的なスピードの差がありますが、jsonデータ解析ができるjqと組み合わせで使うのが効率いいのかもしれませんね。

次回予告

テキストデータベースで一番苦手になりそうな、リレーショナルデータベースに挑戦してみます。
 

ユニークIDをベースに、複数のデータをリレーションする時にどのくらい便利に行えるかがポイントです。
 

できれば、select文さながらにしてみたいですね。
 

俺流テキストデータベース #9 リレーショナルデータベースにTRY

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です