こんにちは、株式会社ビービットの玉越です。

平塚様、ありがとうございます。
テストしていただいたとは本当に頭が下がります。

メールを拝見して全身に脱力感がありました。
見事にO(n^2)ですね。

早速500行ごとに書き込むように変更してみました（少し速くなったようです）。


> I/Oも少しは出ていますが、こちらの環境ではほぼCPUネックです。

という点が少し分かりかねますが、これは書き込みの時間ではなくCPU処理時間
の差でしょうか？

こちらでは、書き込み時間が殆どを占めています。


また、もしかしてRAIDカードのwrite backキャッシュが使われていないのかも、
と思い確認してみたところ、write throughになっていました。ショックです。

今設定し直したので速度を計測し直します。



On Fri, 18 May 2007 13:33:55 +0900
HIRATSUKA Sadao <hiratsuka.sadao@xxxxxxxxxx> wrote:

> 平塚です。
> 
> > > VALUES ..., ..., ...の部分は多くても128MBです。
> > > （bulk_insert_buffer_size=128Mにしています。あふれたらエラーになるはずで
> > > すが、エラーになっていません）
> 
> いくつかデータを作って実験してみたところ、興味深い結果がでました。
> 
> INSERT ... VALUES ..., ..., ... ON DUPLICATE KEY UPDATE ...のSQLは、
> 「VALUES ..., ..., ...」←ここで一度にバルクINSERT (or UPDATE)する行数の
> 二乗に比例した時間がかかります。
> 
> レコード長100バイト、13万レコードのテーブルで
> INSERT ... ON DUPLICATE KEY UPDATEをすると、
> 一度に処理する行数に対して処理時間が以下のようになりました。
> 
> 125行：0.06秒
> 250行：0.26秒
> 500行：1.01秒
> 1,000行：4.04秒
> 2,000行：16.09秒
> 4,000行：64.00秒 (このときのテスト用SQL文は453KB)
> 
> I/Oも少しは出ていますが、こちらの環境ではほぼCPUネックです。
> きっと内部アルゴリズムがとても残念な実装になっているのだと思います。
> 
> 
> > > VALUES ..., ..., ...の部分は多くても128MBです。
> 
> ということで
> ここを数十KBにおさえて、繰り返し実行するようにするとどうでしょうか。
> 
> 
> よろしくお願いいたします。
> 
> -- 
> 平塚貞夫 hiratsuka.sadao@xxxxxxxxxx
> NTTコムウェア株式会社 プロジェクト管理統括部 技術SE部門 DB技術グループ
> Tel:043-211-2318 Fax:043-211-5064
> 
> 

--
株式会社ビービット　玉越 大輝
ユーザビリティ コンサルタント
beBit,Inc. Tamakoshi Hiroki hiroki.tamakoshi@xxxxxxxxxx
--------------------------------------------------------
〒105-0001 東京都港区虎ノ門1-18-1 虎ノ門10森ビル7F
TEL: 03-3509-7602 / FAX: 03-3509-7605
URL: http://www.bebit.co.jp/
--------------------------------------------------------
◆◆◆お知らせ◆◆◆
・ビービット新刊書籍 『ユーザ中心ウェブサイト戦略』発売
  http://www.bebit.co.jp/news/2006/book.html
  http://www.amazon.co.jp/gp/product/4797333529/