夢のデータベース？ 「Cloud Spanner」の実力は？：Mostly Harmless（2/2 ページ）

[大越章司，ITmedia]

トランザクション処理（ACID）を諦めたNoSQL

　こういった背景から、Googleなどのインターネット企業は、RDBMS以外のデータベースを模索します。全世界のWebサイトをインデックスしなければならないGoogleは、世界で最も早くRDBMSの限界に向き合った企業の1つといえるでしょう。

　その中で開発されたのが「BigTable」などのデータベースで、RDBMSとは全く違ったデータ構造、仕組みを持ちます。これらは「RDBMSではない（＝SQLを使わない）」ことを示すために「NoSQL」という呼称で呼ばれるようになります。NoSQLは、ACID特性（CA）を諦めることによって、CPあるいはAPを実現し、分散処理を可能にしているといえます。

分散データベースなのに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％の可用性を持ってはいないのだから、障害が起きることを考えなくてもよいほどの高い可用性があればよい、と展開しています。しかし、そうなのでしょうか？　開き直りのような気もしますが。

　要は、「めったに落ちないから気にしなくてもいいんです。他のシステムだって、絶対に止まらないってことはないでしょ？」ということでしょうか。

　Cloud Spannerは、可用性の数値として、99.999％を挙げています。これはGoogleの他のサービスのSLAと同じですが、メインフレームの可用性って、確か99.9999％ですよね。9の数が1つ違います。99.9999％だと、年間の停止時間が32秒、99.999％だと5分15秒です。まあ、この可用性でも十分、という業務もあるのでしょうが、金融トランザクションにはまだまだ使えなさそうです。

　5月にはMicrosoftからも同様のサービスとして「Azure Cosmos DB」がローンチされています。こちらは「謎」と呼ばれていますね。

著者プロフィール：大越章司

外資系ソフトウェア／ハードウェアベンダーでマーケティングを経験。現在はIT企業向けのマーケティングコンサルタント。詳しいプロフィールはこちら。