2017年02月28日

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

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

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



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

アメリカのFXCMが廃業1歩手前

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

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

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

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

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



為替ブログ FX 専業投資家へ
posted by ワンさん at 10:48 | 大阪 ☀ | 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) | データ分析 | このブログの読者になる | 更新情報をチェックする