| Ｎｏ．１１８ 低速なＲＤＢ |
| 概要 |
・リレーショナルデータベースの速度に疑問を感じている。
・１０万件程度の株価データのシミュレーションに非常に時間がかかる。
・メモリが非常に安価になってきているので、完全にメモリ上で動作するようにして欲しい。
・ハードやソフトにデータベース専用の環境が存在してもいいと思う。
(2008/01/27)
|
| 遅い |
パソコンを構成するハードウェアの処理速度は、年々速くなっています。しかし、その上で動作するソフトウェアの動作は早くなっているような気がしません。
ウィンドウズビスタはソフトウェアが低速という代表的な例ですが、これは機能の肥大化が原因です。アプリケーションソフトの基礎になるオペレーティングシステムがこの状況では仕方がないですね。コンピュータは速度が命のはず。いつから速度よりも使い勝手が重視されるようになってしまったんでしょうか。
オペレーティングシステムは多くの人が使用するので、使い勝手が重視されるのも仕方がないのではという見方もあります。では、データベースソフトはどうでしょうか。現在は、リレーショナルデータベース（ＲＤＢ）という表形式のデータベースが主流です。
表計算ソフトのエクセルもＲＤＢの一種だと思います。マイクロソフトアクセスは使い勝手のいいＲＤＢですよね。これらのアプリケーションソフトの速度は、人間が処理するよりはずっと早いとは思いますが、ハードウェアの急速な進歩と比較すると全然早くなってない気がします。
|
| 株価シミュレーション |
現在、株価データベースに対する分析プログラムを作成しています。様々な条件で、全銘柄に対する過去３年間のバックテストを実行していますが、複雑な条件になると丸一日かかったりします。たかが１０万レコード程度のデータベースに対して、この速度では実用になりません。ま、私のプログラムがダメだという話もあるかもしれませんが。
そこで、いくつかの対策を実施しています。
まずは５日移動平均や２５日移動平均は事前に計算しておくことにしました。本当は○日移動平均だったらどうなるのかというように動的に変更したいのですが、よく利用される５日と２５日に絞ることにしました。
次に全ての銘柄の３年分の株価データを一月一レコードで一つのテーブルに格納していました。これを銘柄毎に一日一レコード一テーブルに分割することにしました。各銘柄の株価データをクエリーなどで一括処理することはないと判断しました。また、一月一レコードの方が処理は速いですが、プログラムが複雑になるので一日一レコードに変更しました。
高速化のためにテーブルの構成を無理に変更しなければならないなんて、お手軽で理解しやすいというＲＤＢの利点を損なっている気がします。
|
| 高速化のために |
そこで、データベースについてインターネットで調査してみました。やはり、ＲＤＢが遅いと感じている人は多いようで、全ての処理をメモリ上で動作させる「オンメモリデータベース」や「ＩＳＳＥＩ」というファイル管理の仕組みをデータベースに応用する手法などを見つけることができました。
しかし、私はＲＤＢが広く普及してしまったので、もうこれを大きく変えることはできないと思っています。今更、カード型データベースやネットワーク型データベースが復活してくるとは思えません。また、ＸＭＬデータベースも流行するかと思ったのですが、いまいち普及していません。多分、ＩＳＳＥＩも同じ道をたどる可能性が高いと思います。
なので、ＲＤＢをより高速化する方が現実的でしょう。例えば、アクセスだったら、データベースサイズは２ＧＢが上限です。２ＧＢのメモリなんて、現状では非常に安価になってきているのですから、２ＧＢのＲＡＭディスクを作って、そこにコピーしてから実行すれば非常に高速に動作するかもしれません。（実際にやったことはないので詳細は不明です。）マイクロソフト社が使い勝手を良くするくだらない機能を作るぐらいだったら、オンメモリで実行するオプションを作ってくれると嬉しいです。
また、ゲームの環境にＤｉｒｅｃｔＸが存在するように、一つのハードウェア上で一つのアプリケーションを高速に動作させる技術があると嬉しいです。
さらに、ハードウェアもゲーム用の構成が存在するように、データベース用の構成とかあっても良いと思います。例えば、大量にメモリを搭載できるが、グラフィック機能は普通とか。大量データ処理の時代ですから、少しぐらい高価でも売れる分野は存在すると思います。
それでも処理速度を早くするのがプロだという声が聞こえてきそうです。（苦笑）
|
