テキストデータベースを採用すると、WEBサービスを作る時の環境構築が非常に楽になります。
SQLモジュール設定やテーブル設定などの事前作業が楽になる事はもちろん、開発途中でテーブルの仕様変更などかなり簡単な対応で行う事ができるようになります。
もちろん、データ構造アルゴリズムの大幅変更は、プログラムも含めた見直しが必要になるのは当たり前ですが、charバイト数などの設定ミスや、不具合、トラブルなども皆無になるので、ありがたい環境に感謝するエンジニアも多いでしょう。
前回行なったログ形式のデータアクセスは、csvと同じ構造なのでawkで行なったのですが、今回は大容量jsonデータをjqコマンドで速度計測してみたいと思います。
ソースコード
事前に大容量JSONデータとして、前回使用したnginx-error-logをjsonに変換してみます。
time cat /var/log/nginx/error.log | awk '{ if( $1 ~ /^[0-9]+\/[0-9]+\/[0-9]+/ ){print "{\"date\":\""$1"\",\"time\":\""$2"\",\"type\":\""$3"\",\"raw\":\""$0"\"}"} else{print "{\"raw\":\""$0"\"}"} }' > log.json
同一階層にlogフォルダを作ってその中に"log.json"というファイルを作ってcsvデータをjsonフォーマットに変換してみました。
統一性が少ないデータなので、日付、時間、タイプ、その他ぐらいの分類で、これに当てはまらないものは、rawデータとして、整形しています。
レコード数は、"916,253"(91.6万)レコードで、ファイル容量は、 "141MB"あるので、計測サンプルとしてはまあまあの容量でしょう。
time wc -l log.json
916253 log.json
eal 0m0.477s
user 0m0.030s
sys 0m0.110s
ls -lha log.json
-rw-r--r-- 1 root root 141M 11月 21 08:42 log.json
最初は、jqコマンドを使って、計測してみましょう。
実行
jqで総数の確認
time jq -s '. | length' log.json
916253
real 0m2.776s
user 0m1.820s
sys 0m0.480s
lengthでちゃんと行数と同じ値が取れますね。素敵です。
日付一覧の取得
time jq -s '[.[].date] | unique' log.json
[
...
"2018/11/15",
"2018/11/16",
"2018/11/17",
"2018/11/18",
"2018/11/19",
"2018/11/20",
"2018/11/21"
]
real 0m5.481s
user 0m4.570s
sys 0m0.420s
配列で取得できて、便利に使えますが、uniqコマンドの方が件数なども表示できて便利です。
5.5秒ぐらいのレスポンスです。
WEBページで使おうとすると、このままでは難しいですね。
jqのスピードについての見解
jqコマンドのスピードが遅いのは、ファイルに格納されている全てのデータをメモリに配置してから評価が開始するので、そのアーキテクチャの基礎部分がボトルネックになっているようですね。
前回のawkとはデータが違うので、今回のデータで行数表示速度と比較すると以下の通りです。
$ time awk 'BEGIN{num=0}{num++}END{print num}' log.json
916253
real 0m0.719s
user 0m0.190s
sys 0m0.150s
圧倒的なスピードの差がありますが、jsonデータ解析ができるjqと組み合わせで使うのが効率いいのかもしれませんね。
次回予告
テキストデータベースで一番苦手になりそうな、リレーショナルデータベースに挑戦してみます。
ユニークIDをベースに、複数のデータをリレーションする時にどのくらい便利に行えるかがポイントです。
できれば、select文さながらにしてみたいですね。
