パスワードを忘れた？ アカウント作成
Close
14862 story

PostgreSQLのINSERT/UPDATEを数十倍高速化するSigres 31

ストーリー by kazekiri
未踏の成果か 部門より

zonkerman 曰く、

SourceForge.jpにて、PostgreSQLのINSERT/UPDATEを高速化するSigresというプロジェクトがあるのだが、11日のSigres-0.1.3のリリース発表において、このSigresは 通常のPostgreSQLに比べINSERTやUPDATEが数倍から数十倍高速化されているということが書かれている。少々驚いたが、何となくwriteとfsyncの呼び出しを最小限にしているような感じである。PostgreSQL開発者のBruce Momijian氏はメモリファイルシステムにWALファイルを置けばいいと考えているようであるが、 Sigresの開発者はそれでは大した性能向上はないことと、チェックポイントレコードすらメモリファイルシステム上にあるのは危険と述べている。 上流で議論を開始しているように見えるが、さて手法については皆さんどう思うだろうか？

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

PostgreSQLのINSERT/UPDATEを数十倍高速化するSigres More

  • この手の高速化って (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2007年03月12日 11時56分 (#1124568)
    やったふりして仕事をためておいて、後でまとめて処理することで高速化をはかる、ただし破綻しない範囲で、ってことですよね。

    私も昔、「やったよ」と返事だけしてためていました。夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、と言いたいとこですが…。そして今もその癖はなおっていません。

    -- A.C., nothing more, nothing less.

    • Re:この手の高速化って (スコア:3, 興味深い)

      by kicchy (4711) on 2007年03月12日 20時47分 (#1124835)
      ＞私も昔、「やったよ」と返事だけしてためていました。
      ＞夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、
      ＞と言いたいとこですが…。そして今もその癖はなおっていません。

      問題は、EoV実施フェーズにおいて
      おなかを出して寝ていて風邪を引いたりなどの実施を
      阻害する要因が出てきてしまうことを懸念しなくてはなりません。

      今回の議論は、
      絵日記は、後で出来るので遅延実施、
      ただし、観察日記の場合、日記自体の書き出しは遅延出来るが
      水やりなどはリアルタイムでやらなくてはならない。
      この遅延させてよい事象と駄目な事象はどれなのかという議論
      (WALファイルとかいうのが水やりに当たる？)
      と
      風邪を引かずに、うまく夏休みの終盤EoV実施フェーズを
      乗り切るためのにどうすればよいかという
      ことだと認識しておいてよいでしょうか？
      シェア
      親コメント

      • Re:この手の高速化って (スコア:1, 興味深い)

        by Anonymous Coward on 2007年03月12日 21時52分 (#1124891)
        Sigresプロジェクトの言い分は、

        「8月31日にお父さんに手伝ってもらうことで処理の高速化を狙うと、その日残業だったり酔っぱらって帰ってきたときに危険である」

        であり、それに対する反論としては

        「お父さんはそもそも手伝ってくれない。せいぜい夜中に様子をみにきて、居眠りしていたら起こしてくれるだけ」

        ということだと思われます。

        -- A.C., nothing more, nothing less.
        シェア
        親コメント

        • Re:この手の高速化って (スコア:1)

          by kicchy (4711) on 2007年03月12日 22時16分 (#1124908)
          ＞「8月31日にお父さんに手伝ってもらうことで処理の高速化を狙うと、
          ＞　その日残業だったり酔っぱらって帰ってきたときに危険である」

          ＞であり、それに対する反論としては

          ＞「お父さんはそもそも手伝ってくれない。
          ＞　せいぜい夜中に様子をみにきて、居眠りしていたら起こしてくれるだけ」

          いいお父さんじゃないですか(´Д⊂

          # そういう話じゃない？
          # どちらも、「最後は自分の力が頼りである、
          # 大事なのは夏休みの終わりまで宿題残さないこと」って主張に見えるけど... :-D
          シェア
          親コメント

    • Re:この手の高速化って (スコア:1)

      by adeu (2937) on 2007年03月12日 12時56分 (#1124618)
      モデレート権があればすばらしい洞察にしたいところ。
      シェア
      親コメント

    • Re:この手の高速化って (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2007年03月13日 3時16分 (#1125018)
      > 私も昔、「やったよ」と返事だけしてためていました。夏休みの宿題とか。8月31日だけで処理できてかなり高速化できましたよ、と言いたいとこですが…。そして今もその癖はなおっていません。

      私はさらに、やらなくて良いことはやらないことによって最適化を図る方法を開発しました。リスクは高いですが、夏休みの宿題なんて、バックれても問題はありませんでした・・・。

      # そしてダメな大人になった
      シェア
      親コメント
      • > 私はさらに、やらなくて良いことはやらないことによって最適化を図る方法を開発しました。

        これは現在、コンパイラの最適化技術に適用されています。データフロー解析によって、まじめに処理してもしなくても結果に関係のない部分は省略されます。

        たとえば、変数iを1増やす文だけを10万回ループさせる場合、ループせずにiに10万を加えて済ませます。そのiが後で使われなければ、この部分自体なくなります。

        一連のコメントから、「夏休みの宿題」、特に「いかに逃れるか考える」ことが技術の発展に大きく寄与していることがわかりました。以上オフトピックすぎてごめんなさい。
    • 割とよくある高速化方法ですね。
      寡聞にして正式な名を知りません。

      ここはひとつ、End Of Vacation - EoV手法と名づけて普及させましょう;-)
  • リリースノートを見てもタレコミ文章以上の情報は無いし、
    プロジェクトサイトを見てもやはり情報は無く、
    フォーラムやMLのアーカイブにもやはり何の投稿も無い。

    これで何を語れというんだろうか…？

    • 「信頼性を犠牲」「効率的な挿入」「速い」 (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2007年03月12日 13時10分 (#1124626)
      エロい人のコメントでも待ちますか…
      シェア
      親コメント
    • 同感。「ソース読め」状態なせいで癖とか勘所がわかりにくいので、
      試験的に使ってみるにしてもちょっと踏み切りにくいですね。
      「tmpfsだと遅い」というのはkernelのファイルシステム層がオーバーヘッドになってるってことでしょう。
      だとすると、WALの管理のうちファイルシステム任せにしてる部分を自前管理に変更してる…のかな？
      # 憶測なんでその程度しか信用しないように。為念。

      Sigres自体は2006年度上期IPA未踏ソフトウェア創造事業の採択プロジェクトで作られたもののようです。
      http://www.ipa.go.jp/jinzai/esp/2006mito1/gaiyou/4-37.html [ipa.go.jp]
      先日報告会があったようですが詳細なレポートなどは発見できず。

      あと、0.2への構想(マルチコアを前提としたWAL実行の並列化)もあるみたいで。
      http://lists.osdn.jp/mailman/archives/sigres-all/2007-February/000002.html [osdn.jp]
      シェア
      親コメント

    • Re:情報が少なすぎ (スコア:1)

      by kabaolaf (33678) on 2007年03月13日 23時41分 (#1125612)
      開発者の川島です。 文書がなくて申し訳ありません。 Sigresの基本哲学は、信頼性を若干犠牲にして、性能を向上させることです。 それゆえ現時点ではミッションクリティカル向きではありません。 しかし、不揮発メモリが当たり前の時代になれば、Sigres方式をあらゆるDBMSが使うようになるでしょう。 Sigres-0.2.0ではXLogInsertレベルでの高速化を実現します。 他にもH2やMySQL/Falconでの高速化を設計中です。 コメント、ご意見など、どうぞよろしくお願い申し上げます。
      シェア
      親コメント

  • Sigresの開発者に同意 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2007年03月12日 12時03分 (#1124574)
    メモリファイルシステム上にチェックポイントレコードを置いて、電源落ちた時どう整合性とる
    のでしょうか。
    整合性をとれないのならRDBMSとは言えないですよ。

    • Sigresの開発者は勘違い (スコア:2, 参考になる)

      by Anonymous Coward on 2007年03月12日 18時42分 (#1124779)
      チェックポイントレコードのキャッシュをメモリ上においているだけ。 本体はファイルに書き出している。何の問題も無い。
      シェア
      親コメント

    • Re: Sigresの開発者に同意 (スコア:2, すばらしい洞察)

      by to (16347) on 2007年03月12日 22時26分 (#1124916)
      リレーショナルデータベースを管理するシステムであれば、整合性が取れる取れないに関係なくRDBMSと言っても良いと思います。
      シェア
      親コメント

    • Re: Sigresの開発者に同意 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2007年03月12日 13時08分 (#1124625)
      大丈夫。

      UPSをつければ、電源が1回落ちる間にLinuxカーネルは100回は落ちるから。
      『電源が落ちたときは』深く考えなくても (^o^)。

      # 当たり前と言えば当たり前だが、高い負荷がかかるとかなりの確率でこける。
      # RHEL4 だと U4 でも、Vanilla 2.6.17 で出たこのパッチが当たってないとか
      #
      # commit 993dfa8776308dcfd311cf77a3bbed4aa11e9868
      # Author: Trond Myklebust <Trond.Myklebust@netapp.com>
      #Date: Fri Mar 31 02:30:55 2006 -0800
      # [PATCH] fs/locks.c: Fix sys_flock() race
      シェア
      親コメント

    • Re: Sigresの開発者に同意 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2007年03月12日 15時58分 (#1124708)
      ＞メモリファイルシステム上にチェックポイントレコードを置いて、電源落ちた時どう整合性とるのでしょうか。
      ＞整合性をとれないのならRDBMSとは言えないですよ。

      全部Roll backするという手があります。IMSのMSDB(めいんすとれーじでーたべーす)がそれです。（あれはRDBじゃないけどね）

      # 中の人なので本当にAC
      シェア
      親コメント
    • そこが「UPSの存在を前提」＝「電源が落ちたときのことは考えない」ということでしょう。
      だからって安心できるわけじゃないけど・・・

      • Re: Sigresの開発者に同意 (スコア:1)

        by JBD01226 (10061) on 2007年03月12日 12時16分 (#1124584)
        マシンが突然リセットしたり電源が死んだ時の話だとどうなるんだろう。
        たとえばRAIDカードはバッテリが乗っかっててマシンが不意にリセットされてもキャッシュを保持したりする。
        シェア
        親コメント
        • こけても問題ないプライベート用途か、すべてのポイントで障害対策を講じてあるエンタープライズ用途以外は使うなということかな?

      • Re: Sigresの開発者に同意 (スコア:1)

        by pollux (23211) on 2007年03月12日 15時25分 (#1124702)
        ずいぶん昔、OracleがREDOログをsyncなしででwriteしてそれだけのことで3倍ぐらい
        早くなったそうです。Linux用のベータ版でのバグでもちろんOracleはすぐに直してます。
        こういう内容ならそれはバグであって、早くなる方法とはいえないでしょう。
        えらい人、教えて。
        シェア
        親コメント

  • 門外漢ですが (スコア:0, 余計なもの)

    by Anonymous Coward on 2007年03月12日 11時30分 (#1124551)
    あのぅ、これ以上メモリ食わないでくださぃ
    • 私も門外漢ですが。

      今の DBMS は read/write でデータを読み書きしている。write はともかく、read の方は、
      read only な mmap にしてくれないかな。変更するときにコピーをとって write するって事で。

      というのは、read/write は kernel 側と DBMS 側に1つづつページのコピーを持っている。
      kernel 側は「手元にあるこのキャッシュのコピーは、DBMS 側がもっているあのページと
      同じものだ」という事が判らないので(read とは「コピーしてよこせ」という意味ですので)
      これじゃ、4Gあったとして、全部データに使えても実質2Gbyteしか使えない事になる。
      mmapなら kernel cache と DBMS 側のページが「同じもの」と判るので、少しだけでも
      この無駄が減る。

      高速化の前にこの辺の無駄を削ってからの方が、トータルスループットが快適に上がると思うだが…。
      --
      fjの教祖様
      シェア
      親コメント

      • Re:門外漢ですが (スコア:2, 興味深い)

        by L.star (163) on 2007年03月12日 14時07分 (#1124668) ホームページ

        今のPostgreSQLのボトルネックは、8.1以降大きく解消したとはいえ各種内部ロックなので、mmap()にしてもそんなに快適にはならないような気がする。

        それに、キャッシュのヒット率を上げるなら、メモリの有効活用よりバッファアルゴリズムを改良するとか他にやることがある。まあ、mmap()辺りの話は昔からずっと言われている割には全然実現していないので、移植性の問題か、はたまたみんなやる気がないのかな、とか思っている。

        シェア
        親コメント
      • ( mmap() + munmap() ) × n は
        fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、
        一般的な32bits環境では mmap() しっぱなしでどうにかなる
        全体が4GB未満のデータベースでしか速くならない
        ってことになるんじゃないですかね。

        • Re:64bits向けなら好し(?) (スコア:2, 興味深い)

          by okky (2487) on 2007年03月12日 14時56分 (#1124690) ホームページ 日記
          うーん。 mmapを使う事でコピーを減らしてメモリの利用効率が上がると、n の数自体が減ると思いますが。 # 十分多きな DB に対しては変わらんか。 あと、前から思っているんだけれど… > ( mmap() + munmap() ) × n は > fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、 これ本当かなぁ?? いや、advice なしで mmap/munmap 使ったら、sequential read では、遅いのは全くもってその通りと思うけど…。 # 文字通りの on demand になるので、4kbyte づつ粉々に、ランダムに読み込むのに等しい。 # それなら、fread() がキャッシュを使って、一気に数Mbyte読むように仕向ければ、 # 圧勝だろう、と私も思う。 『HDDとのIOが支配的』な世界では、madvise で MADV_SEQUENTIAL と MADV_WILLNEED 与えれば、実質 fread() と同じ HDD IO 挙動をしてくれるはず。順番にアクセスするぞ、必要になるぞ、さぁ先読みしろ、と教えるわけですから。『大抵遅い』になるとは到底思えない。 # 時間が出来たら実験しよう…。
          --
          fjの教祖様
          シェア
          親コメント

      • Re:門外漢ですが (スコア:0)

        by Anonymous Coward
        そこで、GNU Hurdですよ

  • forkせずにパッチで配れば？ (スコア:0)

    by Anonymous Coward on 2007年03月12日 16時39分 (#1124728)
    • PostgreSQL8.2.1ベースだから、CVE-2007-0555やCVE-2007-0556の脆弱性を抱えたままですよ。
    • 今後のメンテも考えれば(セキュリティ対応も然り)、forkせずにパッチとしてリリースし、最終的には本家に取り込んでもらう方向で進めた方がいいんじゃないかなぁと。PostgreSQL8.2.1とdiffをとってもさほど大きくないし(22KB程度)。

    • Re:forkせずにパッチで配れば？ (スコア:2, 興味深い)

      by Anonymous Coward on 2007年03月12日 23時57分 (#1124962)
      取り込んでもらうためにパッチを提出したそうです。初めはいい感じの反応をもらっていたそうなんですが、

      PostgreSQL開発者のBruce Momijian氏はメモリファイルシステムにWALファイルを置けばいいと考えているようである


      で、おあずけのようですよ。
      シェア
      親コメント
typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家