RDBMSでは不十分

作者 Sebastien Auvray , 翻訳者 編集部 投稿日 2007年12月6日 午前12時8分

コミュニティ

Ruby,

Architecture

トピック

データアクセス,

パフォーマンス&スケーラビリティ

タグ

データベース,

Relational Databases,

パフォーマンス&スケーラビリティ

リレーショナルデータベースはクライアント/サーバモデルに適合するものの、サービスの世界では新しいソリューションが必要である(source)。RDBMSはスケーラビリティの問題に陥りやすい。冗長性や並列性をどのようにして実現すればいいのか(source)？

（リレーショナルデータベースは）単一故障点となります。特に複製はささいな事ではありません。疑問に思うのであれば、全く同じデータを必要とする2つのデータベースサーバがあることによって起こる問題を考えて見てください。データを読んだり書いたりするために両方のサーバがあると、同時に変更するのが困難になります。マスターサーバとスレーブサーバがあっても、良くありません。なぜなら、マスターはユーザが情報を書き込む際、沢山の熱を帯びるからです。

また、Assaf Arkin氏も整合性を書くこと(source)はRDBMSが自身の重さで内破してしまう理由であると信じている。

参照整合性、制約、アトミック更新などの機能は、クライアント/サーバの世界では非常に重要ですが、サービスの世界では関係ありません。

これらは、ドキュメント指向分散データベースが特に取り組もうとしている典型的な問題である。
MySQLのソフトウェアエンジニアであるDamien Katz氏(サイト・英語)によると、データ管理の柱は以下の4つである(サイト・英語)。

• 保存: データ保存は安全（ACID）、永続的、および効率的であること。
• 視覚的確認: データは簡単に抽出でき、単純なレポーティング方法を統合し、（フルテキストの）検索を実現すること。
• セキュリティ保護: データの区画化、SSL接続の実現、データへのユーザ/グループ/ロールの割り当てなど。
• 共有: オンライン/オフラインにて分散型を採用すること。

Damien氏はCouchDB(サイト・英語)を用いてこれら4つの柱(サイト・英語)を実現している。

CouchDBの定義に当てはまるもの

• JSON(サイト・英語) REST APIを介してアクセス可能なドキュメントデータベースサーバ。
• フラットアドレス空間を持ち、アドホックかつスキーマフリー。 
• 分散型で、双方向のコンフリクト検出/管理機能を備えた頑強な増分レプリケーションが可能。
• クエリとインデックスが可能で、クエリ言語としてJavaScriptを使用するテーブル指向のレポーティングエンジンを搭載する。

CouchDBの定義に当てはまらないもの

• リレーショナルデータベース。
• リレーショナルデータベースに代わるもの。
• オブジェクト指向データベース。さらに具体的に言うと、CouchDBはOOプログラミング言語向けのシームレスな永続層として機能することを意図していない。

CouchDB、およびドキュメントをデータベースに挿入してからクエリの実行用にビューを定義するという考えに着想を得て、Anthony Eden氏(サイト・英語)は自らドキュメント指向データベースであるRDDB(サイト・英語)を記述し始めた。網羅的なレビュー(source)がすでに入手可能である。

現時点でのRDDBの特徴(サイト・英語)は、以下のとおりである。:

• ドキュメントが単純に名前/値のペアの集まりである。
• Rubyコードでビューが定義できる。
• 低減できるブロックを定義して、ビューから最初のマッピングデータを減らすことができる。
• ビューを実体化してクエリパフォーマンスを向上できる。
• データストア/ビューストア/実体化ストアはプラガブルである。現在の実装はRAM、区分編成ファイル/ファイルシステム、およびAmazon S3である。 
• 分散型の実体化は機能するかもしれないが、書き換えが行われる。

InfoQは、Anthony氏と情報交換し、RDDB、CouchDB、およびRDBMSについて話を聞く機会に恵まれた。

まず、研究プロジェクトを話題にしていたRejectConfにて、RDDBに取り組み始めたきっかけは何ですか？

私はRDDBを個人的な研究プロジェクトであると考えています。ここ数年、分析システムに深く関わり、データウェアハウスなどを開発してきました。また、AmazonのWebサービスも使用してきました。RDDBを使用してこの2つをある時点で統合し、EC2およびS3上で動作する分析データベースが実現できればいいと思っています。これこそ私の第一の目的であり、RDDB作成の背後にあった原動力です。

データ統合という課題にさらされている日々の仕事において、現在ドキュメント指向分散データベースは十分に活用されておらず、今後は導入が進むと思いますか？

まだはっきりしたことは言えません。リレーショナルデータベースの背景には多くの歴史があり、成熟するまで長い時間がかかりました。このため、一方では、リレーショナルデータベースが信頼に値するものとして、運用システムのための明白な選択肢となります。他方では、リレーショナルデータベースは必ずしもすべての種類のデータストレージおよびルックアップに最適な選択肢ではないため、新しいデータストアの機会は存在します。ドキュメント指向データベースがその機会をつかむかはまだ分かりませんが、そうなるかは、スケーラビリティと、パフォーマンスの低下を招くことなく大量のドキュメントを処理できる能力に負うところが大きいと思われます。

サービスモデルの世界でRDBMSの場はまだ存在しますか？参照整合性、アトミックの更新、および制約はクライアント/サーバの世界では価値がありますが、サービスの世界でも妥当でしょうか？

RDBMSは依然として他の判断基準であるため、リレーショナルデータベースがすぐに廃れるものとは思いません。私が思うに、最終的には、事実上一時的であるデータベースが手に入るなら、アトミックの更新の必要性は過去のものとなり、あらゆる種類の更新の必要性をなくすことができるかもしれません。確実に必要なものすべてがリソースに含まれ、リンク切れに対するシステムの耐性が強まった環境に移れば、おそらく参照整合性も必要なくなります。制約は常に役に立つでしょうが、もしかすると、制約のためのロジック定義能力を備え、いっそうリッチになるかもしれません。

RDDBをCouchDBと比較するとどうなりますか？（RDDBもCouchDBもごく初期の段階だとは存じていますが）。CouchDB Rubyバインディングと比べて、RDDBを使用するメリットは何でしょうか？

その2つの質問はまとめて答えることができると思います。CouchDBはErlangで、RDDBはRubyで記述されているため、Ruby開発者にとっては、RDDBの方がずっとハックしやすくなります。CouchDBは分散処理の間、プロセス間通信にErlangの言語機能を使用しますが、一方RubyはRindaやRuby SQSライブラリなどのライブラリに依存します。RDDBにおいて必要なのはRubyGemsを使用してインストールするだけであるため、Ruby開発者にとって、RDDBを立ち上げて実行するコストはCouchDBの場合よりも大幅に少なくなります。RDDBにおけるビューはRubyで記述されますが、CouchDBのビューはJSONで記述されています（少なくとも現在のところ）。現時点では、RDDBの方がドキュメントストア、ビューストア、および実体化ストア（これらすべてがRAM、ファイルシステム、S3ストレージをサポートします）向けに異なる実装を備え、プラガブルだと思います。また、RDDBは実体化向けの異なる実装（ローカル、Rinda、EC2など）とともに、スレッド化/非スレッド化実体側も備えています。

InfoQではしばらく前にActiveWarehouse(source)についての記事を記載しましたが、そのプロジェクトの進み具合はいかがですか？ActiveWarehouseはエンタープライズ内で使用されていますか？

最近、ActiveWarehouseの周辺は静かです。作業と利用のほとんどは、ActiveWarehouse ETLライブラリを備えたETL側だと思います。私の目的は、近い将来にActiveWarehouse ETLのバージョン1.0をリリースすることです。Railsプラグインに関しては、バージョン1.0へのアップグレードが実現するには、ディスプレイ側へのさらなる取り組みが明らかに必要です。一部の人はユーザインターフェースコードの変更に関心を示しており、今後どうなるか見ていてください。

原文はこちらです：http://www.infoq.com/news/2007/11/the-rdbms-is-not-enough

• 次へ >