Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

データベースは目的別に使い分けるべし

2009年11月9日

Perspectives - One Size Does Not Fit All

元マイクロソフトのSQL Server開発チームの一員であり、その後マイクロソフトのデータセンターのアーキテクトとして活躍。昨年アマゾンに移籍して、現在はAmazon Web Servicesの上級エンジニアであるJames Hamilton氏が、自身のブログの「One Size Does Not Fit All」というエントリで、リレーショナルデータベースだけにとどまらない幅広いデータベースの種類を4つに分類して紹介しています。

4つの種類とは「機能優先」「スケーラビリティ優先」「シンプル」「目的別」です。

Hamilton氏は、アマゾンがAmazonクラウドでMySQLのサービスを開始したところ、以前から提供していたキーバリュー型データストアの「SimpleDB」は終了するのではないかと心配する声があったことを挙げ、

I can understand why some might conclude that just having a relational database would be sufficient but the world of structured storage extends far beyond relational systems.

リレーショナルデータベースがあれば十分な人が多いために、こうした声が出ることは理解している。しかし、構造化ストレージの世界はリレーショナルを超えてもっと幅広いものなのだ。

と、リレーショナルデータベース以外にもさまざまな目的に対応したデータベースの存在に目を向けるために、このエントリを書いたと説明しています。Hamilton氏が4つに分類したデータベースの世界を見てみることにしましょう。

機能優先のデータベース

このセグメントでは、いわゆるリレーショナルデータベースがリストアップされています。

OracleSQL ServerDB2MySQLPostgreSQL

さらに、クラウド対応としてAmazon Relational Database Serviceを挙げています。Hamilton氏のリストには含まれていませんが、マイクロソフトのSQL Azureを追加しておきましょう。

スケーラビリティ優先のデータベース

データベースのスケーラビリティを実現する方法としてHamilton氏は「多数のRDBMSによるデータ共有」と「スケーラブルなキーバーリュー型データストア」の2つを挙げています。

前者として挙げているのが、DB2 Parallel EditionOracle Real Application Clusters(Oracle RAC)

後者としてはさまざまなデータストアがありますが、Hamilton氏が挙げているのが、Project VoldemortRingoScalarisKaiDynomiteMemcacheDBThruDBCouchDBCassandraHBaseHypertableなど。

また、クラウド上のキーバーリュー型データストアとしてAmazon SimpleDBも挙げています。ここではグーグルのBigtableも追加しておきましょう。

シンプルなデータベース

Hamilton氏が「Simple Structured Storage」と書いているセグメント。リレーショナルデータベースほどの機能や複雑な操作は必要とせず、キーバリュー型データストアほどのスケーラビリティも不要。しかしファイルシステムほどおおざっぱでは困るし、検索やインデックス付けといった機能は求めたい、といった要求に合致するデータベース。

クライアント側で最も多くこの用途で利用されているのはBerkeley DB。そしてサーバ側ではいくつか例が挙がっていますが、FacebookのメールのインボックスとしてCassandra、Last.fmではProject-Voldemortを利用予定、アマゾンのショッピングカート用にはDynamoが使われているとのことです。

目的特化型データベース

ここではわずかな例しか挙げられていませんが、イベント処理プラットフォームのStreamBase、データウェアハウス用のVertica、MapReduceをベースとしたAster Dataなど、さまざまな目的に特化したデータベースがこれからも登場するだろうとHamilton氏は書いています。

データベース多様化の時代がくる

Hamilton氏が指摘するように、今後は何でもリレーショナルデータベースを使うのではなく、データの大きさ、処理の内容によって適切なデータベースを使い分ける時代が来ると僕も思います。

これは何と言っても、ビジネスで処理するデータがWebスケールになったため、データの量や増加速度、そしてデータそのものの中味が多様化してきたためです。「Hadoopの最新動向を「Hadoop World:NY 2009」の資料から(前編)」で紹介したように、成功するネットビジネスでは毎日数テラバイトのレベルでデータが増えており、それを保存するだけでなく、分析してビジネスに活かしていかなければなりません。MapReduceのように、それに適した新しいデータ処理方法が注目されるのは当然でしょう。

一方で、「カラムナデータベース(列指向データベース)とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること 」で紹介したカラムナデータベースや、「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現 」のように、あるいは「キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると 」で紹介したようにリレーショナルデータベースそのものも新しい環境や技術をベースにして進化し続けています。

まるで今はデータベースの種類が爆発的に増えているカンブリア紀のようですね。

新しいデータベースの種類や技術が登場すると、次に期待されるのはそれらに対応した「SQL」のようにデータに対して汎用かつ分かりやすい操作体系の登場でしょう。それがSQLのような言語になるのか、RESTのようなAPIっぽくなるのか、あるいは別の形態をとるのか分かりませんが、そうなるには新しい分野のデータベース体系がもう少し整理されてからのように思うので、まだ数年単位で時間がかかることは間違いなさそうです。

あわせて読みたい

NoSQL RDB データベース




Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

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