アカウント名:
パスワード:
まず、データベースのバックアップができると言っても、ファイル単位で丸ごと取っておく事ができるというだけなので、蓄積されたデータ量が増えてくると、バックアップに必要な容量がどんどんと増えて行きます。長期の利用を考えるなら、差分バックアップが欲しい所。 MySQLであれば、スナップショットをフルバックアップとして取っておき、update-logを吐くようにしておけば、それが差分となりますので、フル＋差分という形でバックアップが取れます。
次にデータベースファイル自体ですが、フラグメンテーションを防ぐためでしょうが、かなり大きな単位で増加して行きます。最初は512KB程度ですがデータ量が増えると増分も大きくなっているようです。 それ自体は良いのですが、全システム共通のデータベースファイル以外に、各ユーザごとに一つずつのデータベースファイルを持っているため、ユーザ数が多いと、このデータベースファイルがすごい勢いで容量を増して行きます。 ディスク容量自体は年々容量単価も下がっていますので、それ程問題が無いと言えば無いのですが、上で書いたようにファイル単位でのバックアップしかできませんので、バックアップに要する時間が飛躍的に増えて行きます。
最後に致命的とも言える問題ですが、Cydbではデータベースのファイルが壊れていてもそれなりに動いてしまいます。 そのため、数世代のバックアップを取っていたとしても、それを越えた時点でやっと壊れているという事が露見してしまう事もあります。 データベースファイルが壊れているかどうかを確認するための手段がユーザにはありませんので、実際動作が異常になるまでわかりません。 サイボウズ社へ送れば調べてくれるらしいのですが、上記のようにデータ量が莫大になってくると、容易に送る事もできません。 そして、仮に送ってみて壊れていると確認されたとしても、サイボウズ社ですら修復ができません。 という事は、最古の世代のバックアップも壊れていた場合には、0から再スタートするしか手段がありません。 もちろん、バックアップを上書きせずに永遠に残すようにすれば0よりはマシですが、それにしても何ヶ月も前の状態に戻ってしまう事態もあり得ます。
独自データベースである事にはメリットがあるかもしれませんが、ダンプ、レストア、チェック、修復というデータベースとして最低限の機能も備えていないものでは、メリットも台無しだと思います。
フリーソフトウェアを作成したら、GPL またはそれと互換性のあるライセンスの下でコードをリリースすることによってフリーソフトウェアを宣伝するようにしてください。それができない場合は、MySQL AB から MySQL コードの商業的ライセンスを購入するという選択肢があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
当然の決断 (スコア:5, 参考になる)
> 興味深い決断である。
独自製品から、オープンスタンダードに移行するのは当然の話で、 別に不思議な話じゃないですよ。
独自製品はメンテナンスに非常にコストがかかるし、ソフトウェアはかなりのデフレ傾向にあるので、よほど数をさばける製品でないと、開発に投資した分を回収することができないです。
一般に独自に製品を開発し、それを使い続けるには以下のようなコスト・リスクがあります。
Re:当然の決断 (スコア:2, 参考になる)
リストアップしていただいたコスト・リスクは、
付加価値と表裏一体だったハズです。
MySQL の選択によって phpmyadmin 等から、
簡単にデータ構造へアクセスが可能になります。
データ構造が理解できれば、
最適なコードを生成するのは、容易いと思います。
# つまりパチもんの登場
MySQL 選択には苦悩があったと思うのですが、
Cybozu がどのように乗り越えたのか ...。
興味あります。
Re:当然の決断 (スコア:2, すばらしい洞察)
サイボウズを使ってみた印象では、
・ＤＢをサービスとして起動しなくてよいので、CGI並に
インストール（導入）が簡単
・データベースのバックアップが、サイボウズのＵＩから
簡単に出来る
などの、独自ＤＢならではの付加価値があったと思うので
すが、ＭｙＳＱＬに変更しても大丈夫なんでしょうか。
Re:当然の決断 (スコア:5, 参考になる)
ユーザ数が数百人という、サイボウズとしてはちょっと規模が大きすぎなのですが、Cydbはかなり難アリですね。
まず、データベースのバックアップができると言っても、ファイル単位で丸ごと取っておく事ができるというだけなので、蓄積されたデータ量が増えてくると、バックアップに必要な容量がどんどんと増えて行きます。長期の利用を考えるなら、差分バックアップが欲しい所。
MySQLであれば、スナップショットをフルバックアップとして取っておき、update-logを吐くようにしておけば、それが差分となりますので、フル＋差分という形でバックアップが取れます。
次にデータベースファイル自体ですが、フラグメンテーションを防ぐためでしょうが、かなり大きな単位で増加して行きます。最初は512KB程度ですがデータ量が増えると増分も大きくなっているようです。
それ自体は良いのですが、全システム共通のデータベースファイル以外に、各ユーザごとに一つずつのデータベースファイルを持っているため、ユーザ数が多いと、このデータベースファイルがすごい勢いで容量を増して行きます。
ディスク容量自体は年々容量単価も下がっていますので、それ程問題が無いと言えば無いのですが、上で書いたようにファイル単位でのバックアップしかできませんので、バックアップに要する時間が飛躍的に増えて行きます。
最後に致命的とも言える問題ですが、Cydbではデータベースのファイルが壊れていてもそれなりに動いてしまいます。
そのため、数世代のバックアップを取っていたとしても、それを越えた時点でやっと壊れているという事が露見してしまう事もあります。
データベースファイルが壊れているかどうかを確認するための手段がユーザにはありませんので、実際動作が異常になるまでわかりません。
サイボウズ社へ送れば調べてくれるらしいのですが、上記のようにデータ量が莫大になってくると、容易に送る事もできません。
そして、仮に送ってみて壊れていると確認されたとしても、サイボウズ社ですら修復ができません。
という事は、最古の世代のバックアップも壊れていた場合には、0から再スタートするしか手段がありません。
もちろん、バックアップを上書きせずに永遠に残すようにすれば0よりはマシですが、それにしても何ヶ月も前の状態に戻ってしまう事態もあり得ます。
独自データベースである事にはメリットがあるかもしれませんが、ダンプ、レストア、チェック、修復というデータベースとして最低限の機能も備えていないものでは、メリットも台無しだと思います。
Re:当然の決断 (スコア:1, 参考になる)
>サイボウズ社へ送れば調べてくれるらしいのですが、上記のようにデータ量が莫大になってくると、容易に送る事もできません。
>そして、仮に送ってみて壊れていると確認されたとしても、サイボウズ社ですら修復ができません。
iOfficeの方は知らんが、ガルーンなら去年の夏バージョンあたりから確認・修復ツールが付属してたはず。
使い物になるのかは知らんけどね。
まあ、いずれにせよちゃちなのは確かなんでMySQLにするのは大歓迎。
Re:当然の決断 (スコア:2, 参考になる)
11.1.15.1. 組み込み MySQL サーバライブラリの概要 [mysql.com]
別途サーバを立てない構成は十分に可能でしょう。
サイボウズがどのような構成を考えているかは未確認ですが。
Re:当然の決断 (スコア:1)
そこで、ライセンス締結ですか。
Re:当然の決断 (スコア:1, 興味深い)
なので、CydeをMySQLに置き換えることは、アーキテクチャの変更を伴うと思います。
Cybozuはスクリプトのエンジンを自前で持っていたりと、
OSの機能を極力使わず、移植性が高い点が面白かったですね。
Re:当然の決断 (スコア:1)
Re:当然の決断 (スコア:1, すばらしい洞察)
＞Cybozu がどのように乗り越えたのか ...。
これについて、顧客にいろいろ提案する身としてはそのうち情報が出てくるとありがたいですね。
どこかＩＴ系メディア（ITmediaとかITProとか）が経緯を取材、記事にしてくれると非常に価値ある資料になりそう。
Re:当然の決断 (スコア:0)
> 最適なコードを生成するのは、容易いと思います。
> # つまりパチもんの登場
データ構造の公開とパチもんの関連は薄いと思います。入力情報などから、データ構造くらいある程度想像つきますよね。
それ以前に、オープンソースを探せば、大抵似たような機