2017年03月01日

板の動きの、速い遅い

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

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

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

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

為替ブログ FX 専業投資家へ
posted by ワンさん at 15:41 | 大阪 ☁ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

FXCMのtickデータを1日分ためてみて

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

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


為替ブログ FX 専業投資家へ
posted by ワンさん at 15:12 | 大阪 ☁ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

SQLITEのINSERTベンチマークやりなおし

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

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


為替ブログ FX 専業投資家へ
posted by ワンさん at 00:55 | 大阪 | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

2017年02月28日

サンプルスクリプトのinsert処理

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

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



為替ブログ FX 専業投資家へ
posted by ワンさん at 10:55 | 大阪 ☀ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

2017年02月23日

ストリーミングデータベース処理を考える

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

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

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

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

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

入り口のデータが、1つのブローカーだけなら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


為替ブログ FX 専業投資家へ
タグ:sqlite
posted by ワンさん at 23:50 | 大阪 ☁ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

2017年02月19日

MT4からSQLiteの処理を行う

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

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


為替ブログ FX 専業投資家へ
タグ:sqlite
posted by ワンさん at 14:44 | 大阪 ☀ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

2017年02月02日

初めてやってみたこと SQLiteとテーブルやらビューやら

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

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

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

テーブルやビューの流れ関係をまとめたER図がこれ
書きかけのEA図.png

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



為替ブログ FX 専業投資家へ
タグ:sqlite
posted by ワンさん at 07:44 | 大阪 ☀ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする

FXデータの金融分析はじめる

これまではForexControlCenterのアプリ版に、ストラテジーテスターのバックテスト取引結果ログを入れて
どのトレード手法の時に、いつ(日別、曜日別、時間別)、大きく動いてるのかを分析していたのだが
やたら処理が遅かったり、ハングアップする頻度がふえてきていた。
本家サイトを見に行くと、アプリ版の配布はやってなくてクラウド版だけとなっており、そのサービスも起業失敗で2月に閉鎖するという。
http://www.forexcontrolcenter.com/

アプリ版は見た目よいのだがハングアップ多くて使えない。
見たいところは時間別の成績結果だけなのでSQLを使えば自作できる。

ということで

メタトレーダー4のバックテスト取引結果ログやフォワード取引結果ログを個人でデータベース分析していく手順について、まとめてみる。

まず、どんなデータベースエンジンを使って分析するか?
とにかく簡単に使えて、処理が速い、この2点は譲れない。

大昔はデータベースSQL言語でプログラムを書いてた記憶がわずかながらあるのだが、おっさんになってしまうと昔のような学習能力はないのだ。思い出すことさえエネルギーがいる。

採用したデータベースエンジンは SQLite3 
こいつは簡単だ。スタンドアロンでしか使わないのでセキュリティはどうでもいい。
やりたいことは「瞬間で集計が終わって、わかりやすい結果をだせること」

SQLite3をより簡単に使いこなすためのツールが2つ必要となる。

DB内管理ツール
テーブル、ビュー、トリガーをGUIで簡単に作れて、テキストリバースもすぐできる。
ブラウザFireFoxのアドオン、SQLiteManagerを採用。
ブラウザの拡張機能で検索してインストール後、ブラウザ再起動して、ブラウザメニューのツールから選ぶだけで即起動する。

SQLエディタ
フリーだけど高機能で有名な A5:SQL Mk-2
http://a5m2.mmatsubara.com/

SQLエディタのA5:SQL Mk-2にもDB管理機能はあるんだけど、ハイスペックなDBエンジン対応がメインになってて、お手軽なSQLite対応はいまいち。しかしSQLエディタとしては大変優れているのでSQL文を書いて実行して試行錯誤を繰り返すのに最適なんだ。

[まとめ]
SQLite3
wiki https://ja.wikipedia.org/wiki/SQLite

FireFoxのアドオン、SQLiteManager
A5:SQL Mk-2

この3つで始めてみる。



為替ブログ FX 専業投資家へ
posted by ワンさん at 07:08 | 大阪 ☀ | Comment(0) | TrackBack(0) | データ分析 | このブログの読者になる | 更新情報をチェックする