昨日のエントリですが、梅田望夫・英語で読むITトレンド にオープンソースの話が上がっていました。このエントリ自体はオープンソースという開発方式に関しての考察であるのだけど、僕が注目したのは文中の MySQL とオラクルのくだり。
MySQLの売上は、2004年現在で2000万ドル。そんな売上はオラクルならば17時間で上げてしまうよ、ということで、オラクル幹部の公式発言は、こんなふうにMySQLの存在など歯牙にもかけないという態度だ。
オラクルの規模から見たら MySQL が手にかけている市場の規模なんて鼻クソ、ということらしいです。ということでオラクルさんは MySQL には届かない、更に上位のエンタープライズ市場で大きな売上をあげているわけですが、僕はおそらく、オラクルや DB2 などの商用の RDBMS にとって、MySQL や PostgreSQL は破壊的イノベーションなんだと思います。(破壊的イノベーションに関しては 『イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき』 を読むといいです。)
MySQL の売上規模はオラクルの売上規模からみたら相対的に無視できる程度のものなのでオラクルの「価値基準」には合いません。つまり MySQL が積極的に利用されるような分野、つまり、高額なサポートを必要とせず、オラクルが謳う様なミッションクリティカル性能あるいはスケーラビリティがそれほど厳密には要求されない市場には、オラクルが投資するだけの見返りがないということで無視するわけです。
一方で、まだ規模の小さい MySQL にとって 2000 万ドルは十分すぎるほどの巨額の富。彼らの価値基準には十分にマッチする市場なわけです。
スウェーデンで起業されたベンチャーである。2001年7月にVCから資金調達をして既に3年が経過している。大オラクルからはゴミみたいな売上かもしれないが、ベンチャーから見れば「売上高$20mil」というのは立派なもので、まもなく公開が射程距離に入ってくるサイズだ。
というくだりからもそれが伺えます。オラクルは、この MySQL が進出してきている市場は、自社の価値基準には合わないし、投資しても会社の規模に見合うだけのリターンが得られないということで、この市場はさっさと MySQL に明け渡して喜び勇んで上位市場へ移行します。オラクルが上位市場へ移行したことにより、ぽっかりとあいた下位市場では破壊的企業、オープンソースの RDBMS を投入する企業が活躍するわけです。
そこで力をつけた破壊的企業は徐々に上位市場を侵食しはじめ...というのがイノベーションのジレンマどおりのシナリオですね。
そこまでうまくいくかどうかは別として、MySQL や PostgreSQL がどうして破壊的なのかという問いに関しては、まず第一にフリーだからという点が挙がります。しかし実はここは重要なポイントではなく、コストが劇的に下がったことで RDBMS をファイルシステムに代わる単なるストレージとして利用するようなシステム形態が可能になった という点が一番大きいのだと思います。
単なるアプリケーションの設定情報を保存しておくとか、アプリケーションのキャッシュを保存しておくとかといった用途のために高額のライセンス料を支払ってオラクルを使うというのはばかげた話ですが、MySQL であればそれも可能。また、単に無料というだけでなく、MySQL は RDBMS をストレージとして利用するという観点で設計されていることもあり、その点においては非常に柔軟かつ強力です。
これによりどんなことが可能になるかというと、NFS のような不安定な仕組みを利用せずとも、TCP/IP 付きのストレージによりデータを共有することができます。また、SQL のように標準化されたインタフェースでそれを操作することができ、プラットフォーム非依存なストレージとして活用することができます。
実際、はてな ではこの MySQL の利点を最大限まで活かして多くのデータを MySQL に格納して共有しています。アプリケーションのキャッシュなど、障害が発生して消えてしまっても特に痛手ではないようなデータはオンメモリ・レプリケーションでディスク I/O をカットして高速化させたりしています。
この、ファイルシステム代わりのストレージとして RDBMS を使うという考え方が定着してくると、アプリケーションの開発の仕方や可能性がかなり拡がるわけで、もう以前の環境には戻れないでしょう。従来その製品で想定されていた利用形態とは異なる形態で威力を発揮しはじめているという点においても、MySQL は破壊的なのでした。(そういう意味では、PostgreSQL よりも MySQL の方が、破壊的な性質は大きいと考えます。)
というわけで、オラクルさんうかうかしてると危ないですよというお話でした。
「ファイルシステム代わりのストレージとして RDBMS を使う」というのはPerlでDBMを使うノリですよね。その分野では完全に無料ではないMySQLよりもSQLiteのほうが使い勝手が良いような。ライセンス面などで。ただしMySQLがすでに認知されてる分だけ導入の心理的コストは低いのも事実ですね。Windowsソフトでもデータを保存するために埋め込みRDBMS+ODBCというのはアリですね。
[1] Posted by: zerobase at September 16, 2004 05:00 PM [返信]>>1 zerobase さん
導入障壁が低いというのと、あとはやっぱりストレージ代わりといっても運用・保守性。
技術的な観点からいくと、
現時点で SQLite は MySQL や PostgreSQL のように TCP/IP Socket での接続ができないのでネットワ-クストレージ的には使えないのは痛いですね。
それと、ファイルベースの SQLite は write のときにテーブル単位でロックがかかってしまうので、INSERT の多いシステムだとパフォーマンスが出ないとか、トランザクションの中にいれないとパフォーマンスが激減という点なんかもあります。
そういう意味では、単にストレージとして使えるというだけでなく技術的にも商用の RDBMS と同等の性能をもっているというところも MySQL の大きなポイントですね。
[2] Posted by: naoya at September 16, 2004 05:07 PM [返信]例えば、MySQL/PostgreSQLをストレージ(スプール)として使うWebメールシステムはあるのでしょうか。
DateやSubjectやToでインデックス化しておくとビューの生成処理の大半をSQLサーバ側に任せられますし、クライアントに一度に提示してみせるべきメール本文は高々数件ですから必要とされるスループットも大したことないわけでSQLサーバとの相性が良さそうな気がするのですけれど。
[3] Posted by: (o) at September 16, 2004 05:41 PM [返信]dbmail、なるほど。直球勝負ですね、私の意図とは微妙に異なりますが。
私の意図は一週間以内に↓あたりにまとめてある予定。
http://as-is.net/blog/archives/000911.html
最近のLivedoorやYahooなどのメールスプールはどういう構成になっているのでしょうね。どなたかご存知でしたら教えていただけると幸いです。
[5] Posted by: (o) at September 17, 2004 03:50 PM [返信]