続、グーグルはリレーショナルデータベースをクラウドに乗せるか?

2009年4月20日

先週、グーグルはリレーショナルデータベースをクラウドに乗せるかというエントリを書いたところ、いくつかのコメントやトラックバックをいただきました。

いずれも興味深いコメントだったにも関わらず、コメント欄に利用しているTypePad Connectがなぜかうまく動作しておらず、表示できませんでした。しかしそれではもったいないので、このエントリとして紹介させていただこうと思います(TypePad Connectには障害報告しました)。

元になったエントリの主旨をまとめると、Google App EngineはJavaに対応したし、企業内のデータセンターとセキュアな通信もできるようになった。これはGoogle App Engineが企業向けのサービスとして方向を定めたことを示す。だとすると、企業システムに不可欠なリレーショナルデータベースもきっとGoogle App Engineにのせてくるのではないか、というものでした。

これに対して、まずは「ひろし」さんのコメント。

これ、異なる二つの方向性が同時に考えられる話だと思います。

「クラウド」の概念は漠然としていますが、方向として 1.ひとつのサーバーに載らないほどの超巨大データテーブルを、分散コンピューターで扱う 2.互いは独立した個別DBを仮想化されたサーバー環境でホストする

前者は、BigTable など、Googleの方向性で、処理場のキーは、個別操作での並列製を失わないためのMap/Reduce 的な仕組み

後者は実は、可用性に配慮しつつ増大するサーバーパワーを背景にパーティショニングを進め、ホスティングコストを低減させること。つまり、ディスクリートなDBの集合を単一環境で複数走らせて並列性を上げること。

おそらく、Azure で考えられているのは、後者の方向なので、一貫性などへの処理も個別には局在化できることで、実装にそれほど困難はないとおもいます。

また、ビジネスで必要とされるDBはかつては巨大とされたものでも、高々テラバイトです。単一サーバーに収まらないサイズではありません。また、局所分散環境(マルチコア)での、性能のリニアさを向上させる Transactional Memory などの技術も出てきています。一方、超巨大テーブルでの一貫性処理に関しては、レイテンシーという大きな壁があり、並列性を大きく低下させる可能性があります。また、ニーズもそれほど明らかではありません。おそらく、両者は組み合わされて使われるのではないかと思います。この観点から言えばGoogleが実装することにもそれほどの困難さは無いと思います。

ビジネスで必要とされるDBは、単一のサーバに収まらないサイズではなくなっている、というのは確かにポイントですね。わざわざ分散させて難しくする必要もないのではないかと。だとしたらクラウドへの実装はそれほど困難ではないかもしれませんね。

続いて「まなぶ」さんのコメント。

RDBを実装するということが、ACID対応バッチリなミッションクリティカルなデータをホストするということであれば、それはやらないんじゃないかという気がします。

それより、検索・分析系のDWHのデータをホストするというサービスのほうから始めるんじゃないでしょうか。標準的なAPIとしてSQLはサポートするけれど、Updateはバルクだけとかいう割り切りで。RDBからのデータはインポートできるけれど、内部でのデータの持ち方はRDBとは全然別で。売りは検索の速さで、TeradataやNetezzaのCloud化というイメージで。Google DocsのSpreadsheetにも出力できたり、OLAP用の拡張したりして。

これなら、実装は既存のキーバリュー型の上にSQLのパーサ載せて、インポートのUtilityを提供するくらいでいいんじゃないでしょうか。そんな簡単でもないかな。

キーバリュー型データベースをSQLっぽいレイヤでラップするというアイデアは、はてなブックマークのコメントでもいただきました。実はマイクロソフトは当初、Windows Azureでそれをやろうとして、多くのユーザーから「本物のSQLをサポートしてくれ!」というフィードバックがあり、方向転換して本物のSQLをサポートすることにした、という経緯があります。

既存のSQL Serverのアプリケーションを多数抱えているマイクロソフトとグーグルでは事情が異なりますし、BigTableを利用可能なままSQLも一部サポートするならグーグルの強みを活かせそうなので、このあたりが現実性がいちばん高いかな、とも思います。

続いてはトラックバックでいただいた意見です。「グーグルは急いでクラウドにリレーショナルデータベースを載せるか」から。

グーグルが(あえて)RDBMSを積極的に提供しないことによって、App EngineではMapReduceを押していくということも、ありえるのかなと。

MapReduceというかたぶんBigTableですよね。まなぶさんのコメントと同様、レガシーな資産を持たないもののメリットを最大限活かすために、あえてリレーショナルデータベースをサポートせずに、キーバリュー型データベース対応のアプリケーションへの移行を積極的にサポートすることで、ビジネスアプリケーションの土俵そのものを変えてしまう、というのは、かなり大胆ではありますがシナリオとしてはあり得そうですね。

Google App Engineは、Amazon EC2と違って自分でデータベースをインストールすることができませんから、基本的にはグーグルが用意したデータベースをアプリケーションで使わざるを得ません。果たしてそのデータベースをグーグルがどうするのか、この戦略が同社のクラウドの今後を大きく左右することは間違いないだけに、引き続き注目していくつもりです。


このエントリーをはてなブックマークに追加 Bookmark this on Delicious     fig Follow Me  fig RSS

タグ : Google , NoSQL , クラウド , リレーショナルデータベース

次の記事
オラクル、「MySQLはオラクル製品群の一部に、Linuxへのスタンスは変わらず」
前の記事
早くもPHPが動作しはじめたGoogle App Engine

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
RSSリーダーで : Feed





アクセスランキング - 過去7日間

  1. 特許庁の基幹システム失敗の背景にある、日本に…
  2. 国内の開発者が使っている言語、1位C、2位V…
  3. 特許庁の基幹システムはなぜ失敗したのか。元内…
  4. 英国政府、新ポータルGov.ukをクラウド、…
  5. なぜ米ヒューレット・パッカードは、一挙に16…
  6. OpenFlowベンチャーのNicira N…
  7. ライアン・ダール氏、Node.jsの開発リー…
  8. フラッシュストレージが最大500TB! 米N…
  9. EMC、満を持してPCIe接続フラッシュスト…
  10. 2012年1月の人気記事「グーグルのバグ予測…
  11. マイクロソフトの責任者が語る「われわれはどの…
  12. 「絶対落ちないシステムを作れ」という要件に、…
  13. ソフトウェアテストの30年前と30年後(前編…
  14. ソフトウェアテストの近未来を話そう(前編)~…
  15. ソフトウェアテストの近未来を話そう(後編)~…

最新記事 10本

バックナンバー



アルファブロガー・アワード2010受賞 Publickeyはアルファブロガー・アワード 2010を受賞しました! いつもご愛読ありがとうございます。









blog comments powered by Disqus