アカウント名:
パスワード:
他のDBを推している人からすれば「vacuumなんて作業が必要になること自体に問題がある」と言われそうですが、
MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。 そういうときは、OPTIMIZE TABLEを行うことになりますが、これはたんにテーブルを作り直しているだけです。:)
そのうちauto vacuum的な物が入るのかもしれません。
ロールバックセグメントは、不要領域を集中管理することによってテーブル上の不要領域を意識する必要がなくなると言う反面、ロールバック時や、古いバージョンの検索のためには非常に面倒なロジックが必要になります。一方で、すべてのバージョンを平等に取り扱うPostgreSQLはシンプルで済みますが、ガベージコレクションであるvacuumが面倒になります。
PostgreSQLの不要領域管理は基本的にシンプルで、今回のHOTのような特定の頻発するケースに対する最適化は初めてじゃないでしょうかね。ようやく最適化に目が向いてきたと言うことで、例えばロールバックセグメント方式採用といった大変更の前に、まずは小さな改善を積み重ねる価値があるんじゃないかと思います。
vacuumというデメリットを抱えても、MVCCというメリットがそれを上回る価値がある、と考えたからでしょ。
MVCCのような追記型により読み/書きのロック競合をなくすというのはTime Domain Processingと呼ばれます。単純上書き型が採用するロックテーブルの管理方式とは大きく異なる革新的なもので、Gray本ではPostgreSQLの前身であるPOSTGRESはこれを意識して実装された、と紹介されています。
元々のポイントは、おそらくロールバックを単純化するためなのではないかと思います。ロールバックセグメントや上書き方式だと、undoログから更新してしまった領域を書き戻すというかなり面倒な一手間がかかります。
個人的にはこの種の専門的で複雑なロジックから解放されていたことが、PostgreSQLが当初オープンソースで細々と開発を続けることが出来た理由の一つかもしれないな、と思っています。いきなり現状のOracleのような高度なソフトウェアをオープンソースで公開して放り投げられても、おそらく誰もメンテナンスできないでしょうから:)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
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 は別ファイルで持ちましょう
といった、設計の問題だと思います。