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

サイボウズが独自データベースを捨てMySQLに 53

ストーリー by yoosee
目的のために手段を選ぶ 部門より

mpd曰く、"ITmediaの記事によると、 サイボウズがMySQL ABとライセンス契約を締結し、今後発売される自社製品にMySQLを搭載することを発表した。サイボウズはこれまで独自のデータベース「Cyde」を用いていたのだが、何があったのだろうか。 興味深い決断である。"

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

サイボウズが独自データベースを捨てMySQLに More

  • 当然の決断 (スコア:5, 参考になる)

    by Anonymous Coward on 2005年04月27日 13時01分 (#728389)
    > これまで独自のデータベース「Cyde」を用いていたのだが、何があったのだろうか。
    > 興味深い決断である。

    独自製品から、オープンスタンダードに移行するのは当然の話で、 別に不思議な話じゃないですよ。
    独自製品はメンテナンスに非常にコストがかかるし、ソフトウェアはかなりのデフレ傾向にあるので、よほど数をさばける製品でないと、開発に投資した分を回収することができないです。
    一般に独自に製品を開発し、それを使い続けるには以下のようなコスト・リスクがあります。
    • APIなどが独自なので、独自SDKを使う必要があり、開発者の育成・引継ぎにコストがかかる。（場合によってはSDKがぼろぼろで罠だらけ、ドキュメントが貧弱でソースを追わないと分からない、と言ったことも）
    • 仕様が独自であるため、ユーザーマニュアルに使い方を隅から隅まで記述する必要がある（CyDEの場合、例えばバックアップ・リストアや再構築の手順、トリガを使ったカスタマイズ、ネットワーク越しのレプリケーションなど)
    • メンテナンスやサポートできる技術者を自社で育成する必要がある。簡単にアウトソースできない。
    • 最新技術への追従は全て自社（の資金）で行う必要がある。
    • サードパーティによるサポートの可能性が低い。サードパーティ製の便利ツールが使えない、サードパーティ向けのSDKを出しても作ってくれない、サードパーティの拡大には販促が必要
    などなど。

    • Re:当然の決断 (スコア:3, おもしろおかしい)

      by Anonymous Coward on 2005年04月27日 13時35分 (#728402)
      Cydeの担当者が退社しただけかもよ(笑)。
      シェア
      親コメント

    • Re:当然の決断 (スコア:2, 参考になる)

      by tyuu (9154) on 2005年04月27日 13時34分 (#728400) ホームページ 日記
      当然かな？
      リストアップしていただいたコスト・リスクは、
      付加価値と表裏一体だったハズです。

      MySQL の選択によって phpmyadmin 等から、
      簡単にデータ構造へアクセスが可能になります。

      データ構造が理解できれば、
      最適なコードを生成するのは、容易いと思います。
      # つまりパチもんの登場

      MySQL 選択には苦悩があったと思うのですが、
      Cybozu がどのように乗り越えたのか ...。

      興味あります。
      シェア
      親コメント

      • Re:当然の決断 (スコア:2, すばらしい洞察)

        by genzin (23225) on 2005年04月27日 14時46分 (#728430) 日記
        ＞付加価値と表裏一体だったハズです。

        サイボウズを使ってみた印象では、
        ・ＤＢをサービスとして起動しなくてよいので、CGI並に
        　インストール（導入）が簡単
        ・データベースのバックアップが、サイボウズのＵＩから
        　簡単に出来る

        などの、独自ＤＢならではの付加価値があったと思うので
        すが、ＭｙＳＱＬに変更しても大丈夫なんでしょうか。
        シェア
        親コメント

        • Re:当然の決断 (スコア:5, 参考になる)

          by Anonymous Coward on 2005年04月27日 16時50分 (#728474)
          とあるお客のサイトでサイボウズを入れています。
          ユーザ数が数百人という、サイボウズとしてはちょっと規模が大きすぎなのですが、Cydbはかなり難アリですね。

          まず、データベースのバックアップができると言っても、ファイル単位で丸ごと取っておく事ができるというだけなので、蓄積されたデータ量が増えてくると、バックアップに必要な容量がどんどんと増えて行きます。長期の利用を考えるなら、差分バックアップが欲しい所。
          MySQLであれば、スナップショットをフルバックアップとして取っておき、update-logを吐くようにしておけば、それが差分となりますので、フル＋差分という形でバックアップが取れます。

          次にデータベースファイル自体ですが、フラグメンテーションを防ぐためでしょうが、かなり大きな単位で増加して行きます。最初は512KB程度ですがデータ量が増えると増分も大きくなっているようです。
          それ自体は良いのですが、全システム共通のデータベースファイル以外に、各ユーザごとに一つずつのデータベースファイルを持っているため、ユーザ数が多いと、このデータベースファイルがすごい勢いで容量を増して行きます。
          ディスク容量自体は年々容量単価も下がっていますので、それ程問題が無いと言えば無いのですが、上で書いたようにファイル単位でのバックアップしかできませんので、バックアップに要する時間が飛躍的に増えて行きます。

          最後に致命的とも言える問題ですが、Cydbではデータベースのファイルが壊れていてもそれなりに動いてしまいます。
          そのため、数世代のバックアップを取っていたとしても、それを越えた時点でやっと壊れているという事が露見してしまう事もあります。
          データベースファイルが壊れているかどうかを確認するための手段がユーザにはありませんので、実際動作が異常になるまでわかりません。
          サイボウズ社へ送れば調べてくれるらしいのですが、上記のようにデータ量が莫大になってくると、容易に送る事もできません。
          そして、仮に送ってみて壊れていると確認されたとしても、サイボウズ社ですら修復ができません。
          という事は、最古の世代のバックアップも壊れていた場合には、0から再スタートするしか手段がありません。
          もちろん、バックアップを上書きせずに永遠に残すようにすれば0よりはマシですが、それにしても何ヶ月も前の状態に戻ってしまう事態もあり得ます。

          独自データベースである事にはメリットがあるかもしれませんが、ダンプ、レストア、チェック、修復というデータベースとして最低限の機能も備えていないものでは、メリットも台無しだと思います。

          シェア
          親コメント

          • Re:当然の決断 (スコア:1, 参考になる)

            by Anonymous Coward on 2005年04月27日 21時03分 (#728540)
            >データベースファイルが壊れているかどうかを確認するための手段がユーザにはありませんので、実際動作が異常になるまでわかりません。
            >サイボウズ社へ送れば調べてくれるらしいのですが、上記のようにデータ量が莫大になってくると、容易に送る事もできません。
            >そして、仮に送ってみて壊れていると確認されたとしても、サイボウズ社ですら修復ができません。

            iOfficeの方は知らんが、ガルーンなら去年の夏バージョンあたりから確認・修復ツールが付属してたはず。
            使い物になるのかは知らんけどね。

            まあ、いずれにせよちゃちなのは確かなんでMySQLにするのは大歓迎。
            シェア
            親コメント

        • Re:当然の決断 (スコア:2, 参考になる)

          by ninestars (5792) on 2005年04月27日 16時27分 (#728467) 日記
          MySQL は任意のアプリケーションにエンジンを組み込んで利用できます。

          11.1.15.1. 組み込み MySQL サーバライブラリの概要           [mysql.com]

          別途サーバを立てない構成は十分に可能でしょう。
          サイボウズがどのような構成を考えているかは未確認ですが。
          シェア
          親コメント

          • Re:当然の決断 (スコア:1)

            by Yappo (5920) on 2005年04月27日 19時31分 (#728516) 日記
            組み込み MySQL サーバのライセンス [mysql.com]

            フリーソフトウェアを作成したら、GPL またはそれと互換性のあるライセンスの下でコードをリリースすることによってフリーソフトウェアを宣伝するようにしてください。それができない場合は、MySQL AB から MySQL コードの商業的ライセンスを購入するという選択肢があります。


            そこで、ライセンス締結ですか。
            シェア
            親コメント

          • Re:当然の決断 (スコア:1, 興味深い)

            by Anonymous Coward on 2005年04月28日 4時31分 (#728648)
            CybozuはCGIで動いていて、常駐プロセスがありません。
            なので、CydeをMySQLに置き換えることは、アーキテクチャの変更を伴うと思います。

            Cybozuはスクリプトのエンジンを自前で持っていたりと、
            OSの機能を極力使わず、移植性が高い点が面白かったですね。
            シェア
            親コメント

      • Re:当然の決断 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2005年04月27日 15時05分 (#728439)
        ＞MySQL 選択には苦悩があったと思うのですが、
        ＞Cybozu がどのように乗り越えたのか ...。

        これについて、顧客にいろいろ提案する身としてはそのうち情報が出てくるとありがたいですね。
        どこかＩＴ系メディア（ITmediaとかITProとか）が経緯を取材、記事にしてくれると非常に価値ある資料になりそう。
        シェア
        親コメント

      • Re:当然の決断 (スコア:0)

        by Anonymous Coward
        > データ構造が理解できれば、
        > 最適なコードを生成するのは、容易いと思います。
        > # つまりパチもんの登場

        データ構造の公開とパチもんの関連は薄いと思います。入力情報などから、データ構造くらいある程度想像つきますよね。
        それ以前に、オープンソースを探せば、大抵似たような機

    • Re:当然の決断 (スコア:1, 参考になる)

      by ef (25263) on 2005年04月27日 13時35分 (#728401)
      独自製品から、オープンスタンダードに移行するのは当然の話で、別に不思議な話じゃないですよ。
      独自製品はメンテナンスに非常にコストがかかるし、ソフトウェアはかなりのデフレ傾向にあるので、よほど数をさばける製品でないと、開発に投資した分を回収することができないです。
      基本的に同意見なのですが、なぜ社外の商用ＤＢでなく MySQL を選んだか？の方にも興味があります。
      シェア
      親コメント

      • Re:当然の決断 (スコア:2)

        by doripush (653) on 2005年04月27日 15時31分 (#728450)
        MySQLはれっきとした商用DBです。製品に組み込むかどうか
        は今後の発表を注目したいところですが、GPLでないライセンス
        で安価に使えて実績も十分にあるので、選択としては当然だと思われます。
        シェア
        親コメント

        • Re:当然の決断 (スコア:0)

          by Anonymous Coward
          PostgreSQL だと GPL(copyleft) でもないし、ライセンスフィーもいらない気がするのですが？
          あえて MySQL なのは有償サポートを期待したって事でしょうか？

          • Re:当然の決断 (スコア:0)

            by Anonymous Coward
            PostgreSQLは開発元が責任を持ってサポートするというものではないからでしょう。開発元のサポートを大事に考える 場合にはPostgreSQLは選択できません 。逆に、オープンで実力さえあれば開発に参加できる自由さに魅力を感じれば、MySQLは選択できません。どちらがよいとは言えない相容れないことです。

            • Re:当然の決断 (スコア:0)

              by Anonymous Coward
              PostgreSQLだと最悪時は自社でメンテする羽目になる。
              けいどMySQLであれば少なくとも契約期間であればメンテは保障される。
              ってのは大きいでしょう。

              有る意味、PostgreSQLでは自社独自のDBを捨てる意味が無いって事にも成りかねないのですから。

            • Re:当然の決断 (スコア:0)

              by Anonymous Coward
              |_・)つ[PowerGres Plus [fujitsu.com]]
              |_・)つ[PostgresForest [nttdata.co.jp]]

              • Re:当然の決断 (スコア:0)

                by Anonymous Coward
                富士通のはWINDOWS専用、
                NTTデータのは分散DBもどき。

                サイボウズの用途には向かない。

      • Re:当然の決断 (スコア:1)

        by ef (25263) on 2005年04月27日 16時39分 (#728471)
        なぜ社外の商用ＤＢでなく MySQL を選んだか？の方にも興味があります。
        商用ＤＢと言う表現は MySQL も(商用ライセンスもあるので)商用ＤＢに含まれると言う意味で適当でなかったようです。
        「数ある選択肢の中から MySQL を選んだ理由は何だったのだろう」
        位の意図でした。

        移植性ってのはありそうですね。

        シェア
        親コメント

      • Re:当然の決断 (スコア:0)

        by Anonymous Coward
        「商用DB」としてMySQL ABと契約したんだと思うがなぁ。
        MySQLは商用ライセンスもあるぞ。

        • Re:当然の決断 (スコア:1)

          by wanwan (45) on 2005年04月27日 14時27分 (#728420)
          単純にサイボウズというブランドが立ち上がって、マネされてもいいやっていうのもあるのやも。
          現状サイボウズを使っている会社が、他のサービスに乗り換えるとも思えないし、新規のユーザもブランドとして立ち上がっているサイボウズよりも、バチモンに手を出すこともないんじゃないでしょうかね。

          実際、うちの社内でもサイボウズを使っていますけど、使い始めると「まぁ、これはこれでいいやぁ～」って気分にさせられるし、今更Lotusとかに行く気もないです。

          実際、こういったサービスって、1回使い始めると、なかなか他のサービスに移行はしにくいと思う。
          シェア
          親コメント

          • Re:当然の決断 (スコア:0)

            by Anonymous Coward
            > 単純にサイボウズというブランドが立ち上がって、マネされてもいいやっていうのもあるのやも。

            別にサイボウズのサービスがオープンソースになったわけではなくて、単にバックエンドのDBを既存の別会社のDBにしただけでは?
            既にあるように、MySQLなら、自

    • Re:当然の決断 (スコア:1, 興味深い)

      by Anonymous Coward on 2005年04月27日 14時37分 (#728426)
      > サードパーティによるサポートの可能性が低い。サードパーティ製の便利ツールが使えない、サードパーティ向けのSDKを出しても作ってくれない、サードパーティの拡大には販促が必要

      RDBバックエンドにするのは、これが一番大きいかな。既存の営業分析系のツールでもRDB前提のも多いし。

      MySQLで最初に移植しておけば、移植性が高くなるのが理由の一つじゃないかと思う。マルチプラットフォーム展開でも、他RDBへの乗り換えでも。
      シェア
      親コメント

    • Re:当然の決断 (スコア:0)

      by Anonymous Coward
      技術的にどうこうだけではなく
      経営判断、営業判断等ありますから、
      実際のところはわかりませんよね。

  • PostgreSQLみたいに (スコア:2, すばらしい洞察)

    by kachou (4553) <kachou.dmNO@SPAMgmail.com> on 2005年04月27日 12時43分 (#728378) ホームページ 日記
    DBのバッファ関係のアルゴリズムにARC [srad.jp]を使ってたから…とか？
    --

    /* Kachou Utumi
    I'm Not Rich... */

  • 実はMaxDBだったりして (スコア:2)

    by trueOne (134) on 2005年04月27日 23時38分 (#728583)
    SAPで使ってるならウチも！って感じで。
    --
    trueOne

  • デヂエのデータの有効活用 (スコア:2, 興味深い)

    by Akiho (5343) on 2005年04月28日 1時31分 (#728625)
    デヂエで蓄積・メンテしているデータを、デヂエよりも使い勝手の
    良い見た目で検索・閲覧したいという要望が身近で結構あるので、
    デヂエのデータにDBアクセス並に手軽にアクセスできたらと
    常々思ってました。

    MySQL搭載で、それが可能になるかもしれませんね！
    今後に期待です。

  • おふとぴ (スコア:1, 興味深い)

    by Anonymous Coward on 2005年04月27日 12時30分 (#728371)
    一瞬、サイベースかと勘違いして焦った。

  • 参考にあまりならないかも知れないけど (スコア:1, 参考になる)

    by Anonymous Coward on 2005年04月27日 14時33分 (#728424)
    CyDE概要 [cybozu.co.jp]。

    ぐぐれば一発で出るけど一応。

  • 微妙... (スコア:1)

    by masayang (13412) on 2005年04月29日 8時08分 (#728987) ホームページ 日記
    カレンダやスケジュール管理共有機能、掲示板、Webメールなどなど。
    で、DBにMySQL使うのなら、オープンソースのGroupwareでもよいのでは？　と思った。
    --
    ---- 末は社長か懲戒免職 なかむらまさよし

  • 一応記事つけときます (スコア:1)

    by raccoon (16317) on 2005年05月12日 10時08分 (#733796)
    ITmedia [itmedia.co.jp]の。

  • 他は直るのかな (スコア:0)

    by Anonymous Coward on 2005年04月27日 17時44分 (#728492)
    DBを変更するとなると大幅な構成変更になると思うんだが、
    ログイン後のクッキーを偽装すると他人に成り済ませるって脆弱性は直るのかな？。

    結構致命的な大穴だと思うのでAC。

  • 捨てたのなら (スコア:0)

    by Anonymous Coward on 2005年04月27日 22時51分 (#728564)
    「CyDE」がオープンソースにならないですかね？

    #え？要らない？
typodupeerror

※ただしPHPを除く -- あるAdmin