データベースの書き込み・読み込み速度を上げたい。

質問

winXPにインストールしたXAMP上における、
複数のデータベース（SQLite)に対し、
それぞれにおいて、１時間に数千件の読み書きを行い、
マシン自体が１時間に処理するデータ量の合計が10000件ほどの場合の、
その処理速度を上げたいと考えています。

この辺りのことについて、私には全く知識がないので、
考え方の指針すら手にしていない状態です。

そんな私が考えたことを述べますと、

・CPUの性能を上げれば良い？
（今の環境はAthlon64X2 4200+）

・ハードディスクを、読み書きの早いものにすれば良い？
（今の環境はHitachi HDT725032VLA360)

このような感じです。

なお、ソフト面（プログラミング言語やコード内容など）というより、
ハード面での対処で検討しています。

今より、少しでも処理を速める方法として、
コストパフォーマンスの優れたものがありましたら、
どなたか教えて下さい。

例）
・ハイテクマシン１台より、並マシン２台の方が処理も速く、そして安い？
・HDDはプラッタ枚数によって、こんなにも読み書きが速くなる？
・SSDの方が速い？
・HDD容量は無駄に大きなものより、小さなものの方が速い？
・OSは、Win7の方がWinXPより速い？もっと言えば、Linuxの方が速い？

と、私が思いつく、改善案かな？と思えることはこれくらいです…。

以上、宜しくお願いします。

回答No.2

gtx456gtx · ベストアンサー

オンメモリはテストでオープンしただけですが、Webで参考になるURLを添付したので参照してみて下さい。
http://d.hatena.ne.jp/mgng/20091104/1257315625

当然、終了時にHDDに書き出さないと消滅するので「オンメモリにするための処理と、終了時にHDDに書き込む処理」を含めてトータルで処理時間を検討しないといけないですが検討する価値はあると思います。

>それぞれにおいて、１時間に数千件の読み書きを行い、
>マシン自体が１時間に処理するデータ量の合計が10000件ほどの場合の
１時間で数千件や１万件程度のデータ操作なら、そんなに気にするほどのことはないように思います。
それにSQLiteは、本格的なデータベースというより開発時のテスト環境的な使い方が最適と思います。　実運用で使った時、ユーザという概念がないことは問題になりませんか？

お礼

お話を伺い、オンメモリを使った方法を検討してみたくなりました。
私の用件にマッチしているかどうかは試してみないことにはわかりませんが、
調べてみる価値はありそうです。
で、この方法の場合、大量のメモリを用意する必要があるようですが、
大量というのは具体的にはどの程度になりますでしょうか。
現在、マシンには２GBのメモリが載っていますが、
32bitマシンであるため、４GBは載らない？かと思います。
このような環境で、オンメモリでの運用は可能だと思われますでしょうか。

次に、SSDを使った方法についてですが、
こちらは、オンメモリの方法を選んだ場合には、候補から除外される類のものでしょうか。
それとも、両者を同時に導入することには価値がありそうでしょうか。

システムをSSDにすることで、OSやXAMPの動きが速くなったり、
最終的に行われる、データベースへの書き込みも速くなりそうですからね。

処理内容にもよるでしょうが、
これらの改善を全て行ったとして、得られるスピードが２倍以上あるといいのですが、
それほど改善されないようだと、正直なところ、悲しくなりそうです。（笑）

回答No.4

gtx456gtx

>これらの改善を全て行ったとして、得られるスピードが２倍以上あるといいのですが
データベースの高速化は、ハードウェア的なのもは想定していない前提条件になります。　簡単に変更できないため。

基本、ハードウェアをデータベース用にチューニングし、その後はデータベースのパラメータやSQL文を検討して高速化するという手順です。
Oracleでの実績でいうと、単純にインストールした状態から、稼動したデータベースに合わせてパラメータのチューニングを行って倍以上に高速化し、その後はインデックスやテーブルを見直して目標の速度に近づけるって感じでチューニングを進めます。

なお、SQLiteでは、パラメータの見直による高速化はあまり期待できないです。

2Gbでどの程度のデータベースがオンメモリ上に展開できるかは、行のサイズによるので・・・実際に展開して確認する方が早いと思います。　当然OSやSQLiteの領域もあるので、1Gbを越すことは無理な気がします。

お礼

またしてもありがとうございます。助かります。

＞基本、ハードウェアをデータベース用にチューニングし、その後はデータベースのパラメータやSQL文を検討して高速化するという手順
＞2Gbでどの程度のデータベースがオンメモリ上に展開できるかは、行のサイズによるので・・・実際に展開して確認する方が早い

こちら、非常に参考になりました！
おかげさまで、
すべきこと、できる範囲、それぞれ見えてきた気がします。

回答No.3

pakuti

OSはWindowsよりもLinuxの方が良いでしょう

ファイルシステムをＥＸＴ３にするのであれば
ジャーナリングモードでファイルの保存性とトレードオフで速度を調整する事が可能です
SQLiteを利用した事がないですが、RAWデバイスを利用するとI/Oのオーバーヘッドを軽減出来ることが多いです。

ボトルネックがどこに出るかによって何が最適かは変わります。
1番はHDDの可能性が高いですが、SQL文によってはCPUがネックになる場合もあります
（その場合は、SQL文を書き直すべきですが）

お礼

大変興味深い回答をありがとうございます。

Linuxもいいなと思えてきました。

＞1番はHDDの可能性が高いですが、SQL文によってはCPUがネックになる場合も

HDDをSSDに、もしくは、読み書きの速そうなHDDに換えてみることには、
少なくともなんらかの価値はありそうですね。
で、気になったのが、
「SQL文によってはCPUがネックになる場合も」
です。

具体例をお聞きしても、おいそれとは出てこないよ、
と言われてしまいそうですが、
もし何かヒントでも頂ければ、とても嬉しく思います。

ちょっと自分でも考えてみました。
SQL文の見方として、以下の４パターンがあるのでしょうか？

（１）CPUに優しく、HDDにも優しい
（２）CPUには優しいが、HDDには優しくない
（３）CPUには優しくないが、HDDには優しい
（４）CPUにも、HDDにも優しくない

「SQL文によってはCPUがネックになる場合も」
というのは、
（３）か（４）のパターンということですよね。
で、SQL文をどう書こうと、その目的が同じであれば、
HDDに対して行われる処理、つまり、書き込み、読み込みは、
同じであると思えるので、
（３）のパターンを改善した結果、（２）のパターンになってしまうとは思えず、
また、同様に、
（４）のパターンを（１）のパターンに改善することも無理なのではと考えました。
つまり、
（３）だったら、（１）へ、
（４）だったら、（２）へ、
の改善しか、それぞれできないのかなと思ったわけです。
何か変なことを言っていましたら、すみません。
考え方的に、何かおかしな点があれば指摘して頂けると嬉しいです。

ということで、
いずれにしても、（３）か（４）が疑わしい場合には、
SQL文を改善することで、いくらかマシな（１）か（２）へと昇格でき、
（１）か（２）でさらに処理速度を上げるには、
HDDを改善すれば良いのかなと。

よって、とりあえずは、
HDD、SQL文、CPU、OS
を見直してみるのが良さそうですね。

回答No.1

gtx456gtx

>ソフト面（プログラミング言語やコード内容など）というより、ハード面での対処で検討しています。
・メモリを大量に準備して、全てオン・メモリで運用が最速と思います。
-------------
・高速なＨＤＤを使う( SSDならよりベター )
・HDDをRAID0で利用する( 当然、最適なブロックサイズで運用 )

>OSは、Win7の方がWinXPより速い？もっと言えば、Linuxの方が速い？
そんなに差はないと思います。

>・HDD容量は無駄に大きなものより、小さなものの方が速い？
比較するなら、アクセス速度(ランダムアクセス)を比較して早いHDDを選択すべき
プラッター数やキャッシュ容量によって傾向はありますが、絶対的な指標にはならないと思います。

お礼

回答ありがとうございます。

＞全てオン・メモリで運用

データを一時的に使うのではなく、
使った後、記録として残すタイプのDBなのですが、
それでも、この「オンメモリ」の方法は使えますでしょうか？
HDDを介さず、メモリだけで処理できれば速そうだなとは思っていましたが、
この方法だと「記録保存」が出来ないだろうと思い、検討候補から除外していました。

＞高速なＨＤＤを使う( SSDならよりベター )

SSDだと記録回数の上限値がHDDに比べて小さいらしいのですが、
１時間あたり10000件の読み書きには向いていそうでしょうか。

またよろしければ色々と教えて下さい。