久しぶりにRDBMS技術的な記事でも。HerokuがDatabase-as-a-Serviceを開始したらしい。

HerokuがPostgreSQLのDatabase-as-a-Serviceを開始。しかし料金表がおかしいぞ

ただしHerokuは昔からPaaSの一環で、バックエンドPostgreSQLをサポートしているのでそれ自体は珍しいわけではない。専用メニューが開始された、ということにすぎない。PostgreSQLではないが、同様のサービスはAmazon RDCで前からMySQLやっているし、SQL Azureもある。

そういえばUmitanuki氏がHerokuオフィスに行ってPostgreSQLとpl/v8の話聞いて来たで遊びに行ったレポートを書いているが、そこの話とも矛盾しない。PostgreSQLは素のまま、管理運用に手を入れて、とにかく万人に扱いやすいシステムに仕上がっているようだ。統合制御のおかげで、実運用するためにはノウハウが大量に必要な高可用性部分など、まさにクラウドベンダーにはおいしいところである。

しかし、使いやすいだけが果たして論点で良いだろうか？例えばDropboxのような単純ストレージを提供しているベンダーは、Dedupを実装しており、見かけより小さなストレージしか用意せずに差額を稼ぐ、と言う手法を使っている。DBMSでは同様の手法はカラム指向データベースを使う方法がある。トランザクション性能こそ遅いが、カラム指向は圧縮しやすく、OLAPトランザクションの処理には通常の行指向RDBMSより優れている。

最近のDaaSを見る限り、かなりはっきりと3種類に指向がわかれてきている。

カラム指向＋キャッシュ

これはSalesforceとGoogle App Engineがやった方法。自社製のカラムナデータベースに強力なキャッシュエンジンを構築しOLTP性能を担保する。圧縮はうまくやれば強力に効くため（ただし、Salesforceが圧縮しているかは不明）、コスト面のメリットはHerokuのような既存RDBMSを使うタイプより大きい。しかし機能、性能特性等の差異は大きく、使いづらい。そして独自製品になるためベンダーロックイン問題が発生する。このくくりが最初に現れたのはとにかく性能に対するハードウェアの物量を最小化できたからである。

端的に言うと、DaaSとしては「効率が高いが不便」なタイプと言える。

既存RDBMS(orNoSQL)＋管理運用＋周辺ソフト(memcached等）

さっきのHerokuやAmazon RDSのやり方である。あくまでDBMSは既存のものを用意し、Dedupのようなハードウェアコストの削減はあまり意識せず、管理運用コストやノウハウの集約を目指す。巨大IaaSが普及し、クラウド基盤を利用できるようになったことが、この種の「汎用システムのクラウド化」が出来るようになった一番の理由だろう。

なにしろ既存のソリューションの延長線なので、ノウハウは利用できるしベンダーロックインの心配も少ない。無理な挑戦はできないが、する必要も無い。こちらは「効率は低いが便利」なタイプと言える。

これはアウトソーシングの亜流みたいなもので、技術的難易度は高くないゆえに、参入障壁も低い。今後どんどん増えてくるだろう。

既存RDBMSの皮を被った新型DBといういいとこどり

となると現れるのが「効率が高くて便利」なソリューションだが、可能性はある。既存RDBMSとの機能互換性を有しつつ、なおかつカラム指向＋キャッシュのような効率的なアーキテクチャをバックグラウンドにすれば、両方が実現出来る。こういう研究はL.starもいろいろやっていて何度かブログに書いた（実装はない）が、

FathomDB、「スケーラブルなRDBをDatabase-as-a-Serviceで提供する」と宣言

クラウド対応のスケーラブルなMySQLデータベース、米Xeroundが発表

などのような挑戦がすでに行われている。前者については情報がないがMySQLベースの仕事をしているらしいから、どっちも考えているのはMySQLのストレージエンジンだろう。もちろん中身は自動Sharding＋レプリケーションによる読み書き負荷分散だ。他に選択肢は無い。これは実際実装してみるといろいろ骨が折れる話で、一人で出来るようなものじゃなかった。Xeroundはよく動くまで持って行ったなと感心している。

その先

さてこの先であるが、微妙に揺り戻しが来ている感じである。1番目の初期DaaSはベンダーロックイン問題などで嫌われてきており、当面はPaaS向けの2番目が主流になり、3番目を実装したベンダーがコスト面で有利になっていくだろう、という形だろう。これに単純なコモディティ型ではないハードウェア、たとえばSSDと組み合わせた形などにより、

が、Oracleがどこにやってくるかが不気味である。たぶん3番目、あるいはその先を見越した開発をしているのではないかと想像している。逆に個々に食い込んで来れないと、レガシー化する恐れがある。いやOracleとしてはそっちのほうがありがたいのかも知れないが。

もうひとつ分からないのはVoltDBで、既存のSQLの致命的な欠点と言えるいくつかの点を改善している。DaaSにより、ディスクであるとか煩雑な運用であるとかはすでにやり玉に挙がったわけで、もしこれ以上改善しようとするとなると、いよいよ

SQL is obsolete.

What is the next to SQL?

とかで考察しているSQLの駄目な部分に食い込んでくるのか？という話になる。もちろんVoltDBがそのまま、ではないが。まあMapReduceとかがすでに挑戦している道であり、近いうちに（10年以内？）何らかの形で変化を見ることになるのではないかと思う。