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

[Hidekazu Ikeda]

池田です。

>>でもMySQLやOracleでも、ディスクが許す限りの大きなロールバックセグメントを
>>とっておけば、あまり大きな違いはないような気もします。
> 
> そうですね。しかし、前もって大量の領域を用意しなければならないのであれば、
> PostgreSQLのVACUUMが必要なアーキテクチャと似たり寄ったりじゃないでしょう
> か。

　以下のどちらが多いか？　ですねぇ。

　実際の業務システムにおいて、DBMS の要求として
  1. 大容量の更新（commit せずにです）で、並列での更新
  2. 少容量（更新量が少ない）で、多数の並列での更新

のどちらが多いのかなぁ？って事じゃないでしょうかね。

Oracle は、２の方が業務システムでは多いと考えているから、
あのような実装だと考えてますが。。
個人的には、１項なら、単純にファイルのほうが良いようにも
思うのですが、、DBMS に向いてないシステムのような。

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

　２項が多いのであれば、VACUUM の方が欠点なのは言える、
とも考えますね。
　汎用機の TSS の時代から、ずっと、企業のシステム構築に
関わってきましたが、経験則として２項が多いとの認識です。

# ８０年代後半に RDBMS で業務システム組んだ事例において
# は大量更新の速度が出ずに、一旦、外部ファイルに落として
# 大量更新して、差分を戻すなんて、変な対処までしてた記憶
# があります。

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

　Oracle は Dirty Read は実装していない、ですし今後も
しないと思います。なので、分離レベルを実装する事が重要
とも一概に言えないと思います :-)

# 足が無いと完成品と思われないジオングのようだ。

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

　むかーしの Informix のように、製品系列が別れてたり
する方が良いかもしれません。

　重い代償にフル機能実装なのと、、軽量化して割り切り
な実装なのと。。

# 昔の SQL Anywhere とかの方向性です

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

　人に拠って、もしくは、状況に拠って、エンタープライズ
の言葉の定義は変わるようです。

  1. 企業の基幹システムと言う意味
     Excel マクロだろうが、Access だろうが、それが無いと
     困るのであれば、広義には、エンタープライズ用途かと。

  2. 大規模システムと言う意味
     並列な大量ユーザ、大量データ、大量トランザクションで
     使われるって意味で、言われる場合が多いです。

１項と２項の意味が、混ざって議論すると、果てしなく無意味
な時間を堪能できます（苦笑）。


ではでは。

-- 
--------------------------------------------------
 Hidekazu Ikeda 　池田　秀一
    E-mail:ikeda ＠ miraclelinux.com
    TEL 03-5562-8300   FAX 03-5562-8306
    http://www.miraclelinux.com/
--------------------------------------------------