先月、GoogleはSpannerの詳細をリリースした。これは高度にスケーラブルで、地球規模でレプリカできるセミ－リレーショナルなデータベースでOperating System Design and Implementation(OSDI '12)カンファレンスで公開された。先週、Wilson Hsieh氏によるOSDI 2012におけるプレゼンのビデオ記録を追加した。氏は論文の共同著者であり、論文の中で幾つかの重要な概念に焦点を当てている。InfoQの Alex Popescuは、Berlin Buzzwordsにおける Alex Lloyd氏のもっと詳細な講演をポストした。その研究が証明したのは、ACIDセマンティクスは、より大規模になっても犠牲になる必要はなく、その結果、NoSQLが高度にスケーラブルな永続化の解決策である、と信念を否定した、ことである。
我々が信じるのは、トランザクションの使い過ぎでボトルネックが発生した時に、アプリケーションプログラマにパフォーマンス問題を処理させるほうが、いつもトランザクションが欠如している周りでコーディングするよりもマシである、ということです。
Spannerプロジェクトは、Google AdWordsシステムに対する極めてリレーショナルかつトランザクションの多い、しかし地球規模の永続化ソリューションの必要性に由来している。MegaStoreは部分的にこれらの懸念に対して応えている。なぜならその一貫性の保証は、大陸規模のトランザクションに対して予想通りの大きな遅延なしには、達成できなかったからである。Spannerでは、分散トランザクションの遅延問題は、Googleが TrueTime APIと呼ぶものを通して処理される。これは基本的にクロック不確実性問題に対するソリューションである。
クロック不確実性（論文ではεで示された）は、広域のネットワークにおいて様々な時刻マスターリファレンスがクロック時間を決める時にクロックのドリフトとネットワークの遅延によって生じるものである。時刻マスターリファレンスは、GPS時間マスターと原子時計が混在しており、それらのエラー率は、冗長化によって小さくしている。 クロック不確実性とコミット待機間隔（2倍のε）の上限に寄与する要因を決定することによって、外部の一貫性の保証は、他の利点、例えばロック無しのリードトランザクション、非ブロッキングリード、そしてアトミックなスキーマ変更などと合わせて達成された。コミット待機間隔が直接 クロック不確実性に結びついているので、クロック不確実性が大きければ、コミット待機間隔が長くなり、 Spannerを遅くすることになる。しかし、より長いコミット待機間隔（典型的には10msだがロングテール分布である）によるこの遅延効果を小さくするために、Spanner はPaxos（コンセンサスプロトコル）の準備フェーズあるいは、待機中に2フェーズコミットを実行する。
Spanner のデータモデルは、 Megastoreに似たセミリレーショナルで、階層的に構造化されたモデルである。 O'ReillyのTimothy O'Brien氏が彼のブログで Spannerのデプロイを要約している。
クロック不確実性（論文ではεで示された）は、広域のネットワークにおいて様々な時刻マスターリファレンスがクロック時間を決める時にクロックのドリフトとネットワークの遅延によって生じるものである。時刻マスターリファレンスは、GPS時間マスターと原子時計が混在しており、それらのエラー率は、冗長化によって小さくしている。 クロック不確実性とコミット待機間隔（2倍のε）の上限に寄与する要因を決定することによって、外部の一貫性の保証は、他の利点、例えばロック無しのリードトランザクション、非ブロッキングリード、そしてアトミックなスキーマ変更などと合わせて達成された。コミット待機間隔が直接 クロック不確実性に結びついているので、クロック不確実性が大きければ、コミット待機間隔が長くなり、 Spannerを遅くすることになる。しかし、より長いコミット待機間隔（典型的には10msだがロングテール分布である）によるこの遅延効果を小さくするために、Spanner はPaxos（コンセンサスプロトコル）の準備フェーズあるいは、待機中に2フェーズコミットを実行する。
Spanner のデータモデルは、 Megastoreに似たセミリレーショナルで、階層的に構造化されたモデルである。 O'ReillyのTimothy O'Brien氏が彼のブログで Spannerのデプロイを要約している。
Spannerの配置は、データセンターを跨いだ複数の「ゾーン」を管理する2,3の管理サーバーから成る。「ゾーンマスター」と一組の「ロケーションプロキシ」が Spannerデータベースにおける大部分の仕事を実行する何百、何千の「spanサーバー」を管理する。 spanサーバーは、「ディレクトリ」と呼ばれるデータ群を格納し、これらのデータ群のそれぞれがタブレットと呼ばれるものの上に Paxosステートマシンを実装している。spanサーバーは、複合キーを使ってタイムスタンプと値と一緒にBツリーでデータを格納しているCloudant Labsは、彼らのブログ記事でSpannerに欠けている2つの領域を指摘している。
特に、 Spannerは未だ、二次インデックスの自動処理をサポートしていない。更に遅れた調停による（ CouchDB流）「オフライン」アクセスをサポートしていない。
Googleが言うには、 Spannerは最初の地球規模で複製ができ、スケーラブルな、ACIDデータベースであり、一方 NuoDBもまた特許を取得した彼らのソリューションである。その特許明細書によると同じことを達成するように見える。このことがあなたの製品／プロジェクト実装のための、NoSQL対NewSQLをめぐる議論をどのように変えるか？