Michael Stonebrakerが語る：主要RDBMSはレガシーテクノロジーである

作者 Ryan Slobojan, 翻訳者 編集部 投稿日 2007年9月10日 午前2時1分

コミュニティ

.NET,

Java,

Ruby,

Architecture

トピック

データウェアハウス,

データアクセス

タグ

データベース,

Debate,

Data Warehouse

Ingres、またPostgres関連性データベースマネージメントシステムの共同設立者、そしてVertica Systems（サイト・英語）のCTOであるMichael Stonebraker氏は、最も主要なデータベースはレガシーテクノロジーであるべきだ（source）と主張し、データベースコミュニティー内でフレームワークを論議 の的としている。

Stonebraker氏は、問題となっている（IBMのDB2、MicrosoftのSQLサーバ、そしてオラクル）データベースは25年以上前に構築された2つのプラットフォーム（System RとIngres)に基づいているので、業界に特化した製品というよりも、むしろ一般的な目的に使用されるとされている。また彼は当時それらがデザインされた環境は今日のものとは異なっており、ハードウェアの特性とデータベースの仕様が大変難しくなっている事を指摘している。特に、Online transaction Processing(OLTP)は当時データベースが使用されていたただ一つの領域であった。今日では考えられるものとして、データウェアハウスやセミ ストラクチャーデータのような非関連性のアプリケーションが存在する。

そして彼は”ワンサイズが全てに対応”というようなアプローチがもはや正しいコンセプトではないことを指摘し、また「私が考えられる主要なアプリケーションエリア内では、50からそこらのファクターにより”ワンサイズで全てに対応”のコンセプトを実践する、垂直の、市場に特化した内部でSQL DBMSを構築するのが可能である。」と述べた。そして彼は下記のように言及している。

私の予測はそのうち列ストアがウェアハウス市場を支配して、完全に行ストアに置き換えるというものです。たくさんのウェアハウスユーザー達が苦労してい るので（有効なウィンドウでダウンロードすることができない、アドホッククエリをサポートできない、大掛かりなアップグレードなしにパフォーマンスの向上が得られない等）、私は顧客たちがパフォーマンス向上への近道を探求して行くにつれ、比較的早い時期にこのコラムの移行が起きるであろうと考えている。

長い目で見て私はユーザー達が苦労を抱える他の市場で同じような種類の移行と、特化されたソフトウェアアーキテクチャからの斬新なパフォーマンス向上がもたらされると予測している。

ComputerWorldのErik Lai氏はコラム指向のデータベースの背景（source）を説明した。

• コラムデータベースは行ごとの規則に基づいたものに反して、列ごとの規則に基づいたデータを保存している。
• なぜなら似たようなデータが隣接しており、コラムデータベースがいろいろな種類のクエリのディスクリードタイムを最小化するからだ。（例：データウェアハウスクエリ）
• グーグルのBigTableはたくさんのGoogleアプリケーション（例：Google Maps、Google Reader）を動かしているコラム指向のデータベースである。

またLai氏はロウデータベースが、データのディスクへの記述等などコラムデータベースにおいても利点があることを指摘している。行の記述は単体の動作であり、一方複数のコラムの記述は複数の記述を要する。

ワンサイズが全てに対応”式コンセプト消滅に対する反論（source）と共に、これに関したSlashdotにおける論議がたくさん（source）行われてきた。”

その廃れかけた疑問に関して、ワンサイズが全てに対応コンセプトはしばらくの間全てにおいて十分対応するだろう。ストレージにつまらないデータを詰めるの を実行するコードを自動生成させるのを可能にするという理由のためだけに、パフォーマンス性を減少させる持続レイヤーを課し、むしろ非効率的な軽量のオプ ションを好む人が増えている。その必要性が無いのはデータベースがどのように作動するのかという事と無関係にし、またテーブルや行、そしてACIDプロパ ティの事を心配することよりも、どのようにデータを処理するかということに集中させてくれる。データと相互作用するコードの自動発生でコードと下部のレイ ヤーの生成においてたくさんの面白いことができる。またSonebraker氏に賛成している人々は下記のように主張している。

Sonebraker氏に賛成している人々（source）は下記のように主張している。

もしあなたがたくさんのデータを読んでいる場合はコラムストアはとても効率的だろう。（ロウストアよりも）しかし、もしあなたがデータを記述している場合ロウストアよりも費用がかかるのだ。
それゆえに自分のニーズに合わせてメソッドを選ぶべきなのだ。あなたは巨大なデータを保存しているだろうか？だとしたらコラムストアは適していないだろう。そのあなたのアプリケーションはロウストアのほうが効率よく作動する。なぜならロウストアへの記述はファイルにもう一つの記録を追加するというシンプルな作業であるからだ。その一方コラムストアへの記述はたくさんのファイルへの記録記述であることが多い。明らかにこちらのほうが労力がかかる。

一方、あなたは記述よりも遥かに読み出しが多い部分で比較的静的なデータセットを処理しているだろうか？そこでもしロウストアが一番の方法でないと思ったらコラムストアを試してみるべきである。ロウストアのクエリは全てのロウをクエリしなければならないということだ。それはあなたが戻りたい特定の分野を探している間に、まったくどうでも良いフィールドにぶち当たることがよくあるということだ。コラムストアを用いるとクエリに表されていないコラムを無視する ことができるのだ。更なることに、コラムストア内でデータが一様なので異なるデータタイプの処理が不必要になり、またデータブロックよりもむしろ分野によ る最も優れたデータを選ぶことができるのだ。
 どうしてみなワンサイズですべてに全てに対応すると主張するのだろうか？

この論争は始まったばかりのようだ。あなたはどう思うだろうか。

• 次へ >