スレッドメモ

MLやNewsのスレッドをメモする試み。

2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|

2004-06-07 (月)

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

[33107] Ryuichiro Munechika (6/7)

さて、石井さんのお話の中にもあった「MySQLのデータがよく壊れる」 件について、以前もどこかで話を聞いたかもしれないのですが、本件に 関して出展をご存知無いでしょうか?

http://jp.xoops.org/modules/newbb/viewtopic.php?topic_id=3565&forum=11 あたりで問題になっていたようなことかと記憶しているのですが。

[33109] Tatsuo Ishii (6/7)

日経システム構築の2004年4月号の150ページあたりにある

  1. XOOPSでシステムを構築したが,DBMSがMySQLだったためかデータが壊れた.担当者曰く「MySQLのデータは壊れやすいということを改めて思い知らされた」(p150)

というのを見ました.

まあ,MySQLにデータの信頼性を期待してはいけません:-)

[33111] SUGIMURA Takashi 杉村 貴士 (6/7)

某携帯電話のメールシステムにて MySQL の InnoDB で 超大規模な分散 DB を構築したことがあるんですが、 単純に壊れやすいということはないように思います。

PostgreSQL や Oracle でも壊れるような運用をすれば壊れますし、 DB の種類だけで論じるのは危険だと思います。

[33112] Hidekazu Ikeda (6/7)

 うーん、「だったためか」と言うのが「FACT:事実」と言う には弱いような。。

 むか〜しの Access MDB とかだと、あるパターンで再現して たので、壊れやすいと言えたのですが、この情報だけでは良く 判らないですよね。

 Mysql-jp も読んでますが、「壊れやすい」と言う感覚には 私はならないのですが。。。

 英文でも良いので、「壊れやすい」「信頼性が期待できない」 の情報源が欲しいですね。

[33114] EBIHARA Yuichiro (6/7)

スペック的にはむしろMySQL(InnoDB)のほうが信頼性が高いと評価できそうなもん ですけどね。 メディアリカバリの分だけ。

エンタープライズ用途を考えるときには、PostgreSQLとMySQLの比較はInnoDBを前 提に語るべきだと思います。MyISAMはシステム要件によっては一考の価値ありの 便利なオプション、くらいの位置づけで。

僕自身もほんの数ヶ月前までMySQLなんて相手にならない、と思っていたものの、 実際に詳細を調べてみたら古い情報で大きな誤解をしていたことに気づき、今は 考えを改めています。

[33128] Tatsuo Ishii (6/7)

以下感覚論.

私がMySQLの信頼性に不信感を持っている一番の理由は,MySQLの開発者らが, 「トランザクションなんか要らない」とか「ロックの管理はユーザが自分でや る」とかDBMSの根幹を否定することを言っていたからなんです.つまり,彼ら にとって,DBMSが自律的にデータを守る,という考えがそもそもないのではな いんではないか,ということです.そうすると,最近になって急にトランザク ションとかACIDとか言い出したのはなぜかというのが謎なんですけどね:-)

他にもいい加減な根拠でPostgreSQLバッシングを盛大にやっていたとか, MySQLというよりは,MySQL ABには私は良い印象を持っていません.

[33134] TANIDA Yutaka (6/7)

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

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

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

[33145] Hidekazu Ikeda (6/7)

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

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

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

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


2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|