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

[EBIHARA Yuichiro]

海老原です。

--- TANIDA Yutaka <tanida ＠ sra.co.jp> からのメッセージ：
> 
> メディアリカバリというのは、いわゆるアーカイブログ相当の機能でしょう
> か？

はい、そうです。

> 正直言って、PITRについて学べば学ぶほど、「金に糸目はつけないから、とに
> かくデータを救え」的な技術であると思うようになってきました。これは確か
> に重要な機能ではありますが、正直言って、PostgreSQLやMySQLを手軽に使い
> たいような人に、ここまでの機能の必要はあるんだろうかといつも思ってしま
> います。
> 必要としている人がいるのも確かなのですが。

これは確かにそうですね。
でも結局のところどういう場面にPostgreSQLやMySQLを適用したいかによるので、
必要としている人もいればそうでない人もいるとしか言えないと思います。

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

> これは個人的な見解ですが、ことPostgreSQL vs InnoDBの比較で、PostgreSQL
> が圧倒的に優れていると思うのは、デフォルトのpg_dumpがホットバックアッ
> プに対応している（InnoDBのは有償）ということだと思います。

これは多分誤解だと思いますが、詳細は僕より詳しい人に任せたいと思います。

僕が思うPostgreSQLがMySQL(InnoDB)に対して優れている点は、こんなところです
。

・標準SQLへの準拠度が高い
・ストアドプロシージャ、トリガー
・日本語、Unicodeを含むI18N系

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

某がOracleだとして、これはロールバックできなくなるのではなく、他トランザ
クションがコミットした更新の更新前イメージが見えなくなることがある、とい
うことです。
MySQLの場合は・・・ごめんなさい、よく知りません。

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

> いずれにしても、PostgreSQLは他のDBに比べトランザクションをまじめに考え
> 続けているなぁ、という気はします。もちろん、これだって必要のない人は多
> いのですが、そういう人はPostgreSQLを使うべきではない、という明確な線引
> きである、といえると思います。

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

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

僕の仕事は、ある程度の信頼性や性能が求められる業務系システムにOSS RDBMSを
適用できるのかどうか、製品によって適用範囲は異なるのかなどを調査したりす
ることです。
ということで、今回はなかなか面白い意見交換ができてうれしかったです。
今後ともよろしくお願いします。

--
海老原 雄一郎