InfoQ

News

サービス型データベースというのは悪いアイディアか?

作者 Jean-Jacques Dubray, 翻訳者 渡辺 裕之 投稿日 2008年8月27日 午前12時3分

コミュニティ
Architecture
トピック
SaaS,
プラットフォーム
タグ
データベース管理,
Amazon SimpleDB,
ADO.NET Data Services,
EC2

クラウド・コンピューティングは(参考記事・英語)私達の業界に重大なパラダイム・シフトをもたらした。David Chappell氏(リンク)は以下のように述べている。

このパラダイム・シフトの最も重要な点はクラウド・プラットフォームの出現です。このようなプラットフォームによって開発者はクラウド上で稼働するアプリケーション、またはクラウドから提供されるサービスを利用するアプリケーション、あるいはその両方のアプリケーションを開発することになります。

これらのプラットフォームはとても似ているように見えるが、Dave氏は以下のように注意を促している。

域内向けのプラットフォームとクラウド・プラットフォームの2つを同じレンズから眺めることは有意義ですが、この2つはまったく同じものではありません。域内向けのプラットフォームで稼働する機能をクラウドに移行すると、かなり広範な変更が必要となることがあります。

Dave氏はアプリケーション・アーキテクチャを以下の三つに分類している

  • 基盤
  • 基幹サービス
  • アプリケーション・サービス

そして以下のように主張している

クラウド・アプリケーションはクラウド基盤上で構築できます。これはon-premiseなアプリケーションがon-premisesな基盤上で構築されるのと同じことです。どちらのアプリケーションもon-premises/クラウドのどちらで提供されている基幹サービスにもアクセスすることができる。ちょうどon-premisesプラットフォームが今日のアプリケーションをサポートしているように、クラウド・プラットフォームは将来構築されるだろうアプリケーションに対してもサービスを提供します。

ありとあらゆる基幹サービスの中で、情報システムがそれを抜きにして構築することができないという点で"データ・サービス"が最も重要であることはほぼ間違いない。最も有名なデータ・サービスを提供したクラウド・プラットフォームが最大のシェアを確保するだろうという点でデータは重要な戦略的な価値も表している。

Dave氏は異なるタイプのデータ・サービスがあると考えている

クラウド上のリモート・ストレージには異なるスタイルのものがあります。例えば、Amazon社のSimple Storage Sevice(S3)は(参考記事・英語)ベーシックで構造をもたないリモート・ストレージを提供しています。開発者に公開しているモデルは、山のようなバイト列がバケツに突っ込まれただけのオブジェクト、そのものです。

クラウド・ストレージに対するもう一つのアプローチはより構造化されたデータをサポートすることです。例えば、Microsoft社のSQL Server Data Services(SSDS)は(参考記事・英語)、コンテナ上には1つもしくはそれ以上のエンティティが存在し、それぞれがいくつかのプロパティを持っています。

Arnon Rotem-gal-Oz氏は"サービス型データベース"がいい考え方かどうか(リンク)悩んでいる。この考え方はMicrosoft、IBM、Amazon(参考記事・英語)、LongJump(参考記事・英語)やEnterpriseDB(リンク)などが参加する業界の流行りである。各社は本質的に同様な機能を提供しようと試みている。氏は次のように説明する。

では、なぜ(RESTfulであるかどうかに関わらず)Webサービス経由でデータベースを公開することが間違っているのか?いくつか挙げてみましょう。

  • "サービス"という考え方を避けている ― CRUDのためのリソース/サービスとして提供されているだけで、ビジネス・ロジックは一切含まない
  • 考え抜かれた結果ではなく、内部のデータ構造もしくはデータそのものを公開している
  • 真のサービスを迂回させ直接データにアクセスすることを促進する
  • (データ・ソースという)blobなサービスを作っている
  • 分散コンピューティングに対する間違った考えを現す、重要ではない(blobなサービスの多様なインタフェースとしての)[半分だけの]サービスを促進する。
  • 羊の皮をまとった単なるクライアント・サーバ構造である

シアトルのリポーター、Andrea James氏は別の熱のこもった記事を書いた(リンク)

ビジネスにとっては、コンセントから流れ出る電力は無限に思えるようです。そして水も際限なく蛇口から流れ出るように思えるようです。ビジネスでは利用した分だけを払うのです。でも、コンピュータの処理能力はそこまで無限ではありません。

私達は辛うじて、構造化されたデータの管理方法なしでは浮かび上がってこないクラウド・プラットフォームの表面を引っ掻いている状況にいる。どのデータ・サービスやどのクラウド・プログラミング・モデルが勝ち残るか言及するにはまだ時期尚早なようである。"サービス型データベース"を信じてあなた自身の企業システム内のデータを委ねることができますか。アプリケーション・サーバを通してデータにアクセスすることと、自身で保持するストレージ・システムに対して単純にCRUDすることのどちらを好みますか。

原文はこちらです:     http://www.infoq.com/news/2008/08/is-data-as-a-service-a-bad-idea

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。