夢のDB? Cloud Spanner の実力とは
今年2月に、Googleが新しいデータベースサービスを発表しました。「Cloud Spanner」です。
Googleがグローバルな分散データベースCloud Spannerをローンチ、SQLとNoSQLの'良いとこ取り'を実装
Cloud Spannerの特長は、これまで不可能とされていた、「トランザクション処理の大規模分散処理」を実現したところにあります。しかし、分散データベースには乗り越えられない「CAP定理」というのがあり、こんな理想的なデータベースは実現できないと言われてきました。Googleはどのような仕組みでこれを実現したのでしょうか?
「間違ってはいけない」トランザクション処理
トランザクション処理というのは、金融システムや生産管理など、ミッションクリティカルな業務で必要となる処理で、「間違いや不整合が起こらない」ことが絶対の要件です。この目的のために使われてきたのが「リレーショナルデータベース (RDBMS)」です。汎用性が高く、開発もしやすいので、数年前まではデータベースと言えばRDBMS、といった状況が続いていました。上の記事に「SQLとNoSQL」とありますが、RDBMSで使われる開発言語がSQLのため、RDBMSの別名としてSQL DB、RDBMSでは無いデータベースをNoSQLと呼びます。(後述)
RDBMSでは扱いきれないデータの出現
しかし、ネット上のデータが爆発的に増える中で、画像や動画、音声など、RDBMSでは扱いにくいデータが増えてきました。RDBMSは会計データのような、数値や文字で桁数もある程度決まっているような「お行儀の良い」データを扱うのは得意ですが、大きさの予想が付かないようなデータは扱いにくい (扱えないわけでは無いが、効率が悪くなる) のです。加えて、大量のデータを扱うために処理能力を上げようとすると大型のサーバーを用意しなければならず、ハードウェアコストがかかりすぎるという面もあります。
トランザクション処理と大規模分散処理は両立しない
処理能力を上げるための方法としては、前述の「大型のサーバーにアップグレードする」という方法 (スケールアップ) と、「小型のサーバーを大量に並べて分散処理する」という方法 (スケールアウト) がありますが、RDBMSは「スケールアウトしづらい」とされてきました。理由は、トランザクション処理では「間違ってはいけない」という目的を達成するために、ACIDという特性を備えることが求められるからです。RDBMSの進化の歴史は、ACIDを追究する歴史でもありました。ところがこのACIDを満足させるために、分散処理に制限が出てしまうのです。CAP定理とは、分散型のデータベースにおいては C (一貫性)、A (可用性)、P (ネットワーク分断への耐性) の3つを同時に満たすことはできない、という定理です。トランザクション処理にはCとAを満たす必要がありますが、そうすると同時にPを満たすことはできないため、ネットワーク上で分散させることができないのです。(この議論は単純化しすぎ、という指摘もあるようですが)
トランザクション処理 (ACID) をあきらめたNoSQL
こういった背景から、Googleなどのインターネット企業はRDBMS以外のデータベースを模索します。全世界のWebサイトをインデックスしなければならないGoogleは、世界で最も早くRDBMSの限界に向き合った企業のひとつと言えるでしょう。その中で開発されたのがBigTableなどのデータベースで、RDBMSとは全く違ったデータ構造・仕組みを持ちます。これらは「RDBMSではない (=SQLを使わない)」ことを示すために「NoSQL」という呼称で呼ばれるようになります。NoSQLは、ACID特性(CA)を諦めることによって、CPあるいはAPを実現し、分散処理を可能にしていると言えます。
分散DBなのにACIDを実現できる?
ということで、要するにこれまで不可能と言われていたことを可能にしたのがCloud Spannerというわけです。最初の記事に「いいとこどり」と書いてあるのはそういうわけです。本当に動くなら、これは「夢のデータベース」といって良いと思います。しかし、何か落とし穴がありそうな気もしております。。話がうますぎますし。嘘では無いにせよ、いろいろ制限があるとか、これから出てくるかもしれません。
それを調べるために、仕組みがどうなっているのか調べようとしているのですが、これがなかなか難しいのです。いろいろと書いてくれている人はいるのですが、
うーん。難しい。。^^; 「SpannerはDatastoreに似ている」って、DatastoreってNoSQLですよね。あと、Paxosというのがキーワードのようですが、これも難しそうです。こちらの記事(Googleの論文の翻訳)によると、原子時計まで使っているようです。
Cloud Spannerの本質はCP型のNoSQLだった
こりゃ、お手上げだなあ。。と思っていたところ、本家GoogleのブログにCAP定理との関連で解説されていました。
Spanner はワイド エリアで扱えるものでありながら、一貫性と高可用性を両立するとありますが、CAP の観点から見ると、多くの人が意外に、あるいは疑わしいとさえ思うでしょう。これは議論すべき題材です。はたして Spanner は CAP で定義されているような CA システムなのだろうかと。端的に答えると、技術的には違いますが、実際のところ CA システムだと考えて構いません。
「技術的には違うが実際のところは」って何でしょうか ^^; よくわかりません。しかし、その後に、
分断が起きると Spanner は C を選択し、A を犠牲にします。つまり技術的に見ると、Spanner は CP システムなのです。
そういうことですか。やはり、CAP定理を乗り越えたわけではないのですね。Googleのブログではこの後で、どんなシステムも100%の可用性を持ってはいないのだから、障害が起きることを考えなくても良いほどの可用性があれば良いのだ、と展開しています。うーん。そうなのか? 開き直りのような気もしますが。
要は、「めったに落ちないから気にしなくてもいいんです。他のシステムだって、絶対に止まらないってことは無いでしょ?」ということでしょうか。
Spannerの可用性の数値として、99.999%という数値を挙げています。これはGoogleの他のサービスのSLAと同じですが、メインフレームの可用性って、確か99.9999%ですよね。9の数がひとつ違います。99.9999%だと年間の停止時間が32秒、99.999%だと5分15秒です。まあ、この可用性でも十分、という業務もあるのでしょうが、金融トランザクションにはまだまだ使えなさそうです。ちょっと羊頭狗肉っぽい感じです。
5月にはMicrosoftからも同様のサービスがローンチされています。こちらは「謎」と呼ばれちゃってますね。