編集スレッドメモMLやNewsのスレッドをメモする試み。VALUES(a)+bを使用して一気に書き込むようにしていますが、これが遅くて困っています。上記構文を利用している理由は、既に同じ条件での計算結果があればそれをインクリメントして追加する必要があるためです。より一度に大量のデータを書き込むことができます。ところが、この1文の実行に2時間以上かかっている場合があります。その間、ディスクへのアクセス音が聞こえ続けますので、本当に書き込みに時間が掛かっていると思います。...の部分は多くても128MBです。(bulk_insert_buffer_size=128Mにしています。あふれたらエラーになるはずですが、エラーになっていません)128MB/2時間=18KB/secですから、いくらなんでもディスクアクセスに時間がかかりすぎています。(5/17)私も、大量なデータを処理した時に、速度の壁にぶち当たりました。1レコードを書き込むのに、Insert構文だと、0.01msかかっていたものが、ファイルの出力にすると、0.003以下に下がったと思います。ファイルの構成は、書き込むテーブルの構成と同じにしておきmysqlimportコマンドが使えるフォーマットにしておきました。2)コントロールブレイク方式での演算で行いました。INFILEすれば速いかと思ってはおりました。それを採用していないのは、同じ条件であれば足し込む必要があるためです。INFILEにはIGNOREとREPLACEのオプションがありますが、UPDATEも欲しかったところです。度は80KB/sec〜140KB/secです。ディスクはSATAでRAID5を組んでいるのですが、やはり遅すぎではないかと思います。(5/18)いくつかデータを作って実験してみたところ、興味深い結果がでました。UPDATE)する行数の二乗に比例した時間がかかります。一度に処理する行数に対して処理時間が以下のようになりました。(このときのテスト用SQL文は453KB)I/Oも少しは出ていますが、こちらの環境ではほぼCPUネックです。内部アルゴリズムがとても残念な実装になっているのだと思います。置かない方がいいんじゃないかと思います。なるように思っています。若干関係なくなるような気もしますが、もう少し説明していただけると助かります。書き込みが遅いためです。あとディスク故障時のパフォーマンスが大幅に低下します。程度にまで落ちました。一概には言えないとは思いますけど...。(5/19)個人的にはRAID5が一番好きで10年以上前から愛用していました。(HDD10本以上構成などで無いと価格優位性が出にくい)RAIDが必要な状況で考えますと、故障したときの復旧が遅いというのは致命傷になりがちです。復旧処理(再構成)しつつ運用できますが、データ処理速度の劣化がひどく、使えない状況になりやすいです。それ以上に、もう一台HDDが壊れると、全データ消滅の恐れもあり怖くて運用できなくなります。RAID装置大手のnetapp(ネットアップ)では、RAID4構成を採用しています。これは、RAID5に近いのですが、パリティー情報を特定のHDDに保存します。パリティー情報格納ディスクが壊れると、非常に危険なので推奨はダブルパリティー方式(オプション)パリティーディスクのみをミラーリングします。大容量と安全性を求めるならnetapp方式で、それをさらに多重化する(必須かと思います)。netappでは、データ変更量が、オンメモリーで処理できる量以内であれば、非常に高速でした。それを超えてしまうと、極度に速度が低下します。メモリー量で価格が倍倍ゲームになっていきますので事前の設計が非常に重要です。ところで、SATAは、メインのRAIDには、普通選びません。RAID構成以前の問題になります(速度を問題にするなら)。RAID構成でSATAを選択する場合、バックアップ用など速度は二の次、コストと容量を確保したい場合に選定します。ファイバーチャネルか、悪くてSCSIになると思います。回転速度(シークタイムと処理速度がともに遅い)が遅いので、RAID0で高速化をはかり、それをRAID1構成にして、安全性を図るのが適しています。(5/20)でも相変わらずDB向けにもRAID5って提案されているんですね。(どの点を重視するかで変わるとは思いますが...)読み出し量が膨大で更新量の少ないwebコンテンツとかであればRAID5も有効だと思います。最低は1本、運が良いと(汗)n/2本までの故障に耐えられますからね。2.3.8-p459。