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

PostgreSQLのパフォーマンスはMySQLを凌ぎOracleに肉迫 40

ストーリー by mhatta
まあそりゃそうだろうなあ 部門より

Anonymous Coward 曰く、

本家/.の記事より。Standard Performance Evaluation Corporation (SPEC)が発表した新しいベンチマークの結果によると、現在のPostgreSQLのパフォーマンスはOracleに肉薄しており、MySQLには勝るか互角であると言う(ただし他のDBシステムのテスト用ハードウェアはPostgreSQLで使われたものとは若干異なる)。テストはSunで働くPostgreSQLのコアデベロッパによるもので、その意味でもバイアスがかかっていないとは言えないが、しかしこれはPostgreSQLに関する最初の「本格的な」ベンチマークだと言う(今回ベンチマークを行ったPostgreSQLのコアデベロッパJosh Berkusのブログの記事)。以前のベンチマーク(や印象論の類)との違いは、PostgreSQLに適切なチューニングを施したかどうかにあるようだ。

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

PostgreSQLのパフォーマンスはMySQLを凌ぎOracleに肉迫 More

  • Oracleとの比較 (スコア:5, 参考になる)

    by Anonymous Coward on 2007年07月10日 23時38分 (#1187536)
    レポートで一番違いが見えるのはこのへんかと思います。

    PostgreSQL
    Storage Requirement Info:
        The 85 minute run for this submission required less than 4GB of database storage.
        This extrapolates to less than 70GB for a 24 hour period.
        The Sun StorageTek 2540 Array drive capacity is 876GB of available storage when configured for RAID 1.

    Oracle
    Storage Requirement Info:
        A 75 min run at Injection Rate of 670 increased storage by 1260 MB. Extrapolating
        for 24 hrs we need 24.0 GB. The system is configured with over 975 GB of storage.

    Oracleのデータ増加は単純にレコードが増えた分の増加だと思いますが、
    追記型アーキテクチャであるPostgreSQLの方は
    更新前データをそのまま蓄えているため増加量が大きくなっています。
    そのため、実際のシステムでは時々VACUUMというデフラグみたいな処理をかける必要があります。

    パラメータ一覧をみてもautovacuumをtrueにはしていないので、
    ベンチマーク中はVACUUMもVACUUM FULLもしてないと思います。
    そのため、PostgreSQLの結果は試験時間が3,600秒しかないことを見越した
    瞬間最大風速であることに注意してください。

    お仕事でDB構築をされる方は、この結果で「PostgreSQLは使える！」と判断する前に
    autovacuumをtrueにして何割性能劣化するのか、あるいはVACUUM FULLをかけるために
    何時間システムを止める必要があるのか、といった点を調査する必要があります。

    8.3でこのへんの改良が入るそうなので、私としてはそちらに期待しています。
  • 皆さん勘違いしているようですが、 SPECjAppServer2004というのはRDBMSの性能を測定するベンチマークではなくてアプリケーションサーバーのベンチマークなんですよ。これがTPC-Cとかだったらもっとインパクトがあったんですけどね。残念。
    http://www.spec.org/jAppServer2004/ [spec.org]

    RDBMSのベンチマークで言えばIPAでやったDBT-1等のベンチマークの方が網羅的ですよ。
    http://ossipedia.ipa.go.jp/ [ipa.go.jp]

  • 適切なチューニング (スコア:1)

    by yasudas (5610) on 2007年07月10日 20時15分 (#1187470) 日記
    「適切なチューニング」って...

    デフォでパフォーマンスが出ないとか、
    特種な設定やらテーブル組しないとダメ
    というのを言ってしまっている様に思える。

    チューニングが必要ならStartsPackみたいなのを同梱しちゃうとか出来ないかな？

    • Re:適切なチューニング (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2007年07月10日 20時55分 (#1187482)
      うーん、DB屋からすると大量データを扱う基幹系やDWH系だとチューニングして
      当たり前、設計・構築前からチューニング前提という感じなんですが。

      チューニングしなくても十分パフォーマンスが出るようなデータ量や構造ならば
      どれ使ってもいいんじゃないですか、好きなのどうぞと回答することにしてます。

      まあ、サーキットを走らせようという車とそこらの生活道路を走る車を同列に
      扱うこと自体意味がないのと一緒ですから。こういうDBパフォーマンスモノの
      記事は専門でやっているのでなければ、そういうもんかと思っておけばいいん
      ではないでしょうか。

      DBの自律チューニングが発達すればいいという発想もありですが。
      シェア
      親コメント

      • C言語は遅い (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2007年07月11日 13時11分 (#1187796)
        一プログラム屋から見ると

        > うーん、DB屋からすると大量データを扱う基幹系やDWH系だとチューニングして
        > 当たり前、設計・構築前からチューニング前提という感じなんですが。

        というのは16ビットの時代あたりで
        「C言語で普通に組むと遅いからボトルネックはregister変数をつかったり、
        アセンブラで書き直すのが当たり前」
        って考えていたのと似ている気がします。

        ＃プログラムとDBで諸条件が違うのは認識している…つもりですが。

        ですので、今日のコンパイラが（ある程度ですが）
        自動的に最適化してくれるのと同じように
        DB自身もそれなりにデフォルトで動いてくれるように
        なるのが健全だと思っています。

        ＃そうするとDB資格で各社が儲けられなくなるからそうしない
        ＃…という陰謀説を唱えるつもりはありませんが
        シェア
        親コメント

      • Re:適切なチューニング (スコア:1, 興味深い)

        by Anonymous Coward on 2007年07月10日 21時10分 (#1187488)
        Postgresの場合システム込みでチューニングしなきゃ起動すらままならんわけで、
        Postgresが食うメモリをアレやコレや設定したり、
        Kernelが食うメモリもアレやコレや設定したり。
        そーゆーの込みで「適切なチューニング」言ってるんじゃね？

        # アホなSIerがPostgresの居るHWにアプリを載せた場合
        # アプリがリークしてPostmasterが死ぬのは良くある事故だよねぇ
        シェア
        親コメント
        • PostgreSQL + Solaris の場合、データファイルを置く
          ファイルシステムが ZFS なのかっていうのも問題。

          追記型DB + 追記型ファイルシステムって相性的にどうよ？って
          のが気になる。

          # 多分、Sun の技術者は「相性よし」と考えてPostgreSQL を
          # 採用したんだろうな。
          シェア
          親コメント
        • > # アプリがリークしてPostmasterが死ぬ

          だからここでSolarisなわけですよ（ｗ
      • >うーん、DB屋からすると大量データを扱う基幹系やDWH系だとチューニングして
        >当たり前、設計・構築前からチューニング前提という感じなんですが。

        それは、わかるりますが...このトピックの

        >以前のベンチマーク(や印象論の類)との違いは、PostgreSQLに適切なチューニングを施したかどうかにあるようだ。

        ということは、一般に行われるであろうベンチマークに耐えないレベル
        を提供しているのか、そもそも「適切な」チューニングとは、その
        ベンチマークにのみ特化したチューニングなのか？という意味で疑義を
        提示したわけなんですけどね。

        ＞DBの自律チューニングが発達すればいいという発想もありですが。

        というよりはチューニングのための指標すら以前はないままで
        ベンチマークやってたのかな？とも思える。

        Notes / Tuning Informationとか見ると、結構OSに絡んだこと
        やっていますよね？「Postgres compile flags used GCC for
        SPARC compilers」といったところとか見ると、自律チューニング
        以前の、原始的すぎることしないとPostgreSQLはだめないかな？
        と思うわけです。
        シェア
        親コメント

        • Re:適切なチューニング (スコア:4, 興味深い)

          by magicalchalk (27784) on 2007年07月11日 11時53分 (#1187739)

          > Notes / Tuning Informationとか見ると、結構OSに絡んだこと
          > やっていますよね？「Postgres compile flags used GCC for
          > SPARC compilers」といったところとか見ると、自律チューニング
          > 以前の、原始的すぎることしないとPostgreSQLはだめないかな？
          > と思うわけです。

          MySQL を Linux で動かす場合は、バイナリディストリビューションをインストールして設定ファイルだけ変更するのが推奨です。それは簡単に性能が出るからではありません。性能を出すのが難しいと MySQL AB. が認めているからです。

          以下のテキストを読まれた後で、それでも何をすべきか分からない場合には、まず弊社のバイナリを試してみてお客様のニーズに合うか決めてください。

          その最適化は glibc のリコンパイルから始まっています。

          DB サーバの最適化は、そんなローレベルから始まるものだと観念しました。

          シェア
          親コメント

        • Re:適切なチューニング (スコア:3, 興味深い)

          by Anonymous Coward on 2007年07月11日 1時10分 (#1187565)
          >自律チューニング
          >以前の、原始的すぎることしないとPostgreSQLはだめないかな？

          えーと、もしかして他のDBはしなくてもよいと思ってますか？
          暇なときに近くにいるDB技術者(大規模な設計・構築をこなせる人)を捕まえて
          話を聞いてみるといいですよ。

          結局、今までは海外ではMySQLほど使われないPostgreSQLをちゃんと評価
          しようという試みがなかったが、今回やってみたら案外いい感じじゃん？
          というのがブログのお話なんではないかと。

          #1年ほど前に5種のDB製品評価を手伝ったことがありますが、
          #一番作業工数がかかったのは各DBでいい値が出るようにチューニング
          #することでした。そんなもんですよ。
          シェア
          親コメント
          • ＞えーと、もしかして他のDBはしなくてもよいと思ってますか？

            ええ。少なくともOracleでGCCのパラメータはいじった記憶がないので....

            ＞今回やってみたら案外いい感じじゃん？

            あ、それは納得しているんですよ。
            でも、それが「適切なチューニング」を以前はしていないというのが謎なわけね。
            でもって、GCCのパラメータとか言っているのは..と思うわけですよ。
            • ＞＞えーと、もしかして他のDBはしなくてもよいと思ってますか？
              ＞
              ＞ええ。少なくともOracleでGCCのパラメータはいじった記憶がないので....

              ヒント：PostgreSQLはソース配布、Oracleはバイナリ配布。
              • ＞馬鹿じゃないの？

                ええ、君は馬鹿なんだろうね。
                適切なコンパイルできる環境が提供されていないということなんだろうね。
                まわりがガラクタだと、中心部分が優秀だったとしても、無駄なだけだと思うよ。
              • ＞まわりがガラクタだと、中心部分が優秀だったとしても、無駄なだけだと思うよ。

                実際、PostgreSQLはそういう状況だったわけだ。
                ソース配布であるにもかかわらず、適切なチューンを施したコンパイルも出来ないmakeファイルを配布していたわけだ。
                チューニングパラメータにコンパイル最適レベルを探さないとダメとしたら、それはもはやDBチューニングではないだろ？という当然に、答えられないわけですから...
                そこらへんを考えて配布すると、本領が発揮できてよいと思うのですけど、/.Jにはそういう意見にはマイナスなんでしょうね。
                シェア
                親コメント

        • Re:適切なチューニング (スコア:2, 興味深い)

          by Anonymous Coward on 2007年07月11日 4時09分 (#1187614)
          postgresのチューンを始めようとしてちょいと調べるだけですら
          ディストロデフォルトでの設定ファイルがイカレポンチというか極めつけにミニマムな設定だか思い知らされます（適当にディストロインストールするとこれなんだよね、しかもとりあえず実験するのに十分うごいちゃう）

          これをLAMPの適当な設定を仮定して、積んでるメモリとCPUからこれくらいメモリほしいにょと言う設定ファイルを書き出すスクリプトを添付する（デフォルトの設定ファイルのかわりにね）だけでも全然違うんじゃないのかと痛感します。

          #趣味で使うにしてもせめてシェアードメモリ設定くらいかえてあげようよ～、いやマジで
          シェア
          親コメント
    • それは「使い方による」ってことで無理じゃない？

      ## 全く話は変わりますが ##
      スクリプトの書き方とかバッチの流し方とか、既にあるものの移行手段かな。あとは。
    • データベースは使えてなんぼなので、それぞれのDBMSにあった適切なチューニングを施すのは当然ではないのかな？
    • s/StartsPack/StatsPack/

      じゃないかな。
      #ごめんなさい、これだけです。
    • 普通に少し勉強すりゃいいんじゃないの？
      怠けてる奴ターゲットにオート車にされると
      ギアチェンジで効率よく運転したい我々に迷惑です

  • 適切なチューニングを施した最初の「本格的な」ベンチマーク (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2007年07月10日 21時31分 (#1187494)
    つまり、今までは、ベンチマークに臨んでも適切なチューニングを施せる技術者がいなかったという事実を露呈。
    やっと適切な高レベルDB技術者を貼り付けるぐらい売り物になったというか、
    または売り物にする目論見が立ったというか。

  • せっかくSunの人なんだったら・・・ (スコア:0)

    by Anonymous Coward on 2007年07月10日 20時13分 (#1187467)
    Solaris 10 x86とか、Solaris10+CoolThreadなTシリーズでベンチをとってほしかった・・・

  • 適切ではないです (スコア:0)

    by Anonymous Coward on 2007年07月10日 20時59分 (#1187483)
    自分に有利な条件での結果ですね。

    • Re:適切ではないです (スコア:5, すばらしい洞察)

      by Anonymous Coward on 2007年07月10日 21時19分 (#1187492)
      他でも書かれてるけど、チューニング無しでDBを使う事が現実にはありえない以上、
      有利になるようPostgreSQLをチューニングをする事は無条件に不適切とはいえません。
      むしろ対抗となるDBのチューニングが適切だったかの方が重要です。
      シェア
      親コメント
      • 揚げ足をとるようだが、括弧でいちいち細かく日本語表現を
        補足する記事は気になりますね。

        そこまでするなら。いっそのこと括弧がないほうがすっきり
        するんじゃね？＞記者様
        • それは
          (cdr (car '((slash dot) jp)))
          を
          cdr car 'slash dot jp
          にせよと言っているような物だ。
          どっちのほうが分かりやすいと思ってるんだ？
          • 逆ポーランド記法にすれば括弧なくなって読みやすくなるよ。
          • cdr car 'slash dot jp
            せんせい木のくくりかたまで消滅してます！

            #読むときは括弧じゃなくてインデントで行おうねって師匠がいってた

    • いやOracle CorporationがやったOracleの結果と比較してという話でないの？
      誰かソース見て

  • 建前では (スコア:0)

    by Anonymous Coward on 2007年07月11日 0時30分 (#1187551)
    Oracleの利用規約でベンチマーク禁止になってなかったっけ。

    # バカ正直にしたがってたらなにもできないのでAC

    • Re:建前では (スコア:2, すばらしい洞察)

      by kicchy (4711) on 2007年07月11日 0時38分 (#1187553)
      ＞Oracleの利用規約でベンチマーク禁止になってなかったっけ。

      いや、ベンチマーク結果の公表が駄目だったはず。
      ベンチマークするのは当たり前でしょ。

      システムでどれくらいのパフォーマンスを出すか
      見積もることを禁じたら採用する所無くなりますよ。
      シェア
      親コメント

  • /.erって天邪鬼よね (スコア:0)

    by Anonymous Coward on 2007年07月11日 0時43分 (#1187555)
    このストーリーのタイトルが「PostgreSQL、SPECベンチマークでOracleに惨敗」だと、
    PostgreSQL擁護意見がたくさん出てきてたんじゃないかな。
typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人