ワンさんのFX個人取引記録日記 R2

東京サーバー限定ツールが無条件配布されるようになりました。
oandaのほかのサーバーに接続して使おうとすると表示制限がかかります。

サンプル


しかしMT4の画面から分離独立できるものもあるので使い勝手はいいのかもしれません。

4月25日に重要変化日
4月25日の週はほかの手法でも重要変化期間とされているので要注意

FXやCFDは株式市場と異なり、集約された取引所での取引ではない。
そのためイカサマされやすいという傾向があるので証券取引に慣れてる人たちからいやがられる傾向があるが、逆手に取ればこんないい制度もない。
証券市場でも、東京証券取引所と地方の取引所とで、同じ銘柄でありながら値が違う時は、片方を売り片方を買って鞘を取るというのはめずらしくなかった。地方の取引所での取引量は少ないが（手数料を除外すれば）絶対負けない鞘取りだ。

FXでこれをやるには、動きの速いブローカーと動きの遅いブローカーを組み合わせて、速いほうの動きに合わせて遅いほうでポジる、テクニカルも何もなくてただただ速度と組み合わせだけの取引手法だ。
この手法では、
どこのブローカーが速くて、どこが遅いか？
早い遅いのパターンはあるのか？
この２つの見極め方が勝利を左右する。

値動きを調べて組み合わせてフォワードテストして検証するのが一般的だが、結構時間がかかる。
時間をかけずに（仮説ベースで）選定していくのが、いまやってるtick数の変移だ。
値板が動くとtickも動く、実際に約定が発生しているかどうかはブローカーにしかわからないが（これがFXのいやらしいとこ）、tickの動きが少ないところは値動きが遅いといえるのではなかろうか。

ということで
速いところを探すためにいろんなデモ口座で
遅いところを探すためにいろんなリアル口座で
tickデータをためていくのは意味があると思うのだ。

1日だけだけど、FXCMデモ口座のtickデータを取ってみた。
最小1秒おきにtick回数を合計してDBテーブルに書き出すだけ。
ドル円、ユロ円、ユロドルの３つでやってみた。
結論はドル円、ユロ円のtick回数がユロドルに比べて大幅に少ない。
東京時間は逆転する場面もあるが朝9時の東京市場オープン直後でもユロドルのほうが多かったりする。
これから推測できるのは業者によって取引されるペアが少ないとtickも少ない。
FXCMは廃業寸前でアメリカの顧客口座はもうないわけだから、なおさら顕著なのかもしれない。

いろんな業者でペアごとのtick集計値をみて、自分がよくトレードするペアの状況がどうなっているのか、確認するのを先にやるべきだ。

MQL4から利用するDLLをBighopeさん作のに切り替えて、insert処理をやりなおしてみた。

結果は100万件のINSERT処理がSSDでもHDDでも5秒だった。
違いがないのはストレージのキャッシュ領域内で終わってたってことだろうか。
DBファイルサイズは16MB弱。
CPUをみてるとi7-3770Kが定格のターボブーストになって3.9Gで回っていた。
いずれにせよ、がんがんデータいれても問題ないってことだ。

サンプルスクリプトのinsert処理がジャーナルモード検証のと、Bind処理のとで実行時間に大差があり、あやしいいのでデバッグ文を追加して調べてみた。
前回の記事
結論は
Bind処理でのinsertは正しく処理され、テーブルにデータがたまっている。
しかし
ジャーナルモードでのinsert処理では、エラーコード「１」が返ってきてて、テーブルにデータがたまっていない。

エラーコード＝１だけなので、詳しい事情がわからない。
モードの違いでの時間差ってのはわかったが、あの処理速度は実際ではまったく期待できないってことだ。

アメリカのFX業界のNo1であるFXCMが顧客をだましてノミ行為をやってたことが監督官庁にばれてしまい、膨大な罰金と営業認可取り消しと代表者の業界からの永久追放が決定し、その余波で、顧客口座をforex.comに譲渡とFXCMの社名変更と主要役員の辞任に発展している。

リーマンショック以降の2009年から2014年まで、呑み専用の子会社を作って、顧客の注文に相対する行為と行ってストップ刈りしまくっていたらしい。
つまり、FXCMでのあやしい動きはすべて「わざと故意に」やってたわけだ。

FX会社は顧客に「ストップが大切！」と勧めるのは、たまったストップを自分たちで刈り取っておいしくいただくためであったということがばれたのだ。
それを率先してやっていたのが、よりによってアメリカのFX業界でシェア35%ももってるナンバーワン企業FXCM社であったというのだ。

FXCMジャパンを買収した楽天証券は同じシステムを使っているであろうから、呑み側である。
ひどい話だ。

漁夫の利をえたのはforex.comを運営しているゲイン社で、2月28日の最新ニュースによると、142万ドル相当の顧客資産を格安で譲ってもらったそうである。

MEMSQLというデータベース製品の金融取引事例
http://blog.memsql.com/market-making-with-memsql-simulating-billions-of-stock-trades-in-real-time/

アメリカでは複数の証券取引所に同一銘柄が上場されてて
どこの取引所に、まとまった量の買い注文が、安い順の上位５つを瞬間表示させる事例が掲載されてる。
証券取引だと、注文量の大きい注文から優先約定っていうルールがあるから
でかい注文の明細状況みながら自分のポジションを優先させることができる。

これってFXだとカバー金融機関がブローカー別に見てるってことだよね。

動画ダウンロードみたいに途切れることなく流れてくる注文のストーリミングデータをメモリー上に一時溜めては逐次分析していく。
これと自動注文あわせてカバーしてたら儲かりまくりになるのだろうか。

データの流れ
MT4またはOANDA_API→Python→MemSQL
または
MT4またはOANDA_API→SQLite

入り口のデータが、１つのブローカーだけならSQLiteのほうが簡単かもしれないし
複数のブローカーからのストリーミングデータを一括処理したいなら、Python→MemSQL処理のほうがいいのかもしれない。

ぐぐってるときにみつけた参考ブログのみなさん
http://darden.hatenablog.com/entry/2016/08/06/150811
http://fatbald.seesaa.net/article/440325932.html

OANDA APIを使ってデータ取得
http://futurismo.biz/archives/4266

MySQL wrapper - library for MetaTrader 4
https://www.mql5.com/en/code/8623

SQLiteのDBに更新処理する時のジャーナルモード設定種類に違いによる処理時間差。
WAL がとんでもなく遅くて、他は大差なし、OFFとmemoryがほぼ同じ。

memory>OFF>DELETE>>>>WAL

CPU:i7-3770K 定格,Windows7 SP1 64Bit　ストレージはSSD 60GB
MT4 Build950

MT4のスクリプトから10万件insertする際の、ジャーナルDBmode設定での処理時間
1レコード1カラム、数字をstringにしてinsert

サンプルスクリプト：sqlite_test_journal.mq4
DL元:https://github.com/Shmuma/sqlite3-mt4-wrapper

コーディングではDBを接続する時ではなく、insertの直前にmode設定している。

10万件での結果
Alert: Benchmark for mode OFF took 18 seconds
Alert: Benchmark for mode MEMORY took 18 seconds
Alert: Benchmark for mode WAL took 124 seconds
Alert: Benchmark for mode DELETE took 19 seconds
Start benchmarks

100万件での結果
Alert: Benchmark for mode OFF took 192 seconds
Alert: Benchmark for mode MEMORY took 189 seconds

ジャーナルモードの解説してくれてる参考ブログ

ここ数日で作成した部分成果をアップする。
ソースコードをアップすると商材屋に丸パクリされるのでそれはなし。
あくまでも自分用メモ。

最初にやってみたのは、バックテスト取引ログを読み込んで、時間別に集計する。
時間別の勝ち数負け数、勝ち値幅計、負け値幅計を計算
次に
時間別の勝ち越し数、勝ち越し値幅をもとにスコア点数化して、どの時間がスコアが高いか低いか、ひとめでわかるようにしてみた。

sql書いてて、はまったのはトリガー処理、テーブル単位での更新で動くんじゃなくて、レコード単位での更新で動く、つまりレコードを1行いれると1回トリガーが動く、1万件のデータをいれると1万回動くのだｗ

テーブルやビューの流れ関係をまとめたER図がこれ


MT4インポートTempにデータを流し込むと、カラムを追加してMT4DATAテーブルにコピーしてるのだが、この処理を最初はトリガーでやってて1万件importするのに10分かかった。CPUは1コアしか使わないが、コア使用率80%以上で、RAMDISKに移しても処理時間は少ししか減らないし、コア使用率が50%くらいあった。
あまりにおかしいので調べてみたら、トリガーがレコード挿入の都度動いてた。
まるでSSDの負荷テストしてるようなもん、SSD寿命が減ってもったいない。
トリガーでコピーするのをやめてSQLバッチ処理に切り替えたら1秒ちょいくらいで終わるようになった。
データ取り込みが終わるとビューを重ねていって、スコア集計するときのみテーブルにためている。
ビューでもいいのだが、SQL文が長くなるのでワークテーブルにためている。

20年位前のふっるーいデータベース開発でよくあったやり方だ。

とりあえずこんなやり方で通貨ペアひとつあたりの処理は終わるようになった。
処理時間はデータ流し込み時間込みで2秒以内。
ストレージは安物SSDで、インメモリ化はまだ採用していない。

これから複数通貨対応をDB上でやっていくとディスクIOが増えてくるのでSSDの消耗を減らすためにインメモリに移していく予定。

利用パソコンのスペックは
Windows7 SP1
CPU　i7-3770K 定格クロックで利用
メモリ16GB
SSDはいろいろ、DBファイルを置いてるのは ADATA SP550の120GB