[pgsql-jp: 33134] Re: PostgreSQL カンファレンスお礼および MySQL のデータが壊れる件

[TANIDA Yutaka]

谷田です。

On Mon, 7 Jun 2004 15:36:59 +0900 (JST)
EBIHARA Yuichiro <uiebi ＠ yahoo.co.jp> wrote:

> ただしMySQLに関しては供給者サイド(MySQL AB社)から、エンタープライズも行け
> まっせ! という強いメッセージが発信されているのは確かです。

メッセージについては、実際PostgreSQLが一番弱点としているところでしょうね。
まあ、明確な宣伝組織の必要ないコミュニティベースの開発では仕方がないとこ
ろかもしれません。

> > 他にも、InnoDBはロールバックセグメント式のMVCCを実装しているようです
> > が、これは某と同じくやはりセグメントを使い果たしてしまうとロールバック
> > できなくなるのでしょうか？もしそうだとすると（違っていたらごめんなさ
> > い）ディスクがある限りトランザクション機構を維持できるというのは、
> > PostgreSQLの定期的なvacuumが必要だという欠点を補ってあまりある利点だと
> > 思いますね。
> 
> 某がOracleだとして、これはロールバックできなくなるのではなく、他トランザ
> クションがコミットした更新の更新前イメージが見えなくなることがある、とい
> うことです。

まあ、私は某がOracleとは一言も言っていませんが:-)その挙動も大変な問題に
なりませんか？

ところで、今のOracleはロールバックセグメントを使い果たしても（一つのトラ
ンザクションでロールバックセグメントの容量を超えてしまうような大量の更新
をしても）正しいロールバックが可能なんですか？

> でもMySQLやOracleでも、ディスクが許す限りの大きなロールバックセグメントを
> とっておけば、あまり大きな違いはないような気もします。

そうですね。しかし、前もって大量の領域を用意しなければならないのであれば、
PostgreSQLのVACUUMが必要なアーキテクチャと似たり寄ったりじゃないでしょう
か。

＃それをまた「うちのはVACUUMがいらないからすごい」と欠点を隠して言う人が
＃いるから話がややこしくなる。

今となってはVadimがOverwtire Storage Managerを実装しなくて良かったかもな、
と思います。

> 何を以ってまじめというかにもよりますが、例えばMySQLのInnoDBでは、Dirty Read
> からSerializableまでの4つのトランザクション分離レベルを備えています。
> これはこれでまじめに考えていると言えると思います。

なるほど、これはPostgreSQLでサポートできていない部分ですね。

しかし個人的に言うと、分離レベルというのは、どうも既存のDBが完全なサポー
トをするとものすごく遅くなってしまったので、パフォーマンスのための救済策
であるように理解しているので、とにかく実装する、というスタンスにあまり前
向きにはなれないですね。

> 最後に、谷田さんからのもう一通のメール(33121)に対する返答にもなるのですが
> 、僕の中ではPostgreSQLを適用可能な範囲というのがまだ明確になっていないの
> です。
> ある人はPostgreSQLはエンタープライズ用途に耐えられると言うし、逆のことを
> 言う人もいるし。

何を持ってエンタープライズ用途と呼ぶか、でしょう。たとえばsf.netは
PostgreSQLで動いているらしい（資料が見つかりませんが）ですが、あれはエン
タープライズでしょうか、そうでないのでしょうか？


-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>