SQL vs NoSQL、グーグルにおける戦い（前編）。Google I/O 2012

SQLとNoSQLではどちらが優れているのか？ グーグルの担当者がディベート（というより小芝居：-）を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。

このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。

ハイライトを紹介しましょう。

クラウドにおけるデータベースのメリット

グーグルのAlfred Fuller氏（NoSQL担当）。

クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。

データのレプリケーションや地域分散でデータも保全され、インターネット経由のアクセスも確保している。

Google App Engineは、開発が容易でスケーラブル、メンテナンス不要のアプリケーションプラットフォームだ。App Engineからは、リレーショナルデータベースの「Cloud SQL」、NoSQLの「Datastore」、そしてオブジェクトストレージの「CloudStorage」にアクセスできる。

DatastoreはGmailやGoogle Docsと同じテクノロジー

Datastoreは、GmailやGoogle Docsと同じテクノロジーで構築されたストレージであり、月間3兆回ものオペレーションが行われている。すべてが管理されたNoSQLソリューションだ。

一方、Cloud SQLもすべてが管理され、ピュアなMySQLデータベース互換のデータベースだ。

Ken Ashcraft氏（SQL担当）が壇上に登場。左がKen氏、右がAlfred氏。

遅れてゴメン。そこで開発者に捕まってたんだ。彼らはCloud SQLのすごさに興奮しててさ、これが本当のデータベースだよって、もうNoSQLみたいなくだらないものは使わなくて済むって言ってて。

もちろんCloud SQLならNoSQLでできることは全部うまく処理できるしね。

（NoSQL担当）いや、そんなことはないよ。

（SQL担当）いやいや、できるって！

クエリ機能の比較

（SQL担当）クエリ機能から見ていこう。Cloud SQLは国際標準のSQLをサポートしている。

（NoSQL担当）NoSQLもSQLのサブセットをサポートしているさ。しかも、SQLにはないようなContainsやAnyをサポートしているし、データが増えても性能劣化の心配がないスケーラビリティを備えている。

（SQL担当）Cloud SQLは、SQLをフルサポートしているし、例えばグループバイで街ごとの平均年齢を集計したりできる。

（NoSQL担当）集計ならMapReduceフレームワークでできるさ。Mapで値を取り出し、Shuffleで街ごとに分けて、Reduceで計算すればいい。マテリアライズドビューを使えば、データが変わるたびに再計算もできる。

（SQL担当）どちらもできるけれど、この勝負はSQLの勝ちだな。スコアボードを付けていこう。

トランザクション機能の比較

（SQL担当）多くのNoSQLがトランザクションをサポートしていないよね。サポートしていても1行だけに限ったトランザクションで、本物のトランザクションじゃない。

（NoSQL担当）Datastoreは本物のトランザクションをサポートしているさ。「Entityグループ」という行をまたがったトランザクションもある。

例えば、ゲームのプレイヤーがポーション（聖水）を飲んでヘルスを回復し、ポーションが削除される、という動作は、「db.transactional」を使って1つのトランザクションとして記述できる。

（SQL担当）なるほど。でもプレイヤーをまたいだトランザクションはできるのかい？ わはは！ （できっこないだろ！）

（NoSQL担当）いやいやできるさ。Cross-Entityグループトランザクションがある。

あるプレイヤーが別のプレイヤーにポーションを売るとしよう。xgをtrueにセットする。あとはさっきと同じようにロジックを書いていけばいい。複数のプレイヤーにまたがったこの処理はアトミックに行われる。

（SQL担当）もちろんトランザクションはSQLでも記述できる。start Transcation; commit;のあいだに書けばいい。

トランザクションやロックを使うケースでは、Cloud SQLのほうがよりうまく処理できるといえるね。

ところで、DatastoreはBigTableの上に構築されているよね。データセンターのレプリケーションが壊れたらどうなるんだろう？ BigTableって、誰もよく分かってないような、ヘンテコな結果整合性のレプリケーションを使っているそうじゃないか。

データ整合性（コンシステンシ）機能について

（NoSQL担当）確かにDatastoreはMegastoreレプリケーションを使っている。ただしMegastoreレプリケーションは、さっき説明したEntityグループを使っていて、トランザクションを用いてレプリケーションをしていて一貫性に矛盾はない。

レプリカにはマスターはないけれど、Entityグループの最新データを取得する方法などを提供している。

（NoSQL担当）ところでレプリケーションといえば、MySQLはシングルマスター方式で強力な一貫性を提供しているらしいけれど、非同期のレプリケーションでマスターに更新キューがたくさんたまっている状態でマスターがクラッシュしたらどうなるんだい？

（SQL担当）いやいや、Cloud SQLには同期レプリケーションがあるのさ。

データセンターAでMySQLが稼働しており、クライアントからリクエストを受ける。このときクライアントに返答する前に、同期的にほかのデータセンターにレプリケーションを行ってからクライアントに返答する。

これでデータを失うことなくレプリケーションされるため、データセンターAがダウンしたとしても何の問題もなくマスターをデータセンターBへ移行できる。

（SQL担当）三連勝か。このまま楽勝だな。

（NoSQL担当）まだ終わっちゃいないさ。次はスケーラビリティの話をしようぜ！

≫ここからNoSQLの反撃が始まります。続きは「SQL vs NoSQL、グーグルにおける戦い（後編）。Google I/O 2012」へ