パスワードを忘れた？ アカウント作成
Close
5304 story

MySQL v4.x系の安定版が遂に登場 43

ストーリー by Oliver
DBトピックのアイコン募集中 部門より

dseg 曰く、 "MySQL ABは18日、バージョン4系列では初の安定版となる、v4.0.12をリリースした。 変更点一覧はこちら。
今バージョンではInnoDBが標準バイナリに含められた。InnoDBのテーブル形式を使えばトランザクション・外部キーがサポートされるので、MySQLに対する「速度優先で、RDMBSの機能を幾つか割愛している」という形容詞は多少不適切になった...という事で良いのだろうか? (タレコミ子にはDB系の素養がないので、ぜひツッコミをお願いします)
ところで現状としては、v4.x系はどれくらいの方に使われているのだろう? 乗り換え時期の判断基準・判断方法も是非聞かせて頂きたい。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

MySQL v4.x系の安定版が遂に登場 More

  • 全文検索 (スコア:2, 参考になる)

    by Rockman (2923) on 2003年03月21日 10時28分 (#283569)
    Version 3.23.23 からですが，text型フィールドにおける全文検索が
    実装されているようで面白いと思いました。
    http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.ht... [mysql.com]
    ただし日本語は通らないでしょうけど。

  • MySQLの導入を検討してるんだけど (スコア:2, 興味深い)

    by Anonymous Coward on 2003年03月21日 11時43分 (#283591)
    トランザクションもできるようになった、外部キーもできるようになった。両方の機能をPostgreSQLで使ってるものとしてはMySQLを使わない理由が無くなったわけで・・・え？　view はまだ無いですか(^^;　ちょっと苦しいなぁ。　え？ストアドプロシージャもダメですか。　うーん、それもちょっと・・・(^^;

    そのようなわけで代替手段を探しつつもMySQLの「高速」という利点をどう生かせられるかどうかは案件の内容にも色々関わってくるわけで、とりあえずはあまり複雑な事を要求される場合はまだPostgreSQLの方が妥当かもしれないです、こっちも高速化のノウハウはあるわけだし。

    とかそんな話しをしてるとこのような話しを聞かされました。「MySQLはとてつもなく高速だけど、途中でupdateやdeleteとかが入るとものすごくパフォーマンスが落ちる。　単純にinsertしただけのデータを検索するなら恐ろしく早いんだけど・・・あ、もちろんマシンの方は十分なメモリを積んでて性能もものすごく良いものを使っている」との事でした、そのマシンの正確なスペックは聞いてなかったので、その辺はまぁ考えないとして、実際にMySQLを使ってる方にその辺はどうなのかちょっとお伺いしたいです。

    • Re:MySQLの導入を検討してるんだけど (スコア:2, 参考になる)

      by Anonymous Coward on 2003年03月21日 14時01分 (#283646)
      “MySQL”でひとくくりにして語ると間違うかも知れません。
      簡単に言うと、MySQLは

      ・参照激速、更新遅くトランザクション何ソレのMyISAM（従来のMySQL）
      ・トランザクション対応だけど参照速度いまいちInnoDB

      の２つのデータベースがゴッチャに構成されてるものと
      理解してます。（他の形式もあるけど普通使わないよね？）
      用途よってテーブル単位での使い分けは可能なのですが、
      運用管理がめんどくさいのであんまりやりたくありません。。

      個人的にはサブクエリーが使えないのがつらいです。
      4.1で対応とはなっていますが……安定版はいつになるやら。
      シェア
      親コメント
    • そういう用途に無理にMySQLを適用しようとすると「あれがないこれがない」って
      ことになってお互い幸せになれません．
      そんな時はFireBirdにしたら？って思うよ．少なくともPostgreSQLよりは速いし
      HDD容量はMySQL(InnoDB)の1/3程度です．PostgreSQL比は分からない．．．すまん
    • InnoDB遅いって言ってるけど、むしろInnoDBの方が速いような気が.. http://www.innodb.com/bench.html

  • 学習環境としても重宝してます (スコア:2, 参考になる)

    by duster (12761) on 2003年03月22日 0時27分 (#283916) 日記
    MySQLはWindowsバイナリが前からあったので重宝してますよ。

    Windows環境でもApache＋Tomcat＋MySQLで、JavaでDBを取り扱うサンプルを後輩に勉強させるのに、重宝してます;-)

  • これで、さらに・・・ (スコア:1, 興味深い)

    by terasawawawa (6534) on 2003年03月21日 10時33分 (#283572) 日記
    トランザクション対応がハッキリと打ち出されるようになっちゃうと
    ORACLEの置き換えにMySQLなんていうトンデモ提案が増える予感・・・

    経営者的に見れば、びっくりする程コストが下がるし、それが真実だとしたら・・・
    と思って、イチイチ技術者に提案内容の吟味とかさせちゃいますよねぇ

    マジで高負荷状況でトランがガシガシ発生するECサイト(バックエンドORACLE)をMySQL置き換え提案を持ってきたベンダーがありました・・・

    参照系のみ一部置き換えとかなら全然OKだと思いますけどね

    • Re:これで、さらに・・・ (スコア:1, 興味深い)

      by kenji (81) on 2003年03月21日 11時44分 (#283592)
      であなたは、MySQL の性能を検証したんでしょうか? Oracle を MySQL で置き換えできないと思う理由は なんなんでしょう?
      シェア
      親コメント

      • Re:これで、さらに・・・ (スコア:2, 興味深い)

        by terasawawawa (6534) on 2003年03月21日 12時28分 (#283612) 日記
        たしかにおっしゃる通りかもです。
        （皮肉でないです。念のため）
        ただ、その時のORACLEは、4CPUのSUNをHA構成にしてファイバーチャネルで共有ディスク云々
        ってな感じで構成されていたんで

        それと同等環境ではたしてMySQLで高負荷トランザクションに耐えられるか？
        とかっていう検証は、予算的、時間的、にもできなかったです。

        なんていう情報を書いたほうが良かったですね。

        その辺の実績みたいなのがベンダーだけでなく、実際にSEレベルの人達からも語られるような状況まできてたら
        「じゃ、チャレンジしますか」
        と思ったかもです・・・。

        決してMySQLがORACLEの置き換えにならない事は無いと思います。
        シェア
        親コメント
  • >DBトピックのアイコン募集中 部門より．

    ディスク(ドラム)と四角いテーブル(表)の組合せとか...
    • とりあえず「黄色い鍵」はやめよう。

      今時97使いな私です。
      シェア
      親コメント

    • 四角だけかぁー (スコア:1)

      by G7 (3009) on 2003年03月22日 15時44分 (#284169)
      >四角いテーブル(表)

      それは表形式つーかRelational方式のDBしかサポートしないという神の意志でしょうか？(T_T)

      #OODBの泣かず飛ばずが悲しいのでG7。言語とかはこれだけOOP化されてるのに、なんで誰もがOOと相性最悪のRDBとを接続して事を済まそうとするかなあ？
      #まぢ、関連だらけのObjectを保存する(しかも多人数同時使用を想定して、一部のObjectだけCommitできるようにする)ことを考えると、OO-RDBマッピングって本質的に痛いんですけどぉ。
      シェア
      親コメント
      • >>四角いテーブル(表)
        >
        >それは表形式つーかRelational方式のDBしかサポートしないという
        >神の意志でしょうか？(T_T)

        それを言っていたら,木構造とかネットワークとかカードとか
        キリがないような...

        DWHも考えると倉庫のほうがいいのかなあ～
        シェア
        親コメント
    • アナライザーの上半身なんてどうですかね。

      # DB とつながる気がしないが脊髄反射で思い浮かんだので
    • 太めの円柱でいいと思います。
    • ・ １コマ目
      　毎晩夜遅くまで情報の整理に悩む会社員Ａ、時計の針はAM3:00をさしている

      ・２コマ目
      　もうだめだ、頭を抱えて絶叫する会社員Ａ、時計の針はAM5:00をさしている、その時誰かの手が会社員Ａの肩にかけられる。

      ・３コマ目
      　どこから現れたのか先輩女性社員がニコっと微笑んでデータベースソフトのパッ

      • 3コマ目と4コマ目の間に何日経過しているんだろう.

        そりゃあ情報整理はあっと言う間かもしれないけど, DBへのデータ取り込みやインデックスの張り直しにどれだけ時間がかかるのやら. ロールバック用領域の容量が足りないと, 途中で溢れて最初からやりなおしなんてことにもなりかねないし.

        # 懺悔の時間: 5GBのexportファイルをimportしている途中でほったらかして帰りました. だって何時終わるか予想できなかったんだもん. DB実装設計を自分でやったわけじゃないし.

        シェア
        親コメント
      • マヂレスしとくと、
        なんぼDBなどのツールを導入してくれても、その中でどう自分らが保持させたいデータを表現するか？を決めるのは
        やっぱり人間の仕事っすね。

        少なくとも、スキーマが決定され、そこに既存の(非DBな！)データを流し込み、
        それなりにアプリを作ったりして人間に使いやすくして、ユーザーの皆も使い方を覚えて、
        という、いわゆる「運用」が行われるようになれば、仕事はすっきり楽になるのかも知れませんが、
        それは多分、今日明日のことじゃないですよね。

        ところで。データベース(をいじるソフト)を直接いじるのが一部の担当者だけに限られるという運用だと、効果は出にくいよね。
        人間というボトルネックを如何に回避できるか、が結構重要。
        人数を出来るだけ限定しないようにすることで、細いボトルの首も束ねて太くできる。
        シェア
        親コメント
      • そういうのはまた2chにDB板ができたらな。

  • BDBが捨てられた理由 (スコア:1)

    by YamaKenZ (12605) on 2003年03月21日 14時32分 (#283664)
    最初にトランザクションが実装された時にはBerkeley DB [sleepycat.com]を使ったBDBテーブルが使われてたと思いますが、これがInnoDBに置き換わった理由は何なんでしょう。

    技術的な問題? それともライセンス上の不都合や政治的な理由?

  • 4.0 (スコア:0)

    by Anonymous Coward on 2003年03月21日 13時46分 (#283636)
    3.23の頃だと、UNIONテーブルを参照するクエリーを連続で投げ続けると、mysqldが無反応になってshutdownもできなくなることがよくあったんで、試験的に4.0系を使っています。
    4.0以降でもたまにUNIONでこけることがあるけど、3.23の頃よりも頻度は低いので我慢しています。
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー