システムトレードでは、取引履歴を蓄積して、そこからレンジバー作って各種テクニカル指標を求め、エントリーの判断を行う。
筆者の環境では、各マーケットのストリームAPIから取得した情報をPostgreSQLに蓄積していたが、 非常に重くなってしまったので、Elasticsearchを選んだ。
高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)
- 作者: Rafal Kuc (lにストローク符号、cにアクサン・テギュ付く),Marek Rogozinski (nにアクサン・テギュ付く)
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/03/25
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
Elasticsearchがログ蓄積に使われているのが決め手で、なぜなら、取引履歴も結局ログだからだ。
スキーマレスな使い方もできるようだが、筆者はこちらのマッピングを使っている。
{ "mappings": { "execution": { "properties": { "market": { "type": "string" }, "timestamp": { "type": "date" }, "price": { "type": "double" }, "side": { "type": "string" }, "size": { "type": "double" } } } } }
side
には、"buy"
または"sell"
が入る。
CPU使用率が非常に低いが、メモリは際限なく消費するため、"ES_JAVA_OPTS=-Xms320m -Xmx320m"
として、メモリ消費を抑えている。
投入には1秒間バッファリングした取引履歴をBulk APIでいっぺんに送っている。
PostgreSQLの時は、Goのバインディングに問題があり、1つの取引履歴ごとにINSERT
文を発行していたので(それをしなければESもいらないのかもしれないが…)非常にCPUを消費していた。
クエリはMongoDB に似ていて、Python からは、elasticsearch-dsl を使ってデータを引いている。
Elasticsearch DSL — Elasticsearch DSL 5.4.0.dev documentation
10000ドキュメント以上を引くには、.scan()
を使う必要があるが、
これを使うとソートが効かなくなるので、Pandasでゴニョゴニョしている。
これはどうにかしたい。
以前の記事にも書いた機械学習でクリーンした値を取得するのと組み合わせて、 非常にノイズの少ないデータが取れるようになった。 ※ ただし取得に非常に時間がかかる
バックテストの結果、勝率も上がることが確認できた。
まだマーケットと繋いでいないので実力はまだわからないが、来週中には結果を出したい。
高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)
- 作者: Rafal Kuc (lにストローク符号、cにアクサン・テギュ付く),Marek Rogozinski (nにアクサン・テギュ付く)
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/03/25
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築!] Software Design plus
- 出版社/メーカー: 技術評論社
- 発売日: 2014/08/14
- メディア: Kindle版
- この商品を含むブログを見る