パスワードを忘れた? アカウント作成
19163 story

PostgreSQL 8.3リリース 50

ストーリー by Acanthopanax
高速化やJIS2004対応も 部門より

Driver 曰く、

PostgreSQLの新バージョン8.3.0が2月4日にリリースされました。今回の改良で、PostgreSQLユーザーの多くが幸せになるのはHOT (Heap Only Tuples)でしょう。8.2までのauto vacuumでは、更新/削除トランザクションが多く発生する環境では無効領域が増え続ける場合があったり、vacuumが動作すると他のトランザクション処理が行えなくなるなどの弊害がありましたが、8.3ではHOTの実装によりvacuumの必要性自体が軽減され、PostgreSQLを使用できる場面がかなり増えるだろうと想像しています。

(つづく...)

他のDBを推している人からすれば「vacuumなんて作業が必要になること自体に問題がある」と言われそうですが、vacuum (HDDのデフラグ処理みたいなもの)のような作業は、多くの場合必要になるのではないでしょうか? たしかに、vacuumを行わないと表領域が肥大化し続けるというのは、業務的には許されない場合も多いとは思いますが、その運用さえしていればクリティカルな問題にはならない状況がほとんどではないでしょうか。

PostgreSQL 8.3では、そのほかにも多くの性能改善が実現されているようです。国内ではかなりのシェアを持っており、多くのプラットホームで利用可能です。皆さんもこれを機に使ってみませんか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 参考リンク (スコア:4, 参考になる)

    by Anonymous Coward on 2008年02月05日 19時43分 (#1292117)
    どれも石井さんが書いた記事。
  • FILLFACTOR (スコア:4, 参考になる)

    by Mizar (27267) on 2008年02月05日 21時00分 (#1292136) ホームページ

    HOTによる更新速度向上の恩恵を受けるためにはテーブルの更新対象データが含まれるブロックに空き領域がなくてはならないのですが、テーブルのFILLFACTOR(充填率)はデフォルトで100(%)となっているため、このままでは充分な空き領域が確保できない事が多いと思われます。必要に応じて、更新頻度の高いテーブルにはFILLFACTORの値を設定する必要があるかもしれません。

  • by kanie (911) on 2008年02月05日 17時57分 (#1292076)

    他のDBを推している人からすれば「vacuumなんて作業が必要になること自体に問題がある」と言われそうですが、

    MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。
    そういうときは、OPTIMIZE TABLEを行うことになりますが、これはたんにテーブルを作り直しているだけです。:)

    そのうちauto vacuum的な物が入るのかもしれません。

    • by Anonymous Coward on 2008年02月05日 21時08分 (#1292142)
      あまり知られていないかもしれませんが、SQLite でも vacuum はあります。データベースを便利な入れ物代わりにするような使い方をしているアプリケーションでは、たまに vacuum するとファイルサイズが激減して気持ちがいいものです。

      # Delphi + SQLite の組み合わせが好きなので AC
      親コメント
    • by Anonymous Coward
      まあOracleだってエクステントがぐちゃぐちゃでパフォーマンスが落ちてきたら
      テーブルを作成しなおしてexpしたデータをimpしなおす事もやってたし
      24h運用に致命的でなきゃvacuumもあってもいいかな。

      #最近Oracle使う仕事は他人に振ったので最近の事情は知らない
      • by NaruTo (1519) on 2008年02月05日 19時43分 (#1292116) ホームページ 日記
        PostgreSQL の vacuum の主な処理は「無効領域の解放」です。
        PostgreSQL はマルチバージョニング(トランザクション開始時点の状態のデータにアクセスするための機構)を
        実現するために
        「内部では更新の度に新規レコードを作っている」
        のです。そしてこれを解放する必要が生じするのです。(約2億レコードに達する前に?)

        ですから、
        「Vacuum に相当する機構を行わないOracle」というものは
        「ロールバックセグメントがいつまでも膨れ続けるOracle」
        と考えればいいのではないでしょうか?

        MySQL のことはわかりません。

        # 勘違いだったらやなので AC
        --
        マクロの基本は検索置換(by y.mikome)
        親コメント
        • Re:MySQLでもvacuum必要 (スコア:2, すばらしい洞察)

          by Anonymous Coward on 2008年02月05日 21時13分 (#1292144)
          ># 勘違いだったらやなので AC

          ID持ちのAC悪用って常用になりつつありますね
          親コメント
        • by suexec (16684) on 2008年02月06日 1時40分 (#1292234) 日記
          ロールバックセグメントが膨れ続けるOracleっていうのは違うのでは?
          エクステンション書き出し前の一時領域だし
          vacuumの不要領域との比較はあんまり意味無いかも。

          Oracleは不要領域を再利用してもデータ領域の断片化に対して
          今のところは上手くアプローチ出来ているんじゃない?って思う。
          逆にvacuumで何とかしようってアプローチが限界が来ているんじゃないかな?
          親コメント
          • by L.star (163) on 2008年02月06日 3時44分 (#1292246) ホームページ
            いえ、ロールバックセグメントもPostgreSQLにおける古いバージョンも、ロールバック時のundoログとして働くという点において同じです。そこにあるのは、テーブルファイルの中にそのまま置くか、集中管理するかの違いだけです。

            ロールバックセグメントは、不要領域を集中管理することによってテーブル上の不要領域を意識する必要がなくなると言う反面、ロールバック時や、古いバージョンの検索のためには非常に面倒なロジックが必要になります。一方で、すべてのバージョンを平等に取り扱うPostgreSQLはシンプルで済みますが、ガベージコレクションであるvacuumが面倒になります。

            PostgreSQLの不要領域管理は基本的にシンプルで、今回のHOTのような特定の頻発するケースに対する最適化は初めてじゃないでしょうかね。ようやく最適化に目が向いてきたと言うことで、例えばロールバックセグメント方式採用といった大変更の前に、まずは小さな改善を積み重ねる価値があるんじゃないかと思います。

            親コメント
        • Re:MySQLでもvacuum必要 (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2008年02月06日 4時55分 (#1292250)
          なんかOracleではvacuum不要みたいな発言が続いているけど、何か違わないか。
          確かにOracleはその辺はPostgreSQLより賢いかもしれんけど、
          最高水位標(HighWaterMark)の問題があるのだから、全くないわけではない。

          PostgreSQLのそれは他のDBMSと比べて使用する頻度が多くなるように思うので嫌われているように思うが、その手の処理がないDBMSってあるのか。
          あったとしても他の何かを犠牲にしているだけに思うのだが。
          それは使用目的が異なるDBMSだと思う。

          MySQLのMyISAMだってSQLServerだって可変長項目の断片化に対するので対処するコマンドがある。これだって不要領域の開放。
          SQLServerはデフォルトでクラスタインデックス化されてたりするので割と性能に反映される。
          # 別のコメントでMySQLはInnoDBでとあるけどMyISAMも同様だと思うのだが。
          # ひょっとして5.xとかだと本当に不要になっている?
          親コメント
        • by Anonymous Coward
          >ですから、
          >「Vacuum に相当する機構を行わないOracle」というものは
          >「ロールバックセグメントがいつまでも膨れ続けるOracle」
          >と考えればいいのではないでしょうか?

          想像しただけでゾッとする・・・。
          「内部では更新の度に新規レコードを作っている」の仕様を決めたのは誰だよ。
          • vacuumというデメリットを抱えても、MVCCというメリットがそれを上回る価値がある、と考えたからでしょ。
            「誰だよ」とか言うほどのものかな?

            その上で、デメリットを縮小する努力を継続してしているわけで。
            親コメント
            • by L.star (163) on 2008年02月06日 2時59分 (#1292243) ホームページ

              vacuumというデメリットを抱えても、MVCCというメリットがそれを上回る価値がある、と考えたからでしょ。
              残念ながら順番そのものは逆で、vacuumが昔から存在し、MVCCはあとから、6.4だったかで実装されました。しかし、それを見据えての追記型だったのではないかと思います。

              MVCCのような追記型により読み/書きのロック競合をなくすというのはTime Domain Processingと呼ばれます。単純上書き型が採用するロックテーブルの管理方式とは大きく異なる革新的なもので、Gray本ではPostgreSQLの前身であるPOSTGRESはこれを意識して実装された、と紹介されています。

              元々のポイントは、おそらくロールバックを単純化するためなのではないかと思います。ロールバックセグメントや上書き方式だと、undoログから更新してしまった領域を書き戻すというかなり面倒な一手間がかかります。

              個人的にはこの種の専門的で複雑なロジックから解放されていたことが、PostgreSQLが当初オープンソースで細々と開発を続けることが出来た理由の一つかもしれないな、と思っています。いきなり現状のOracleのような高度なソフトウェアをオープンソースで公開して放り投げられても、おそらく誰もメンテナンスできないでしょうから:)

              親コメント
          • by Anonymous Coward
            別に、ロールバックセグメントなんて面倒なもの用意しなくて済む代償としては安いものだと思うけどな。 # Oracleだって言ってしまえばロールバックセグメント上に新規レコードを作りまくってるわけで
      • by Anonymous Coward
        誰も使ってないでしょうけどDB2もオンラインREORGが使える前には表スペースに無駄が貯まってEXPORTしてDELETE ALLしてIMPORTしていたような気がします。

        #DB2はメインフレームのおまけなのでAC
    • by Anonymous Coward
      > MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。

      空間の仕様効率が50%を割ることはありませんし、処理速度も一定以下に落ちることはないですよ。

      処理速度が異常に遅くなると感じているとしたら、

      1) インデックスがメモリに載りきっていない -> メモリを増やしましょう
      2) 大きな BLOB を使い過ぎ -> BLOB は別ファイルで持ちましょう

      といった、設計の問題だと思います。
  • リリースノート [postgresql.org]を見るとHOTのほかにも、

    Allow col IS NULL to use an index
    IS NULLを使ったときにindexを参照するようになった…って部分は、地味~にパフォーマンスに効くのではないでしょうか。

    まぁ、今回は8.1→8.2以上に変更点が多いとどこぞで聞いた記憶もあるので、移行には十分なテストが必要でしょうけど。

    # 追跡していたのにリリースに気づいてなく、タレコミに先を越されたので悔しいからID
    • by Anonymous Coward on 2008年02月06日 1時45分 (#1292235)
      NULLにindexかあ。微妙だなあ。

      元々SQLのNULLは、データ無しとか未入力とかいう意味じゃなく、
      データが有るか無いかすら「不明」って意味だ。

      (だから大抵の式(関数や演算子)にNULLを1つでも食わすと式全体の値がNULLになる。
      不明を1つでも食わせりゃ全体が不明に汚染されるってことだ。)

      一方「不明」なんてな状態を許す必要が有るカラムは
      現実的にはそう多いわけでもない。
      実際に欲しいのは「不明」ではなく「なし」や「未入力」のほうだということが多い。

      (そういう意味では、NULLのときindexが効かないという制限をRDBが持つのはそれなりに合理的)

      なのにSQLには「なし」「未入力」を表す合理的な道具が無いのだな。
      仕方ないからみんな、「NULL」「'hoge'」「9999」などなどで代用したりするわけで。

      だから

      >IS NULLを使ったときにindexを参照するようになった

      本来これはズレた対応だ。
      「なし」「未入力」でindex参照が出来ればそれで(大抵は)十分だ。

      ただし「なし」「未入力」が無いもんだから、
      仕方なく、代用品であるNULLにindexを許すという逃げが必要になるわけ。

      #そんな歪んだ仕様のSQLが大嫌いなのでAC
      #言語仕様としてのSQLはポカが多すぎる。
      親コメント
      • by Anonymous Coward on 2008年02月06日 5時13分 (#1292251)
        > SQLには「なし」「未入力」を表す合理的な道具が無い
        元々も何も極初期のSQLにはnullなんてものはなかったはずだが。徹底的に正規化すれば「なし」に相当する値が必要になることはありません。存在しないデータは最初からDBに入れなければよいだけです。例えばユーザ表にIDとユーザ名と生年月日のカラムがあって、生年月日未入力がありえるなら、単にそれをユーザ名表とユーザ生年月日表に分ければよろしい。
        そうしないで生年月日カラムにnullを入れるなら、それは単にパフォーマンスチューニングのために正規化をくずしているということなので、それなら効率化のためなら何でも遠慮なくできた方がいいでしょう。
        親コメント
        • by Anonymous Coward
          >>生年月日未入力
          元ACじゃないですけど

          つまりは、例えば ID:生年月日 で表作っといて、IDで検索して見つからなければ生年月日入力されてないという判断を下すってコトですかね。
          生年月日入力が無いIDの一覧を得るって言う利用方法を考えなければおっしゃる通りなのでしょうね。

          たぶん、分析とサービス特化とかの立場の違いなんですかね。

          #個人的にはNULLがほしいAC
          • by Anonymous Coward
            >生年月日入力が無いIDの一覧を得るって言う利用方法を考えなければ

            table human=(id, name)
            table birthday=(human_id, date)

            select human.id
            from human, birthday
            where
            human.id = birthday.human_id(+)
            and
            human_id is null

            …おっと、is nullが使えない世界の話だっけ。

            もっと込み入ったSQLを書いて
            SQL呼び出し回数もケチらなければ
            なんとか(なんとでも)なるけど、
            それじゃ人間も計算機も手間ですね。
            • by Anonymous Coward
              単純に select id from human minus select human_id from birthday; ではいかんのか?
              • by Anonymous Coward
                不可能といいたいわけではなくて、効率的ではなさそうだな、という感想です。
                使い勝手としてはイマイチかな位。

                #スパッと検索条件指定できたほうが気持ちいいと思うだけのAC
        • by Anonymous Coward
          正規化も過ぎると遅くなりませんか?
          設計者の美意識にユーザビリティが引きずられると後がきつい・・・。
        • by Anonymous Coward
          上のACです

          >元々も何も極初期のSQLにはnullなんてものはなかったはずだが。
          >徹底的に正規化すれば「なし」に相当する値が必要になることはありません。

          #私がいった「元々」はNULLの仕様についてであって、NULLの出自についてではありません。

          それはそうとそれは興味深い話ですね。
          SQLにとっての極初期つまり数十年も前においては、(マシンが弱かったため)今よりも遥かに追いにくかったであろう理想を、プログラマに要求する言語仕様だったわけですか。
          えらくバランスの悪い言語だったんですね。

          さて。
          パフォーマンスのことは(特に現代では)置いといてもいい、としましょう。

          でも、確
      • by Anonymous Coward
        繊細すぎる……
  • by Anonymous Coward on 2008年02月06日 1時49分 (#1292237)
    新機能と改良の項目に「更新可能カーソル」ってあるのを見て,
    今まで無かった? ちょっとびっくり。
    oracleで云うところの,FOR UPDATEでOpenして,fetch loop内側で
    CURRENT OF...でUPDATEって事が出来る様になったって事かしらん。

    って,調べてみたら,英語のリリースノートにそのまま載ってました・・・。
    http://developer.postgresql.org/pgdocs/postgres/release-8-3.html
    E.1.3.6. Queries

    こいつは,プログラマにとっては嬉しい機能ではないでしょうか。
    • by Anonymous Coward
      >プログラマにとっては嬉しい機能

      「典型的Webアプリプログラマ(特にそれしか知らない奴)にとっては」
      何のことか判らないかも。

      典型的Webアプリでは
      SELECT FOR UPDATEのようにデータを捕まえておくってことは
      避けるベキとされているようなので。

      表示画面でのSELECT(のためのDBセッション)と
      次の更新画面でのUPDATEとを
      いかに「べつべつに切り離す」か?が重要である、
      とされているようなので。

      でも、
      大量の顧客を右から左に捌く外向きサービスなら
      確かにそれが真なんだけど、
      べつに全てのWebアプリがそういうものとは限らなくて、
      (「限れ」と強制する権利は多分誰にも無い)
      掴んでいることのデメリ
      • by Anonymous Coward
        > どっちもアリなはずなんだ。

        本当にそう思うか?
        いつロールバックするつもりなんだ?

        ステートレスセッションが基本であるはずのwebシステムにおいて、
        状態を維持することが目的のトランザクションがなじまないのは、
        少し考えればすぐわかるだろう。

        そもそも、httpみたいな本質的にステーフルになじまない構造と、
        コネクション維持が可能でステーフルに馴染むクラサバを同一視してるあたりが、
        理解不足ではないだろうか?
        • by Anonymous Coward
          >ステートレスセッションが基本であるはずのwebシステムにおいて、

          多くの(全てとは言わないが)の「Webアプリ」では、
          HTTPのステートレスっぷりをむき出しのまま使ってるわけじゃなく、
          ラッパーでステートフルに見せてますね。

          それによって、上位層から見れば差は無いことになります。
          (期間数十分…数日という)タイムアウトという概念が有る点が違うだけで。

          (というか大抵の通信にゃ
          遥か下位の層にステートレスな層が有るはず。
          それをラップしてタイムアウトつきステートフル通信に見せてる。
          その層の位置が高いか低いかの違いだけ。)

          現実で具体的に何をしているかというと、
          クラサバでは
  • by Anonymous Coward on 2008年02月05日 17時33分 (#1292058)
    個人的には年賀状の住所録ぐらいしか使い道が......
    エクセルとかで十分な気がする^_^;
    • >エクセルとかで十分な気がする^_^;

      Excelも2007になると,100万行/1シートまでOKとの事なので,ますますExcelで十分なような...
      親コメント
      • by deleted user (35572) on 2008年02月05日 21時06分 (#1292140)
        理論上は扱えても、物理的に扱えないんじゃないですか?

        #2007があまりに重過ぎるのにびっくりした。
        親コメント
        • by Stealth (5277) on 2008年02月05日 21時32分 (#1292153)

          物理的に扱えないというと zip ファイルの仕様的に無理という話ですか? 中のデータは単なる XML ファイルなので理論的にも物理的にも (リソースが十分にあれば) 普通に扱えるでしょう。

          P3 1.2GHz/RAM 1GB なマシンで以下の操作をしてみました。

          • A1 に =RANDBETWEEN(1,100) を入力 - 一瞬で終了 (当たり前)
          • A2 ~ A1048575 のセルに A1 の内容をコピペ (A2 ~ A1048575 のセルで 1 ~ 100 の値をランダムにセット) - 7 ~ 8 秒
          • A1048576 のセルに =SUM(A1:A1048575) を入力 - 1 ~ 2 秒

          この程度なら、重すぎるという程重いかなぁ? という感じがします。

          さすがにこれを元にグラフ描画とかであれば時間はかかるでしょうけど、この程度の速度が出ていれば一般的な用途では問題になる程の遅さは感じられないと思いますが。

          # UI が重いって話であっても、これを試したマシンでも「まぁ普通じゃない?」という程度なのですが……。

          親コメント
          • by deleted user (35572) on 2008年02月05日 22時50分 (#1292186)
            色々と試していただいてなんですが、ここは笑い飛ばすところ!

            #ネタなんだからね!
            親コメント
            • by Anonymous Coward
              どのへんがネタになってるんでしょうか?
              「物理的に無理」ということになると色々影響が出るので、
              リアルな実例をお願いしたいです。(HDDが一杯とかじゃなく)

              事実が無いなら、コメントを撤回して下さいな。
          • by Anonymous Coward
            ひとりで盛り上がっているところ悪いんだけど

            > 物理的に扱えないというと zip ファイルの仕様的に無理という話ですか?

            この時点で間違ってますよ。
            何で物理=zip仕様って解釈できるかなあ?
            • by Stealth (5277) on 2008年02月06日 0時14分 (#1292204)

              単に gzip の物理制約 (ヘッダの構造上 4GB までしか取り扱えない) を思い出しただけですよ。

              メモリ的な物理制約や 32bit アプリとしてのハンドリング可能なメモリ量といった言うまでもない話をわざわざ取り上げる、なんて思えませんし。

              親コメント
              • by Anonymous Coward
                gzipの「物理」制約ってなんですか?
                布団は圧縮できないってこと?
            • by Anonymous Coward
              誤りを指摘するだけじゃなく正解まで書けばいいのに

      • by Anonymous Coward
        一年生になったら、友達100万人できるかな♪

        .......ぜったい無理だって^^;
  • by Anonymous Coward on 2008年02月05日 17時41分 (#1292064)
    autovacuumが実装されたときも同じこと言ってたよね。
    結局vacuumeしなくてよくなるのはいつなのさ。
    • by Anonymous Coward
      8.2:autovacuumをデフォルト無効で実装
      8.3:(HOTのおかげでvacuumの負荷が減ったから)autovacuumをデフォルト有効に変更
      OK?
      • by Anonymous Coward
        じゃ、ユーザーはもうvacuumを一切意識しなくていいってこと?

        # それが望まれてるんだよね?
  • by Anonymous Coward on 2008年02月05日 20時41分 (#1292129)
    >vacuumを行わないと表領域が肥大化し続けるというのは、業務的には許されない場合も多いとは思いますが、その運用さえしていればクリティカルな問題にはならない状況がほとんどではないでしょうか。

    けむにまいてごまかす論理展開ではなく、問題にならないことを証明してみてください。 その運用がちゃんとできないような作りだから問題なんですよ。
    • Re:vacuum (スコア:4, すばらしい洞察)

      by vzg02111 (4390) on 2008年02月05日 23時16分 (#1292196)
      > 問題にならないことを証明してみてください。

      タレコミ文には「その運用(=必要なときにvacuum)ができるなら」PostgreSQLは実用に足りる(場合が多い)でしょ? と書いてあるわけで、
      「vacuumすれば問題はすべて解決!喝!」とは書いてないと思いますよ。

      > その運用がちゃんとできないような作りだから問題なんですよ。

      PostgreSQLの設計上の問題で「(とあるアプリケーションにおいて)必要なときにvacuumを行うことが出来ない(結果、表領域が肥大化してしまい業務的に許されない状況が起きてしまう)から問題」と仰っているのだと思いますが、だったら(そのアプリケーションには)PostgreSQLは使えないと判断されたわけですよね?
      そのアプリケーションに利用するには、今までのPostgreSQLでは力不足だったということですから、当然、別の(vacuumの要らない)DBMSをお使いになっているわけで、それはそれで何の問題も無いのではないでしょうか。

      で、今度のバージョンでは、そのvacuum(というか表領域の扱い)関連の改善がされているようですね。
      ということは、上のようにvacuumが問題になってPostgreSQLを使えなかったアプリケーションでも、今後はPostgreSQLを使える可能性があるかもしれないということです。
      問題になるかならないか、再評価を行ってみるのもいいかもしれませんね(少なくとも新規の案件では選択肢に入ってくるでしょう)。
      親コメント
    • by Anonymous Coward
      そーいや最近デフラグやスキャンディスクしてないなー、まいっか
      って程度
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...