ちょっと小旅行に出ている間にアクセスが伸びていて、おかげさまで前回のVoltDBのエントリが大人気だったようだ。まだまだ書き足りない部分がいっぱいあったので、補足する意味も込めて書き足してみたい。それは、H-Storeが従来型RDBMSとどれほど異なったシステムか、ということだ。インターフェースの話や大まかな話はしたが、前提となる部分の話はずいぶん抜けてしまっていた。
NoSQLを超えるSQLデータベース「VoltDB」。Cassnadraとベンチマーク対決！
で、実際にCassandraと比べて検討している
Key-Value Benchmarking
という記事が紹介されていて興味深い。で、なおかつ勝っていると言うから痛快だ。まあ個人的にはこの勝負は高々３ノードしか使っていない時点でスケーラビリティに勝るKVSにずいぶん不利な内容だな、と言わざるを得ない。せいぜい12ノードぐらいでしかテストされていないというVoltDBだから、30ノードならずっと違う結果が出るだろう。しかし、それでも勝ちは勝ちである。そもそも、ある程度のSQLを解するRDBMSなら、あげられた条件ではCassandraに肉薄すらできない。
何故ここまで勝てるのか？と言う話だが、逆に何故今までのDBは遅いのか、と言う話はすでに以下の論文にまとめられている。
http://cs-www.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf
ここでいにしえのSystem Rの以下のような部分に対して批判がされている。
- ディスク上に配置されることに最適化されたデータ構造
- （ディスクI/Oの）レイテンシの遅さを補うためのマルチスレッディング
- 同時実効性制御にロックを使うこと
- トランザクションログによるリカバリ
ではこれに対するVoltDBというかH-Storeの回答は何だろう？こうだ
- 最初からオンメモリを前提としたデータ構造
- ロックフリー化。（ストレージ部分のシングルスレッド実行）
- ロックを一切用いない追記とシングルスレッドによる同時実行制御
- UNDOログは追記で不要。REDOは関してはレプリケーションで代用（これは論文に書かれていないが、FAQからそう読める）
このうちいくつか、MVCCやロックフリー化（に近い削減）は、RDBMSの世界ですら珍しくないものだ。逆に無いものから考えると、引き算で答えが出る。
となると答えは簡単だ。オンメモリベースのDBでログを持たないから。
実験したことのある人は多いと思うが、普通のRDBMS,PostgreSQLやMySQLのデータをRAMDISK上においても、極端な性能向上は見られない。少なくとも昔はそうだった。それはロックが多すぎてボトルネックになってしまうからだ。
メモリDBというのは単なるRAMディスクにデータを全部おいたRDBMSではない。いわゆるRDBMSのアルゴリズムは全てディスクベースで構成されている。それはつまり、あらゆるデータはディスクから読み書きされることを前提としていて、メモリはキャッシュとしてしか利用しないと言うことだ。
キャッシュにしか使っていないから、データ構造は全てディスク上に配置されることに最適化されている。B-Treeなどその最たるものだ。オンメモリで良いなら赤黒木なりなんなりもっと楽なアルゴリズムがあるし、メモリポインタをそのまま使うことで一気に単純化可能で、いろんなボトルネックが解消できる。ロックも簡単である。
そして、RethinkDBのエントリでも書いたが、ログをまじめに書かなくていい前提ならディスクI/Oは最小である。となるとWALによるデータ保証をしているCassandraとでは圧倒的な差が出て当然である。
ちなみに、PostgreSQLのコアメンバでEnterpriseDBにいるDave Pageが
Comparing VoltDB to Postgres
でこのVoltDBについて、要を得た比較しているので参考になるだろう。Daveはいくつかの点で、VoltDBがPostgreSQLの代替として使えない、ということを指摘している。コメントで「それはアーキテクチャの問題ではなく機能不足」とされていた部分を除くと
- 限られた同時実行制御モデル
- 従来インターフェースとの互換性
- オンメモリDBであることによって、メモリ不足が深刻な問題になること。
と言ったことがあげられる。ただし、実はVoltDBにおいてはそんなことは設計の時点で折り込み済みである。先の論文で、なんのためにこんなシステムを実装しようとしたかの結論部分を引用しよう。
1. The predicted demise of “one size fits all”
2. The inappropriateness of current relational implementations for any segment of the market
3. The necessity of rethinking both data models and query languages for the specialized engines, which we expect to be dominant in the various vertical markets
そう、もう「1つのエンジンがあらゆるところに使い回される時代は終わった」と言っているのである。RDBMSはその点テクノロジー的な優等生を目指している。いやむしろRDBMSが標準に近いのではなく、標準がRDBMSを元に作られたとまで言ったほうがいいかもしれない。
車にたとえると、VoltDBはTPC-Cのようなトランザクション処理に特化したレースカーである。CassandraのようなKVSも、同様に又違う種類のトランザクションに特化したレースカーである。その点素のRDBMSはどこまで行ってもセダンだ。
だからVoltDBの数字に踊らされる前に、自分たちの使っているトランザクション特性をしかと考えてみてほしい。あなたのシステムが、メモリに収まらないほどのデータを扱わず、OLAP系の複雑なクエリなど知ったことではなく、でもOLTP性能がほしくて、RDBMS並に完璧なデータ完全性が必要ないならこいつは素晴らしいシステムだ。しかしどれかに当てはまらないならゴミだ。それだけのことである。
コメント