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

Googleが発表した「Cloud Spanner」は、どのような仕組みでトランザクション処理の大規模分散処理を実現したのでしょうか？

[大越章司，ITmedia]

この記事は大越章司氏のブログ「Mostly Harmless」より転載、編集しています。

　2017年2月、Googleが新しいデータベースサービス「Cloud Spanner」を発表しました。

　Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。しかし、分散データベースには乗り越えられない「CAP定理」というのがあり、そんな理想的なDBは実現できないといわれてきました。Googleはどのような仕組みでこれを実現したのでしょうか。

Cloud Spannerの特徴（Google「Cloud Spanner」サイトより）

「間違ってはいけない」トランザクション処理

　トランザクション処理というのは、金融システムや生産管理などのミッションクリティカルな業務で必要となる処理で、「間違いや不整合が起こらない」ことが絶対の要件です。

　この目的のために使われてきたのが「リレーショナルデータベース（RDBMS）」です。汎用（はんよう）性が高く、開発しやすいので、数年前まではデータベースといえばRDBMS、といった状況が続いていました。

　こちらの記事に「SQLとNoSQLの“いいとこ取り”」とありますが、RDBMSで使われる開発言語がSQLのため、RDBMSの別名として、SQL DB、RDBMSではないデータベースをNoSQLと呼びます。

RDBMSでは扱いきれないデータの出現

　ネット上のデータが爆発的に増える中、画像や動画、音声など、RDBMSでは扱いにくいデータが増えてきました。

　RDBMSは会計データのような、数値や文字で桁数もある程度決まっているような「お行儀の良い」データを扱うのは得意ですが、大きさの予想がつかないようなデータは扱いにくい（扱えないわけではないが、効率が悪くなる）のです。

　加えて、大量のデータを扱うために処理能力を上げようとすると、大型のサーバを用意しなければならず、ハードウェアコストがかかりすぎるという面もあります。

トランザクション処理と大規模分散処理は両立しない

　処理能力を上げるための方法としては、前述の「大型のサーバにアップグレードする」方法（スケールアップ）と、「小型のサーバを大量に並べて分散処理する」方法（スケールアウト）がありますが、RDBMSは「スケールアウトしづらい」とされてきました。

　理由は、トランザクション処理では「間違ってはいけない」という目的を達成するために、ACIDという特性を備えることが求められるからです。

　RDBMSの進化の歴史は、ACIDを追究する歴史でもありました。ところがこのACIDを満足させるために、分散処理に制限が出てしまうのです。そのCAP定理は、分散型のデータベースでは、C（Consistency：一貫性）、A（Availability：可用性）、P（Partition-tolerance：ネットワーク分断への耐性）の3つを同時に保証することはできない、という定理です。トランザクション処理には、CとAを満たす必要がありますが、そうすると同時にPを満たすことができないため、ネットワーク上で分散させることができないのです。なお、この議論は単純化しすぎ、という指摘もあるようです。