Cloud Platform Storage: Relational vs. Scale-Out ?
# Friday, February 27, 2009
From David Chappell’s Blog
From <http://www.davidchappell.com/blog/2009/02/cloud-platform-storage-relational-vs.html>
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
David Chappell さんといえば、TechDays で配布された Azure Platform ホワイトペーパーの著者であり、オピニオン･リーダーとしての立場から、一連の Microsoft クラウド戦略について、いろいろな形で情報を提供している人です。彼のブログに、とても興味深い内容が書かれていて、それとはなしに目を通していたのですが、今回の Relatonal SDS の発表を受けて「こりゃ一大事！」と思い、Agile Cat に載せてよいですか？ ・・・とメール送ってみました。
すると ・・・
This is very kind of you, Agile Cat — I’d be happy to have you publish a Japanese translation.
Thanks! – David
・・・という、気持ちの良いレスが戻ったので、写真入で抄訳をポストしちゃいます！
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
現時点において、利用可能なすべてのクラウド･プラットフォームが、スケーラブルなストレージ･メカニズムを提供している。Google の AppEngine は Datastore を、Amazon Web Services は SimpleDB を、Windows Azure はテーブルを、そして、Salesforce.com の Force プラットフォームはオブジェクトストアをという状況だ。それら全てにおいて、類似すると思われる事柄は、テーブル･ベースであるより、むしろ階層的なストレージと、スキーマ･レスの容易なアプローチ、そしてシンプルなクエリー言語である。
しかし、何故なんだろうか？ これらのプラットフォームは、どのような理由から、普通のリレーショナル･ストレージを提供しないのだろうか？ それらの階層的なアプローチは、いくつかの強みを持っている。つまり、単純さと、柔軟さである。しかし、たくさんの弱点も持っている。 ここに、重要な点についてまとめてみた：
それらが普通のテーブルを提供しないため、こうしたストレージ･テクノロジーをデベロッパーが理解して、利用することが難しくなっている。オンプレミスの一般的なリレーショナル･データベースと、階層的なクラウド･データストアの間でデータを移動するには、そのための作業も必要になる。たとえば、良いパフォーマンスを達成するには、アプリケーションの最も一般的なクエリーに対して、最適化されたデータ階層が必要になるだろう。それは、いつものリレーショナル･アプローチとは違う何かを、構成しなければならないという意味合いを持つ。
それら全てが、標準的な SQL をサポートしない。それにより不便さが生じ、さらには join や aggregate といった有用な機能が使えなくなる。それぞれのプラットフォームが独自のクエリー言語を持っているため、デベロッパーの作業は難しくなり、さらには、プラットフォームへの囲い込みが生じる。
標準的なリレーショナル･データの欠落は、たとえばレポーティング･サービスのような、既存のツールが容易に利用できないことを意味する。
スキーマが無いために、プログラムには多くのエラーが潜むようになるだろう。たとえば、整数フィールドに文字列をストアするようなエラーを、データベースに依存することなく、自分で見つけなくてはならない。
これらは重要な制約となり、大きい問題を提起する。つまり、誰がこんなものを使うのかという疑問である。何ゆえにクラウド･プラットフォームのベンダーは、このような制約されたアプローチではなく、SQL を用いたリレーショナル･ストレージを提供しないのか？
その理由は、ほんとうに大規模なデータを保持する、リレーショナル DBMS のスケールについて、作り方を知っている人が居ないという点にあるのだろう。確かに、より大容量のマシン上で実行することで、リレーショナルシステムに大量のデータを処理させることができる。しかし、マルチ･マシンをまたいだリレーショナル･データのレプリカを作りながら、そのための処理を実施することは遥かに難しいことになる。言い換えれば、従来からのリレーショナル･データベースはスケールアップするが、それらのスケールアウトは難しいということになる。
リレーショナル DBMS を用いたスケールアウトの方式として、データをDBMS のマルチ･インスタンスに分割するという手がある。 たとえば、「A」で始まる顧客は 1つのインスタンスであり、その次のインスタンスは「B」で始まるという方式である。 Sharding と呼ばれる、このアプローチが上手くいくこともある。 しかし、その管理は難しく、また、断念する理由もたくさんある。リレーショナルの世界では馴染み深い all-in-one の機能を失うことになる。つまり、それぞれのインスタンスにまたがる SQL クエリーが不可能になる（join と aggregate の喪失）。それと同様に、レポーティング･ツールも簡単には使えない。そして、データベース全体にまたがる共通スキーマを、自動的に維持することができなくなる。
こんな問題について、聞いたことがありますか？しかし、クラウド･プラットフォームが提供する、階層的なストレージ･メカニズムにより、失われるものを反映すると、そうなるはずだ。 これらの階層的なストアの構造は、ストレージをスケールアウトさせることで、大規模でスケーラブルなストレージを提供することに焦点を合わせている。Sharding データベースとまったく同様に、スケーラビリティとの間で、機能のトレードオフがある。
おそらく、いつの日にかは、これまでのリレーショナル･データベースから得てきた全てを提供するスケールアウトのストレージを、クラウド･プラットフォーム上で利用できるようになるのだろう。 しかしながら、今のところは、最先端のスケールアウト･ストレージであっても、SQL とリレーショナル･データベースで我々が慣れ親しんできた多くのものを、断念するよう要求しているように思われる。
それでは、どのような状況で、クラウド･プラットフォームのスケールアウト･ストレージを使うべきなのか? Google AppEngine のようなケースにおいては選択肢がない。すべての永続的なデータが Datastore にストアされる。しかし、他のプラットフォームは選択肢を持っている。 たとえば、Amazon Web Services は両方の選択肢を提供する。ひとつはスケールアウト･ストレージ のための SimpleDB であり、もうひとつは、仮想マシン上で Oracle や SQL Server といった、標準的なリレーショナル DBMS を実行する環境である。 これまでに説明してきたように、後者はスケールを提供しないだろうが、フル･リレーショナル･システムを与える。
私の主張は、こうである。スケールアウト･ストレージは非常に制約されているため、アプリケーションが膨大なスケーラビリティを要求とするときにだけ使用すべきである。リレーショナル・データベースのアドバンテージを断念することは、機能とスケーラビリティの間のトレードオフに価値があるときにだけ意味をなす。これまでのところ、私の感覚としては、それを必要とする、多くのクラウド･アプリケーションは存在しないということになる。つまり、SimpleDB の利用は、たとえば VM で利用するリレーショナル･データベースよりも、ずっと人気のないもののように思われる。
やはり、リレーショナルなストレージは素晴らしいものなんだ。ただし、すべての問題を解決するものではないだろう。したがって、スケールアウト･ストレージの制約を受け入れることも時には必要である。あなたのクラウド･アプリケーションが大規模なスケール必要としないなら、リレーショナルの選択は、数多くの意味をもたらすだろう。
From <http://www.davidchappell.com/blog/2009/02/cloud-platform-storage-relational-vs.html>
ーーーーーーーーーー
こちらも、ど～ぞ。
New Relational SDS Q&A 第一ラウンド！
http://agilecat.wordpress.com/2009/03/13/new-sds-interview_1/
