【ODBMS の DB 業界ウオッチ】MIT Stonebraker 氏、In Memory OLTP を語る

今回、ODBMS.ORG の編集長である Roberto V. Zicari 氏は、MIT 教授で一連の起業家でもある Mike Stonebraker 氏にインタビューを行った。

「私は、『フリーサイズですべて間に合う』とは思わない。すなわち、あらゆる垂直市場には、レガシー リレーショナルデータベースを桁違いの力で打ち負かす方法がある」

以下はインタビューの一部を翻訳したものである。全文はこちら。オリジナルの記事は2012年5月2日に発表された。

Q1：これまであなたはいくつかのデータ管理システム、すなわち、「Ingres」リレーショナル DBMS、オブジェクト‐リレーショナル DBMS「PostgreSQL」、「Aurora Borealis」ストリーム処理エンジン（StreamBase として商用化された）、「C-Store」カラム指向 DBMS（Vertica として商用化された）、「H-Store」トランザクション処理エンジン（VoltDB として商用化された）を開発してきた。

振り返ってみたとき、これらのシステムの相違点と似ている点はつまるところ何か。それらの強みと弱みは何か。

それに追加すると、私は複雑な解析を志向する SciDB も構築している。私は、「フリーサイズですべて間に合う」とは思わない。すなわち、あらゆる垂直市場には、レガシー リレーショナルデータベースを桁違いの力で打ち負かす方法がある。使われる技法は市場によって異なる。この時点では、Postgres と Ingres はレガシーコードの土台だ。

Q2：2009年にあなたは、H-Store プロジェクトからのアイデアを基にしたスタートアップ企業、VoltDB を共同で設立している。H-Store は分散 In Memory OLTP システムだ。VoltDB のお勧めは何なのか。SAP HANA あるいは Oracle TimesTen などの他のインメモリデータベースと比べるとどうか。

われわれの多くが、『Through the OLTP Looking Glass and What We Found There』（SIGMOD 2008）という論文に書いているが、その中で、われわれは重要な OLTP オーバーヘッドの4つの源泉（同時発生制御、書き込み先行ログ、ラッチ/バッファプール管理）を確認した。これらの4つの源泉に大きな穴を開けなければ、現在のディスクベースの RDBMS より劇的に速く動作させることはできない。

私の知る限り、VoltDB はこれらの4つのオーバーヘッドコンポーネントをすべて、排除するか、徹底的に減少するシステムだ。たとえば、TimesTen は、型にはまったレコードレベルのロック、牡羊座風の書き込み先行ログと型に従来のマルチスレッドを使うので、かなりラッチが必要になる。それゆえ、4つの源泉のうち、たったひとつしか排除しない。