PostgreSQL8.3リリース 50
タレコミ by Driver
Driver 曰く、
PostgreSQLの新バージョン8.3.0がリリースされた。
今回の改良でPostgreSQLユーザーの多くの人が幸せになるのはHOTであろう。
8.2までのauto vacuumでは、更新/削除トランザクションが多く発生する環境では無効領域が増え続ける場合があったり、vacuumが動作すると他のトランザクション処理が行えなくなるなどの弊害があったが、8.3ではHOTの実装によりvacuumの必要性自体が軽減され、PostgreSQLを使用できる場面がかなり増えるだろうと想像しています。
他のDBを推している人からすれば「vacuumなんて作業が必要になること自体に問題がある」と言われそうだが、vacuum(HDDのデフラグ処理みたいなもの)のような作業は、多くの場合必要になるのではないでしょうか?
確かに、vacuumを行わないと表領域が肥大化し続けるというのは、業務的には許されない場合も多いのだとは思いますが、その運用さえしていればクリティカルな問題にはならない状況がほとんどではないでしょうか。
そのほかにも多くの性能改善が実現されているようです。
国内に限ってはかなりのシェアを持っており、多くのプラットホームで利用可能です。
皆さんもこれを機に使ってみませんか?
参考リンク (スコア:4, 参考になる)
FILLFACTOR (スコア:4, 参考になる)
HOTによる更新速度向上の恩恵を受けるためにはテーブルの更新対象データが含まれるブロックに空き領域がなくてはならないのですが、テーブルのFILLFACTOR(充填率)はデフォルトで100(%)となっているため、このままでは充分な空き領域が確保できない事が多いと思われます。必要に応じて、更新頻度の高いテーブルにはFILLFACTORの値を設定する必要があるかもしれません。
MySQLでもvacuum必要 (スコア:3, 参考になる)
MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。
そういうときは、OPTIMIZE TABLEを行うことになりますが、これはたんにテーブルを作り直しているだけです。:)
そのうちauto vacuum的な物が入るのかもしれません。
Re:MySQLでもvacuum必要 (スコア:3, 参考になる)
# Delphi + SQLite の組み合わせが好きなので AC
Re:MySQLでもvacuum必要 (スコア:2, 参考になる)
(自分にとって)身近なところだと、Mac OS XのMail.appがSQLite使ってるようなので、vacuumしてやるとパフォーマンスがあがるようです。
参考 [nitenichiryu.org]
--S0R5
Re: (スコア:0)
テーブルを作成しなおしてexpしたデータをimpしなおす事もやってたし
24h運用に致命的でなきゃvacuumもあってもいいかな。
#最近Oracle使う仕事は他人に振ったので最近の事情は知らない
Re:MySQLでもvacuum必要 (スコア:4, 参考になる)
PostgreSQL はマルチバージョニング(トランザクション開始時点の状態のデータにアクセスするための機構)を
実現するために
「内部では更新の度に新規レコードを作っている」
のです。そしてこれを解放する必要が生じするのです。(約2億レコードに達する前に?)
ですから、
「Vacuum に相当する機構を行わないOracle」というものは
「ロールバックセグメントがいつまでも膨れ続けるOracle」
と考えればいいのではないでしょうか?
MySQL のことはわかりません。
# 勘違いだったらやなので AC
マクロの基本は検索置換(by y.mikome)
Re:MySQLでもvacuum必要 (スコア:2, すばらしい洞察)
ID持ちのAC悪用って常用になりつつありますね
Re:MySQLでもvacuum必要 (スコア:1)
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
# 俺もな~
Re:MySQLでもvacuum必要 (スコア:1)
エクステンション書き出し前の一時領域だし
vacuumの不要領域との比較はあんまり意味無いかも。
Oracleは不要領域を再利用してもデータ領域の断片化に対して
今のところは上手くアプローチ出来ているんじゃない?って思う。
逆にvacuumで何とかしようってアプローチが限界が来ているんじゃないかな?
Re:MySQLでもvacuum必要 (スコア:5, 参考になる)
ロールバックセグメントは、不要領域を集中管理することによってテーブル上の不要領域を意識する必要がなくなると言う反面、ロールバック時や、古いバージョンの検索のためには非常に面倒なロジックが必要になります。一方で、すべてのバージョンを平等に取り扱うPostgreSQLはシンプルで済みますが、ガベージコレクションであるvacuumが面倒になります。
PostgreSQLの不要領域管理は基本的にシンプルで、今回のHOTのような特定の頻発するケースに対する最適化は初めてじゃないでしょうかね。ようやく最適化に目が向いてきたと言うことで、例えばロールバックセグメント方式採用といった大変更の前に、まずは小さな改善を積み重ねる価値があるんじゃないかと思います。
Re:MySQLでもvacuum必要 (スコア:1, すばらしい洞察)
確かにOracleはその辺はPostgreSQLより賢いかもしれんけど、
最高水位標(HighWaterMark)の問題があるのだから、全くないわけではない。
PostgreSQLのそれは他のDBMSと比べて使用する頻度が多くなるように思うので嫌われているように思うが、その手の処理がないDBMSってあるのか。
あったとしても他の何かを犠牲にしているだけに思うのだが。
それは使用目的が異なるDBMSだと思う。
MySQLのMyISAMだってSQLServerだって可変長項目の断片化に対するので対処するコマンドがある。これだって不要領域の開放。
SQLServerはデフォルトでクラスタインデックス化されてたりするので割と性能に反映される。
# 別のコメントでMySQLはInnoDBでとあるけどMyISAMも同様だと思うのだが。
# ひょっとして5.xとかだと本当に不要になっている?
Re: (スコア:0)
>「Vacuum に相当する機構を行わないOracle」というものは
>「ロールバックセグメントがいつまでも膨れ続けるOracle」
>と考えればいいのではないでしょうか?
想像しただけでゾッとする・・・。
「内部では更新の度に新規レコードを作っている」の仕様を決めたのは誰だよ。
Re:MySQLでもvacuum必要 (スコア:1)
「誰だよ」とか言うほどのものかな?
その上で、デメリットを縮小する努力を継続してしているわけで。
Re:MySQLでもvacuum必要 (スコア:2, 参考になる)
MVCCのような追記型により読み/書きのロック競合をなくすというのはTime Domain Processingと呼ばれます。単純上書き型が採用するロックテーブルの管理方式とは大きく異なる革新的なもので、Gray本ではPostgreSQLの前身であるPOSTGRESはこれを意識して実装された、と紹介されています。
元々のポイントは、おそらくロールバックを単純化するためなのではないかと思います。ロールバックセグメントや上書き方式だと、undoログから更新してしまった領域を書き戻すというかなり面倒な一手間がかかります。
個人的にはこの種の専門的で複雑なロジックから解放されていたことが、PostgreSQLが当初オープンソースで細々と開発を続けることが出来た理由の一つかもしれないな、と思っています。いきなり現状のOracleのような高度なソフトウェアをオープンソースで公開して放り投げられても、おそらく誰もメンテナンスできないでしょうから:)
Re: (スコア:0)
Re: (スコア:0)
#DB2はメインフレームのおまけなのでAC
Re: (スコア:0)
空間の仕様効率が50%を割ることはありませんし、処理速度も一定以下に落ちることはないですよ。
処理速度が異常に遅くなると感じているとしたら、
1) インデックスがメモリに載りきっていない -> メモリを増やしましょう
2) 大きな BLOB を使い過ぎ -> BLOB は別ファイルで持ちましょう
といった、設計の問題だと思います。
他にもうれしい部分 (スコア:3, 参考になる)
まぁ、今回は8.1→8.2以上に変更点が多いとどこぞで聞いた記憶もあるので、移行には十分なテストが必要でしょうけど。
# 追跡していたのにリリースに気づいてなく、タレコミに先を越されたので悔しいからID
Re:他にもうれしい部分 (スコア:1, 興味深い)
元々SQLのNULLは、データ無しとか未入力とかいう意味じゃなく、
データが有るか無いかすら「不明」って意味だ。
(だから大抵の式(関数や演算子)にNULLを1つでも食わすと式全体の値がNULLになる。
不明を1つでも食わせりゃ全体が不明に汚染されるってことだ。)
一方「不明」なんてな状態を許す必要が有るカラムは
現実的にはそう多いわけでもない。
実際に欲しいのは「不明」ではなく「なし」や「未入力」のほうだということが多い。
(そういう意味では、NULLのときindexが効かないという制限をRDBが持つのはそれなりに合理的)
なのにSQLには「なし」「未入力」を表す合理的な道具が無いのだな。
仕方ないからみんな、「NULL」「'hoge'」「9999」などなどで代用したりするわけで。
だから
>IS NULLを使ったときにindexを参照するようになった
本来これはズレた対応だ。
「なし」「未入力」でindex参照が出来ればそれで(大抵は)十分だ。
ただし「なし」「未入力」が無いもんだから、
仕方なく、代用品であるNULLにindexを許すという逃げが必要になるわけ。
#そんな歪んだ仕様のSQLが大嫌いなのでAC
#言語仕様としてのSQLはポカが多すぎる。
Re:他にもうれしい部分 (スコア:3, 興味深い)
元々も何も極初期のSQLにはnullなんてものはなかったはずだが。徹底的に正規化すれば「なし」に相当する値が必要になることはありません。存在しないデータは最初からDBに入れなければよいだけです。例えばユーザ表にIDとユーザ名と生年月日のカラムがあって、生年月日未入力がありえるなら、単にそれをユーザ名表とユーザ生年月日表に分ければよろしい。
そうしないで生年月日カラムにnullを入れるなら、それは単にパフォーマンスチューニングのために正規化をくずしているということなので、それなら効率化のためなら何でも遠慮なくできた方がいいでしょう。
Re: (スコア:0)
元ACじゃないですけど
つまりは、例えば ID:生年月日 で表作っといて、IDで検索して見つからなければ生年月日入力されてないという判断を下すってコトですかね。
生年月日入力が無いIDの一覧を得るって言う利用方法を考えなければおっしゃる通りなのでしょうね。
たぶん、分析とサービス特化とかの立場の違いなんですかね。
#個人的にはNULLがほしいAC
Re: (スコア:0)
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呼び出し回数もケチらなければ
なんとか(なんとでも)なるけど、
それじゃ人間も計算機も手間ですね。
Re: (スコア:0)
Re: (スコア:0)
使い勝手としてはイマイチかな位。
#スパッと検索条件指定できたほうが気持ちいいと思うだけのAC
Re: (スコア:0)
設計者の美意識にユーザビリティが引きずられると後がきつい・・・。
Re: (スコア:0)
>元々も何も極初期のSQLにはnullなんてものはなかったはずだが。
>徹底的に正規化すれば「なし」に相当する値が必要になることはありません。
#私がいった「元々」はNULLの仕様についてであって、NULLの出自についてではありません。
それはそうとそれは興味深い話ですね。
SQLにとっての極初期つまり数十年も前においては、(マシンが弱かったため)今よりも遥かに追いにくかったであろう理想を、プログラマに要求する言語仕様だったわけですか。
えらくバランスの悪い言語だったんですね。
さて。
パフォーマンスのことは(特に現代では)置いといてもいい、としましょう。
でも、確
Re: (スコア:0)
ちょっと意外ですが (スコア:2, 参考になる)
今まで無かった? ちょっとびっくり。
oracleで云うところの,FOR UPDATEでOpenして,fetch loop内側で
CURRENT OF...でUPDATEって事が出来る様になったって事かしらん。
って,調べてみたら,英語のリリースノートにそのまま載ってました・・・。
http://developer.postgresql.org/pgdocs/postgres/release-8-3.html
E.1.3.6. Queries
こいつは,プログラマにとっては嬉しい機能ではないでしょうか。
Re: (スコア:0)
「典型的Webアプリプログラマ(特にそれしか知らない奴)にとっては」
何のことか判らないかも。
典型的Webアプリでは
SELECT FOR UPDATEのようにデータを捕まえておくってことは
避けるベキとされているようなので。
表示画面でのSELECT(のためのDBセッション)と
次の更新画面でのUPDATEとを
いかに「べつべつに切り離す」か?が重要である、
とされているようなので。
でも、
大量の顧客を右から左に捌く外向きサービスなら
確かにそれが真なんだけど、
べつに全てのWebアプリがそういうものとは限らなくて、
(「限れ」と強制する権利は多分誰にも無い)
掴んでいることのデメリ
Re: (スコア:0)
本当にそう思うか?
いつロールバックするつもりなんだ?
ステートレスセッションが基本であるはずのwebシステムにおいて、
状態を維持することが目的のトランザクションがなじまないのは、
少し考えればすぐわかるだろう。
そもそも、httpみたいな本質的にステーフルになじまない構造と、
コネクション維持が可能でステーフルに馴染むクラサバを同一視してるあたりが、
理解不足ではないだろうか?
Re: (スコア:0)
多くの(全てとは言わないが)の「Webアプリ」では、
HTTPのステートレスっぷりをむき出しのまま使ってるわけじゃなく、
ラッパーでステートフルに見せてますね。
それによって、上位層から見れば差は無いことになります。
(期間数十分…数日という)タイムアウトという概念が有る点が違うだけで。
(というか大抵の通信にゃ
遥か下位の層にステートレスな層が有るはず。
それをラップしてタイムアウトつきステートフル通信に見せてる。
その層の位置が高いか低いかの違いだけ。)
現実で具体的に何をしているかというと、
クラサバでは
なんに使うかな~ (スコア:0)
エクセルとかで十分な気がする^_^;
Re:なんに使うかな~ (スコア:1)
Excelも2007になると,100万行/1シートまでOKとの事なので,ますますExcelで十分なような...
Re:なんに使うかな~ (スコア:1)
#2007があまりに重過ぎるのにびっくりした。
Re:なんに使うかな~ (スコア:1)
物理的に扱えないというと zip ファイルの仕様的に無理という話ですか? 中のデータは単なる XML ファイルなので理論的にも物理的にも (リソースが十分にあれば) 普通に扱えるでしょう。
P3 1.2GHz/RAM 1GB なマシンで以下の操作をしてみました。
この程度なら、重すぎるという程重いかなぁ? という感じがします。
さすがにこれを元にグラフ描画とかであれば時間はかかるでしょうけど、この程度の速度が出ていれば一般的な用途では問題になる程の遅さは感じられないと思いますが。
# UI が重いって話であっても、これを試したマシンでも「まぁ普通じゃない?」という程度なのですが……。
Re:なんに使うかな~ (スコア:1)
#ネタなんだからね!
Re: (スコア:0)
「物理的に無理」ということになると色々影響が出るので、
リアルな実例をお願いしたいです。(HDDが一杯とかじゃなく)
事実が無いなら、コメントを撤回して下さいな。
Re: (スコア:0)
> 物理的に扱えないというと zip ファイルの仕様的に無理という話ですか?
この時点で間違ってますよ。
何で物理=zip仕様って解釈できるかなあ?
Re:なんに使うかな~ (スコア:1)
単に gzip の物理制約 (ヘッダの構造上 4GB までしか取り扱えない) を思い出しただけですよ。
メモリ的な物理制約や 32bit アプリとしてのハンドリング可能なメモリ量といった言うまでもない話をわざわざ取り上げる、なんて思えませんし。
Re: (スコア:0)
布団は圧縮できないってこと?
Re: (スコア:0)
Re: (スコア:0)
.......ぜったい無理だって^^;
vacuumの必要性自体が軽減され… (スコア:0)
結局vacuumeしなくてよくなるのはいつなのさ。
Re: (スコア:0)
8.3:(HOTのおかげでvacuumの負荷が減ったから)autovacuumをデフォルト有効に変更
OK?
Re: (スコア:0)
# それが望まれてるんだよね?
vacuum (スコア:0)
けむにまいてごまかす論理展開ではなく、問題にならないことを証明してみてください。 その運用がちゃんとできないような作りだから問題なんですよ。
Re:vacuum (スコア:4, すばらしい洞察)
タレコミ文には「その運用(=必要なときにvacuum)ができるなら」PostgreSQLは実用に足りる(場合が多い)でしょ? と書いてあるわけで、
「vacuumすれば問題はすべて解決!喝!」とは書いてないと思いますよ。
> その運用がちゃんとできないような作りだから問題なんですよ。
PostgreSQLの設計上の問題で「(とあるアプリケーションにおいて)必要なときにvacuumを行うことが出来ない(結果、表領域が肥大化してしまい業務的に許されない状況が起きてしまう)から問題」と仰っているのだと思いますが、だったら(そのアプリケーションには)PostgreSQLは使えないと判断されたわけですよね?
そのアプリケーションに利用するには、今までのPostgreSQLでは力不足だったということですから、当然、別の(vacuumの要らない)DBMSをお使いになっているわけで、それはそれで何の問題も無いのではないでしょうか。
で、今度のバージョンでは、そのvacuum(というか表領域の扱い)関連の改善がされているようですね。
ということは、上のようにvacuumが問題になってPostgreSQLを使えなかったアプリケーションでも、今後はPostgreSQLを使える可能性があるかもしれないということです。
問題になるかならないか、再評価を行ってみるのもいいかもしれませんね(少なくとも新規の案件では選択肢に入ってくるでしょう)。
Re: (スコア:0)
って程度