InfluxDBから select *
で全データ取った場合と
それをローカルに保存したJSONを読み込むだけでどれぐらい時間が違うのかを検証した。
JSONファイルおよびInfluxDBは同じ PCIe3.0x4 のSSD内で検証。
JSONの読み込みコードはJavaScriptの JSON.parse(fs.readFileSync())
7年前のSATA SSD PCから約130万件のSELECTは21秒かかった
約130万件:約定データ12時間分
余談:JSONのデータ量313MB
ローカルのJSONを読み込むまでの時間: 約2秒
InfluxDBから読み込む時間: 約11秒
圧倒的にローカルのJSONを読むほうが早い。
※サーバー側のデータをローカル側のInfluxDBにコピーするためのコード作成に戸惑ったためデータに3000件ほどズレが生じてしまったためおおよその時間のみの表記。差が明らか+時間の都合によりこれ以上の精度は求めないことにした。
DB内のSELECT処理やそのためのデータ構造等の兼ね合いでシーケンシャルリードとの差が歴然とするのは当然ではある。
つまり約定データからバックテストを行う場合、何度もデータを読み込むような実装や検証の場合は必要なデータの日付範囲をInfluxDBから読み込みJSONで一時的にファイル化したほうが効率が良いと言える。
InfluxDBであれば確実に時刻を絞ってロードしていけるので、小さな範囲で分けて検証するには高機能でメモリ制限などを考慮すれば悪くないと言えるがそのための実装を考慮すると少々大変なことが想像できる。
CSVやJSONの巨大ファイルを扱うプログラムは取り扱ったことがないのでどれほどの実装コストになるかは分からないが、単純に「バックテスト目当て」でデータを保存するのであれば生データで十分である可能性が高い。せいぜい日付でファイルを分ける程度で良いのではないだろうか。
あとはファイル容量の問題と、それに対応するなら圧縮・解凍周りだろう。
思いのほか大きな差となってしまった。
InfluxDBのメリットとしてはChronografによる可視化が簡単に行えること、記録サーバーを止めている間の別PCによる約定記録や、それに伴う約定データのマージなどを行う場合等はInfluxDBに軍配があがると考えている。
またBUYに絞った抽出なども効率良くできる。
ただ、これが本当に実装コストに見合ったものかは常に考えておかねばならない。
今後いろいろ検証出来たらと考えている。