最近また超並列DBのデザインを進めたりRethinkDBの話を書いてみたりとまたRDBMSづいているが、そんなことをしているうちに世の中では実際に並列DBが登場してしまった。
INGRES,POSTGRES,Illustra(と、誰も知らないMariposa)と、RDBMSの世界で革新的な仕事をしているMichael Stonebraker博士。最近何やっているのかと思ったらいつの間にやらH-Storeなる新型のストレージに携わっていて、それがいつの間にかSQL機能をもってVoltDBというプロダクトとしてやってきた。かれこれ40年近く業界の第一線にいることになる。
「NoSQL」を上回る性能を目指す次世代型高速SQLデータベース「VoltDB」登場
などという記事を見てびっくりした次第だ。NoSQL並の性能とRDBMS並のACID準拠、そしてSQL構文が使えるという、これまた夢のようなシステムである。
しかし、これがいわゆる狭義のRDBMSというか、我々が考えるOracleやMySQLのようなシステムを想像してとっかかると、全然違うものである。全くとんでもない代物である。
まず持ってH-Store自体、従来のRDBMSの持つ欠点というか、時代に即した設計に改めるためにかなりドラスティックな変革をしたシステムである。当然現物を見たことはなかったが、ここに来てVoltDBが出てきたことで拝めることになった。
それについては論文を見るのが早い。
HStore:A HighPerformance, Distributed Main Memory Transaction Processing System
こいつはOLTPに特化したシステムで、最初の記事で圧倒的に早いと言われていたのはおそらく論文にも出てくるTPC-Cである。主記憶を主に使うオンメモリDBに近いタイプだろうと推測する。書き込みの高速化はsharding、そしてレプリケーションを使うのは前回のエントリでも言ったとおり常套手段である。
ユニークなのはパーティショニングされているテーブルと、パーティショニングされていず、全部のサーバにレプリケートされている読み込み専用のテーブルの2種類があることだ。後者はマスタ等に利用する考えだろう。
そして独特なのが利用モデルで、VoltDBではテーブル、その設定、そしてJavaとSQLで書かれたストアドプロシージャを「ビルド」して「アプリケーション」を作る。つまり少なくとも現状では、データベースは静的なシステムであり、オンザフライでの頻繁な変更をあまり考慮していない。少なくともALTER TABLEはない。
また、トランザクションモデルは驚くほど異なっている。まずもって全てのトランザクションはストアドプロシージャとして登録されなければならず、インタラクティブなものは事実上ありえない点が新しい。そのため、JDBCやODBCのような汎用インターフェースをサポートしない(できない)VoltDBのFAQにもその旨が書かれている。なお、アドホックにSQLが書けないわけではない。しかし非推奨だ。
一応ソースコードも軽く眺めてみた。軽くなので正確なことは分からないが、エンジン部分はC++でかかれており、ここにストレージ用のコードやExecutorのコードがある。またフロントエンドはJavaで書かれていて、こっちにPlannerがあるのが興味深い。またMerge Joinなどの特殊なJOIN機構が無いのも興味深いが、これはOLTP用としては重要ではない判断だろうか。Java側には設定等のためかHSQLDBも入っている。実に興味深い。
これは実際、確かにSQLを受け付けるとはいえ、現実にはかなり異なったシステムだと言っていいだろう。スレッドモデルの考え方など、他にもずいぶん独特な部分がたくさんあるが、もう少しちゃんと読み込んでからそこは書いていきたい。しかしいえるのは、今までのやり方は通用しないと言うことだ。それは悪いことに見えるかもしれないが、代償として得られる性能は圧倒的であることは強調しておきたい。SQL実装の扱いやすいが性能に差し障る部分が削られていることが、性能を印象的なものにしている。
BigTableあたりから始まって、データストアの性能改善の動きが激しく、まだしばらくは続きそうだ。一段落したときにどんなシステムが勝ち残るか、いったいどれだけのことができるようになっているか、そしてユーザはどのようにその恩恵を受けられるのか?いろいろ興味深い種は尽きない。その中でL.starはどういう役割を果たすべきか?ちゃんと考えておかないとなぁ。