大規模分散システムの現在 -- gfs, mapreduce, bigtableはどう変化したか？
TRANSCRIPT
大規模分散システムの現在GFS, MapReduce, BigTable はどう進化したか
@maruyama097
丸山不二夫
Agenda
大規模分散システムの成立 すべては、ここから始まった
GFS, MapReduce, BigTable GFS から GFS2 へ Caffeine 新しい検索システム Dremel インタラクティブなデータ分析 Spanner 新しい分散データベース Knowledge Graph 新しい検索技術 資料編
大規模分散システムの成立
21世紀の初頭、かってない巨大な規模の分散システムがネットワーク上で稼働を始めた。現在の IT を領導しているのは、こうした大規模分散システムを所有し、その上でサービスを提供している Google, Amazon, Apple, Facebook といった企業達である。
Amazon
Apple
Microsoft
GoogleGoogle
Microsoft
クラウドとクラウド・デバイスの時代 クラウドの時代は、 21 世紀になってから本
格的に始動した。すぐ後を追って、クラウド・デバイスの時代が始まった。 2004 年 Google 上場 2004 年 Google GFS,MapReduce,BigTable
の論文公表 2006 年 Amazon EC2, S3 2007 年 Apple iPhone 2008 年 Microsoft Azure 2008 年 Google Android 2012 年 Facebook 上場
Google の社是とスタンス 全世界の情報を、組織し、アクセス可能にす
るという夢は、ほとんど達成可能なところにまで来ている !
“ 我々は、検索を人々の役に立つようにするというビジネスをしている。インフラを売るビジネスをしている訳ではない。”
--- Lipkovitz, Google
Facebook の社是とスタンス Facebook は、本来、会社となるために作ら
れたものではなかった。それは、次のような社会的使命を達成するために作られた。世界を、もっとオープンで、つながったものに！
このテクノロジーと、構築されるべきインフラの規模は、前例のないものです。私たちは、これこそが私たちが集中することの出来る、もっとも重要な問題だと確信しています。
-- 「 Facebook 上場申請文書」
現代の大規模分散システムがハンドルするデータの規模
Google の検索エンジンが処理するデータの量 Google の検索システム Caffeine が、一秒間
に処理するデータの量は、紙に印刷すると、3 マイル（ 4.8km ）の高さになる
A4 の用紙に 2KB の情報が入るとして、紙の厚さを 0.2mm とすれば、情報の量は、 2KB x 4.8km x 5 = 48 x KB x K x K = 48GB
Google の検索システムで使われているストレージの情報を、 iPad に入れようとすれば、625,000 個の iPad が必要になる。この iPadを積み上げれば、 40 マイル (72Km) 以上になる
64GB x 625,000 = 40,000GB x K = ４ 0PB
毎月のアクティブ・ユーザ 8 億 4500万人
一日の投稿 25 億 一日の「いいね」 27 億 一日にアップロードされる写真 3 億枚 Facebook 上の友人関係 1000 億 30 分ごとに 105TB のデータがスキャンされ
る。
Big Data は、大きいか小さいか？ 1K 1,000 人 千人 1M 1,000,000 人 百万人 1G 1,000,000,000 人 十億人 世界人口 ７ G 人 世界の一人一人に、 2 バイトコード
で、 1000 字程度の個人情報のプロファイルを与えるとすると、2 x 8 x 1K x 7G = 2 x 7TB のディスクがあればいい。
日本人一億人なら、 200GB で十分。今なら2T のディスクが、秋葉原で一万円で買える。
Windows Azure SQL データベースの最大容量は、 150G
Amazon DB インスタンス
なぜ、大規模分散システムに注目する必要があるのか？
なぜ、大規模分散システムに注目する必要があるのか？ 大規模分散システムが取り組んでいるのは、
Web 上のネットワーク・メディアの発展によって、止まることなく増え続けるアクセスと情報の増大の中で、リアルタイム性を追求するという、現代の IT 技術のもっとも重要な課題である。
大規模分散システムは、新しいネットワーク・マーケットの台頭の中で、大規模の情報をハンドルしながらリアルタイム性を志向し、同時に、正確なトランザクションを担保することを求められている。これらの課題は、技術的に挑戦的なものである。
なぜ、大規模分散システムに注目する必要があるのか？ 重要なことは、こうした技術的な探求が、新
しいサービスの開発をめぐる、ビジネスの競争によってドライブされていることである。
サービス利用者から見て” Public クラウド”と言われるものは、ビジネスの主体からみれば、Google 、 Amazon 、 Microsoft... らが「所有」する” Private クラウド”であると考えることも出来る。
彼らのビジネスの力の一つは、大規模分散システムを開発し運用し、新しいサービスを提供し続ける技術的な力にある。
なぜ、大規模分散システムに注目する必要があるのか？ また、現代の IT ビジネスの競争力の中核の一
つは、大規模分散システムでのみ提供可能なサービスにある。検索サービス、エンタープライズ向けクラウド・サービス、ソーシャル・ネットワーク・サービスは、その代表的なものである。
ただ、現在の大規模分散システムは、その力を全面的に開花させている訳ではない。それは発展途上にある。また、それによって提供可能な新しいサービスも、今後、続々と登場してくるであろう。そこには、ビジネス的にも、もっと大きな可能性がある。
なぜ、大規模分散システムに注目する必要があるのか？ 一般の企業・一般の開発者にとっても、こう
した技術は無縁ではない。それが現代の技術とビジネスの課題を反映したものである以上、そこから派生した技術は、遅かれ早かれ、時代の IT 技術に深い影響を与えていくだろうから。
Google の大規模分散技術
21 世紀のクラウドとクラウド・デバイスの時代を牽引してきたのは Google である。 Google は、大規模分散処理のシステム技術においてもいまだ卓越した地位を占めている。彼らは、処理のリアルタイム化・正確なトランザクションの実現にむけて、そのインフラ技術の見直しをすすめている。
すべては、ここから始まった
2003 年 The Google File System 2004 年 MapReduce 2006 年 BigTable
The Google File System
http://209.85.163.132/papers/gfs-sosp2003.pdf
GFS は、安価な PC サーバからなるクラスタ上に構築された分散ファイルシステムである。クラスタは、 2,000台以上の chunkserver からなり、 Google には、 30 以上の Cluster がある。GFS は、ペタバイトサイズのファイルシステムであり、 read/write 2,000MB/s 以上の性能がある
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
The Google File System
Gobioff氏は、 2008 年 3 月 11 日、悪性リンパ腫で亡くなった。
GFS chunkserver
Linux File System
GFS chunkserver
Linux File System
Application
GFS Client
GFS Architecture
Chunk 2ef0
GFS Master
File NameSpace
/foo/bar(file name,chunk index)
(chunk handle, chunk location)
(chunk handle,byte range)
chunk data
Instruction to chunkserver
Chunkserver state
・・・・・・・・
・・・・
MapReduce: Simplified Data Processing on Large Clusters
MapReduce は、関数型のプログラミング・モデルに基づいた、大規模なデータ・セットの処理・生成を行う
http://209.85.163.132/papers/mapreduce-osdi04.pdf
MapReduce: Simplied Data Processing on Large Clusters
Jeffrey Dean and Sanjay Ghemawat
Split 0
Split 1
Split 2
Split 3
Split 4
Worker
Worker
Worker
Partition0Partition1
Partition0Partition1
Partition0Partition1
Worker
Worker
Outputfile0
Outputfile1
Master
入力ファイルとその分割
Map のフェーズ
Local Disk 上の中間出力ファイル
Reduce のフェーズ
最終出力ファイル
Bigtable: A Distributed Storage System for Structured Data
Bigtable は、数千台のサーバ上のペタバイト単位の非常に大きなサイズにまでスケールするようにデザインされた、構造化されたデータを管理する、分散ストレージ・システムである。http://209.85.163.132/papers/bigtable-osdi06.pdfhttp://video.google.com/videoplay?docid=7278544055668715642&q=bigtable
Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber
Bigtable: A Distributed Storage System for Structured Data
BigTable システム構成
Bigtable セル
メタデータのオペレーションを実行ロードバランシング
BigtableTablet Serverサーバデータ
フェイルオーバのハンドリングモニタリング
タブレットデータの保持 ログ
メタデータ保持、マスター選定のハンドリング
BigtableTablet Serverサーバデータ
BigtableTablet Serverサーバデータ
Bigtable Master
ClusterShedulingSystem
GoogleFile
System
ChubbyLock
Service
Bigtable Client
Bigtable ClientLibrary
Open
GFS から GFS2 へ
2009 年、 Google は GFS のデザインの見直しを示唆。バッチ・システムの効率を上げる為にデザインされた、シングル・マスターの GFS は、分散マルチ・マスターのシステムに変わる。同時期に開発が始まった Megastore は、現在の Google のサービスの主力になる。
2009 年７月、 Google 大規模障害
2009 年７月、 Google 大規模障害 2009 年 7 月 2 日 , 6:45 AM から 12:35 PM
まで、 Google App Engine に大規模な障害発生。
この障害の根本的な原因は、データセンタ内のノードが、サーバー側できちんとしたチェックを行わずに、不適切に構成されたFileHandle を送りつけたことに起因するGFS Master server のバグであった。これを処理しようとして、 Master は、スタック・オーバーフローを起こした。
Transactions Across Datacenters （ Weekend Project ） この障害事故の少し前、 2009 年 5 月 27 日
Google IO で、 Ryan Barrett は、自らのWeekend Project として、データセンターをまたいだシステムを提案していた。
http://www.google.com/intl/ja/events/io/2009/sessions/TransactionsAcrossDatacenters.html
what if your entire datacenter falls off the face of the earth? This talk will examine how current large scale storage systems handle fault tolerance and consistency, with a particular focus on the App Engine datastore. We'll cover techniques such as replication, sharding, two phase commit, and consensus protocols (e.g. Paxos), then explore how they can be applied across datacenters.
Post-mortem for February 24th, 2010 outage After further analysis, we determine that
although power has returned to the datacenter, many machines in the datacenter are missing due to the power outage, and are not able to serve traffic.
Particularly, it is determined that the GFS and Bigtable clusters are not in a functioning state due to having lost too many machines, andthat thus the Datastore is not usable in the primary datacenter at that time.
2009 年 9 月、 Bigtable の見直し 2009 年 9 月 14 日、 Ryan Barrett は、“
Migration to a Better Datastore”を発表 http://googleappengine.blogspot.jp/2009/09/migration-to-better-datastore.html
Megastore replication saves the day!Megastore is an internal library on top of Bigtable that supports declarative schemas, multi-row transactions, secondary indices, and recently, consistent replication across datacenters.
2011 年 1 月Megastore: Providing Scalable, Highly Available Storage for Interactive Services
http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf
cf. 日本 2012 年 6 月 20 日 ファースト・サーバー社事故
Megastore
MegaStore
Megastore を利用したよく知られた Googleのアプリには、次のものがある。
Gmail Picasa Calendar Android Market AppEngine
HDFS の Avatar Node
ちなみに、 Facebook が、 HDFS の Master Node の二重化、いわゆ、 Avatar Node の実装の次の論文を発表したのは、 2011 年のSIGMOD でのことであった。
“Apache Hadoop goes Realtime at Facebook”http://dl.acm.org/citation.cfm?id=1989438&bnc=1
GFS: Evolution on Fast-forward
事故直後の 2009 年８月 1 日、 Sean Quinlan は、 ACM とのインタビューに応え、 GFS のデザインの見直しを示唆。
http://queue.acm.org/detail.cfm?id=1594206
GFS: Evolution on Fast-forward
GFS の単一マスターで行くという決定は、実際には、設計の非常に早い段階でなされたものだ。主要には、デザインをシンプルなものにするというのが、その理由だ。
ただ、問題は、すぐに起きていた。ストレージの容量が、数百テラからペタバイトに、さらには数十ペタに増大するにつれて、マスターが維持しなければならないメタデータの割合は、増えていった。
GFS: Evolution on Fast-forward
同様に、データのボリュームとともに、リカバリーのデータを探す為にメタデータをスキャンするというような操作がリニアなスケールで増えていく。こうして、マスターに要求される仕事の量は、本質的に増大する。
GFS: Evolution on Fast-forward
GFS が、いまや、多くの挑戦にさらされているのは、疑問の余地はない。一例を挙げれば、不断に増大するユーザーの大群と直面していて遅延が大きな問題となるアプリケーションを、本来は、バッチ・システムの効率を上げる為にデザインされたシステムの上でサポートしていることの、不格好さは、誰の目にも明らかである。
GFS: Evolution on Fast-forward
BigTable の登場は、この点では、いくらかの助けにはなった。ただ、明らかになったのは、BigTable は、実際には、 GFS とは、最良の組み合わせではなかったということだ。事実、この組み合わせは、 GFS システムの単一マスターのデザインのボトルネックとしての限界を、他の場合よりも、はるかに明らかなものとしただけだった。
GFS: Evolution on Fast-forward
これした理由から、 Google の技術者達は、過去 2 年間というもの、 BigTable の利点を最大限生かしながら、現 GFS に取っては特に困難であると証明されているいくつかの問題を攻略する、新しい分散マスターシステムのデザインに取り組んできた。
問題 マスターは、秒あたり数千の処理しか終える
ことが出来ない。
MapReduce は、かなりの数のファイルをオープンしようとする、千ものタスクを走らせるかもしれない。
現在の実装 Cell あたり一つのマスター 歴史的には、データセンターに一つの Cell と
いうのが目標だったが、結局、 multi-cell アプローチをとった。
データセンターに複数の Cell がある。ネットワークをまたいで、複数の Cell は、関連づけられた、ただし異なったファイルシステムとして機能する。
現在の実装 複数の GFS マスター chunk サーバー群の上に、複数の GFS サー
バーを置く。 配下のストレージ・プールが、複数の GFS マ
スターを持つように設定出来る。 異なった Cell をまたいだデータの分割には、
アプリケーションが責任を持つ。
現在の実装Name Space
それぞれのアプリケーションが、マスターを持つとしよう。（一つか、少数のマスターを）
Name Space が、これらを全てをアプリケーションから隠す。 namespace を分割する静的な方法
ログ処理システムでは、いったん一つの Cellのログを使い果たすと、複数の GFS Cell に移動する。
Namespace ファイルは、ログ・データが、異なる Cell をまたがって分割されているかを記述する。
現在の実装マスターのパフォーマンスチューニング 最終的には、マスターのパフォーマンスのチューニングにかなりの努力をした。特定のバイナリーのチューニングに多くの力を注ぎ込むのは、 Google では、あまりないことである。
一般的に、我々のアプローチは、ほどほどに動くようになったら、スケールさせることにフォーカスするというものだ。これはたいていはうまく機能して、一般的には、スケールさせることでパフォーマンスが得られる。
この例の場合には、インパクトを持ち始めた一つのボトルネックがあったわけだが、我々は、マスターの負荷を軽くすることに、更に努力することが価値があると感じていた。
数千の処理から、数万の処理にスケールした時点で、マスターは、ボトルネックになった。
ふりかえり GFS は、記録的な短期間で製品化された。 3
人のチームが、一年足らずで配備にまでこぎ着けた。 GFS が稼働している最大級のファイル・システムであることを想起してほしい。
開発スピードの優位性は、 Google に、巨大な成長を可能にした。
GFS の機能を最初に利用したのは、 大規模なクローリングと index システムだった。
GFS の利用の第二の波は、大規模なデータを格納することだった。 GFS は、この新しいユースケースにも適応出来るように調整された。
様々なアプリケーションが、 GFS をイメージして開発されるようになった。
Additional problems
急速な成長の中で、 64MB のチャンク・サイズが問題になった。 Google が扱うデータが巨大な為になされたものであったが、Ｇmａｉｌのように、多くのファイルは、 64MB以下で十分だった。
ファイル数のカウントは、また、別の問題になった。ログの数が増え続けた。フロントエンドのサーバーはログを書き出すのだが、それがクラッシュすると、更に大量のログを吐き出す。それは、想定よりはるかに大きなデータだった。
Additional Improvements
ファイル数の増大が問題だった。マスターのメモリーが枯渇する前に、調整可能なのは、高々限られた数のファイルだ。
それぞれのファイルについて、メモリーに格納されるメタデータが必要になった。ファイル名とチャンクの情報。
もし、平均的なファイルサイズが、６４ MB以下であれば、ストレージに対するマスター上のオブジェクトの数の比率は低下する。
この問題に対応する為に、オブジェクトを大きなファイルにまとめ、その内容のテーブルを作った。
また、ファイル数とストレージの容量にquota をかけた。大体、引っかかるのはファイル数の quota の方だった。
Additional Improvements
全面的に新しいデザインの作業を始める。 分散マルチ・マスター・モデル。 1MB の新しいファイルサイズ。
ファイル数問題への対応 一万個の 10KB のファイルを読む方が、 100 個
の 1MB のファイルを読むより、シークに時間がかかる。
一つのマスターに 100M 個のファイル。数百のマスターという構成。
BigTable 構造化されたデータの分散ストレージ ファイル数の増大に対する対応策–小さなものを集約
する 数千台のマシンをまたぎ、ペタバイトまでスケールす
る。 GFS 上に構築され、 GFS 上で稼働し、 GFS の原理と矛盾がないように設計された。
アプリケーションにも見られるが、実際には、インフラの一部 システムのエラーに非常に敏感に対応 クローリングと index システムに利用された 沢山の小規模なデータを利用するアプリ
は、 BigTable を使う BigTable は、単にファイル数問題を扱うために設計されたものではない。それ以上の意図があった
BigTable
もともとのアイデアは、 SSTable とログ、たった二つだけの基本構造を持つというものだった。 SSTables– Stored String Tables (key-value pair)
BigTable は、 mutable なログと、データを圧縮した immutable な SSTable の上に構築された。
GFS には、どんなデータでも書き込みが出来る。しかし、大部分のユーザーは、結局、 BigTable の二つのデータ構造、 SSTable とログを使うようになった。
More initial GFS limitations/improvements
初期の GFS は、低い遅延の上に、高帯域（高スループット）を実現するようにデザインされていた。
バッチのアプリケーションでは、 Single point of failure も許される。
ただ、ビデオのサービスでは、そうはいかない。
GFS では三重化されたファイルに書き出すのだが、もし、 chunkserver が死んだり、調子が悪くなると、一つの chunk のレプリカを作る。この作業に 10 秒から一分かかる。
大規模な MapReduce の処理ならそれでもいいが、 Gmail では、一分の遅れは受け入れられない。
初期のマスターのフェイル・オーバーには、数分かかっていたが、今では、それは数十秒に短縮された。
More initial GFS limitations/improvements
MapReduce ベースの世界から、 BigTableのようなものに依存したインタラクティブな世界に移行すること。
バッチ志向の処理用にデザインされたファイルシステムの上に、インタラクティブな DBを構築することは、挑戦的な課題だ。
Bigtable – トランザクション・ログがボトルネック。 二つのログファイルを同時に開いて、一つに書き込む。それがいっぱいになったら、もう一つに書き出し、最後にマージする。
Gmail は、マルチ・ホーム Gmail アカウントの一つのインスタンスが不調に
なったら、他のデータセンターに移る。（これは、可用性を高めるのを助ける）
Compatibility issues: ドライバーとドライブのミスマッチが、デー
タ破壊を引き起こした（全ての IDE プロトコルのバージョンをサポートしていなかった） 厳格なチェックサムの実行が必要 でも、少しデータの読み込みが遅れるのは OK で
ある これらの対策は、マスターに新しいデータを
追加して、もっと沢山の状態を管理することで可能になった。
Consistency Issues
あるファイルを複数回読むと、異なるデータが返ることがある。
GFS は、全てのデータが全てのレプリカに書き出されないと、次に進まない。問題は、クライアントがクラッシュした時に起きる。
Consistency Issues
RecordAppend 複数のライターがログに追加出来る。ゆるい整合性。 全てのレプリカが書き込まれたという保証がない。
データは、チャンクに一度以上、違った順序で、違ったチャンクに書き込まれうる。等々。
問題があれば、新しいプライマリーが新しいオフセットを取り出す。 ファイルを指定出来ない ゆるい整合性は、価値があるというより苦痛にな
る ファイルあたり単一の書き込み、順番付けされた
書き込みが、整合性の為には必要である。
Initial GFS aspect that still works Snapshot of chunk レプリカを置き換える
クライアントが書き込めないロックを取り消す GFS は、 snapshot機能もサポートしている – clone 非常に強力なのに、広くは利用されていない 実装が難しい。ただ、本当の snapshot として、実装を試みた。
結論 GFS の成績表は、 10 年経った今でも、ポジ
ティブである。 成功によってではなく、まだ力を発揮してい
るという点で。 スケールもアプリケーションも、 1990 年代
後半の想像をはるかに超えている。
チャレンジなのは、ユーザーを前にした、遅延に敏感なアプリケーションを、バッチのスループットの為にデザインされたシステムの上でサポートすること。
BigTable は助けになった。しかしそれは、GFS とぴったりあっていた訳ではない。むしろそれは、ボトルネックの限界を、明らかにした。
BigTable の利点を最大限生かした、分散マスターのシステムをデザインすること。
Caffeine Google の新しい検索システム
2010 年 6 月、 Google は新しい検索システム Caffeine を稼働。 MapReduce の利用を廃して、 BigTable 上でリアルタイムにインデックス付けを行う方式に移行。あわせて、 BigTable のトランザクション処理に大幅な改良を加える。
Our new search index: Caffeine
2010 年 6 月 8 日Google Webmaster Central Bloghttp://googlewebmastercentral.blogspot.jp/2010/06/our-new-search-index-caffeine.html
本日、 Caffeine と呼ばれる新しい Web インデキシング・システムが完成したことを報告します。 Caffeine は、 Web 検索で、以前のインデックスより 50パーセント新しい結果を提供します。それは、私たちが提供してきた中で、最大の Web コンテンツのコレクションです。
それが、ニュースであれ、ブログであれ、フォーラムへの投稿であれ、それが公開されると、以前に可能だったものよりはるかに早く、関連するコンテンツへのリンクを見つけることが出来ます。
では、なぜ、私たちは新しいインデキシング・システムを構築したのでしょうか？ Web 上のコンテンツは、開花の時期を迎えています。単にサイズや数が増えたばかりではなく、ビデオや画像、ニュースやリアルタイムに更新されるものが登場し、普通の Webページもリッチで複雑なものになっています。加えて、人々の検索に対する期待も、以前に比べて高度なものになっています。検索者は、最新の関連するコンテンツを見つけることを望み、公開者は、公開した瞬間にでも、それが見つかることを期待します。
Web の進化に対応し、高まるユーザーの期待に応える為に、私たちは、 Caffeine を構築しました。この図は、古いインデキシングシステムがどのように働いていたかを、 Caffeine との比較で図示したものです。
古いインデックスは、いくつかの層を持っていました。そのいくつかは、他のものより早く更新されていました。主要な層は、二週間に一回更新されていました。古いインデックスの層を更新する為には、 Web 全体を分析してきました。そのことは、私たちがページを見つけるのと、それをユーザーに利用可能にすることの間には、大きな遅れがあったことを意味します。
Caffeine では、私たちは、 Web の小さな部分を分析し、検索インデックスを全体的には連続したベースの下で更新します。新しいページ、あるいは、既存のページに新しい情報を発見すると、これらを直接インデックスに追加することが出来ます。こうして、それがいつどこで公開されても、いまだかってなかった新鮮な情報を、ユーザーは見つけることが出来るのです。
Caffeine では、私たちは、巨大な規模でWebページのインデックス付けを行います。実際、 Caffeine は、毎秒 数十万のページをパラレルに処理します。もし、それを紙で積み上げたら毎秒 3 マイルの高さになるでしょう。 Caffeine は、一つのデータベースに約一億ギガバイトのストレージをあてています。そして一日に数十万ギガバイトの割合で情報を追加しています。この情報を蓄えるには、大型の iPad が、 625,000 個必要です。 これを端から端にならべると、 40 マイル以上になります。
私たちは、 Caffeine を未来を胸に抱いて構築しました。単に新しい情報を与えるだけでなく、オンライン上の情報の増大とともにスケールし、より関連する検索結果をユーザーに届ける、さらに高速で分かりやすい検索エンジンを構築する、それは強固な土台なのです。ですので、期待して注目してください。今後の数ヶ月のうちにも、さらなる改良が行われることを。
Google Caffeine jolts worldwide search machine
2010 年 6 月 9 日Interview with Matt http://www.theregister.co.uk/2010/06/09/google_completes_caffeine_search_index_overhaul/
本質的には、 Google はバッチ型のインデックス・システムから、その場でリアルタイムでインデックスを更新するシステムに移行したのだ。
「我々の技術は、ページをクロールするやいなやページにインデックスをつけることを可能にした。過去には、インデックスの更新の度に、 Web 全体の分析を行っていたので、我々は大規模なバッチで（しばしば数十億ページに及ぶ）ページにインデックスをつけていた。 Caffeine では、 Web の小さな部分で分析が出来るので、 インデックスを連続的に更新出来る。」
「このことは、次のようにも考えることが出来る。我々は、数十億のドキュメントのインデックス付けのバッチから、（それぞれ一つの文書に対して）数十億の「バッチ」を処理するシステムに変わったのだと」
Google search index splits with MapReduceWelds BigTable to file system 'Colossus’
2010 年 9 月 9 日Interview with Lipkovitzhttp://www.theregister.co.uk/2010/09/09/google_caffeine_explained/
新しい検索のインフラは、 GFS 分散ファイルシステムの改修版を使用している。これは、Google File System 2 、 GFS2 と呼ばれていたのだが、 Google の内部では、 Lipkovitz がいうように Colossus として知られているという。
「 Caffeine はデータベース・ドリブンで、BigTable を変化させたインデックス・システムである。 Google は、このシステムを論じた論文を、来月行われる USENIX Symposium on Operating Systems Design and Implementation (OSDI) で発表する。」
「我々は、非常に膨大なデータから出発して、それを処理してきた。８時間かそれくらい後に、この全体の処理の出力がなされる。その結果をまた、サービス用のシステムにコピーする。我々は、そうした処理を連続的に行ってきた。」
MapReduce は、 Google が望むように出来るだけ早くインデックスを更新することを、Google に許さなかった。リアルタイム Webの時代、 Google は数秒のうちにインデックスを更新することを求められていた。
過去数年の間、 MapReduce は、 MIT のデータベースの権威 Mike Stonebraker のような人々から批判を受けてきた。 Lipkovitz によれば、 Google自身、大分前から「同じような認識」に到達していたという。
「 MapReduce は、リアルタイムに近い出来事に必要な計算には、向いていない。 MapReduce は、一連のバッチ処理からなる。一般的には、最初の処理が終わるまでは、次のフェーズあるいは次の処理を始めることは出来ない。」
「 MapReduce は、“おちこぼれ”の問題に悩まされていた。 map-reduce の一連のシリーズに基づいたシステムを作ろうとすれば、ある程度の確率で、何かうまくいかないことが起きる。その確率は、処理の数を増やそうと思えばそれだけ大きなものになる。問題が起きた時、ほんの少しの時間ですむ処理でさえも、何も出来なくなる。だから、我々は、MapReduce を取り除いた。」
Caffeine では、 Google は、既に BigTableに格納されている Web マップを直接変更することで、インデックスを更新出来る。このシステムは、 BigTable 上で動く、あるフレームワークを含んでいる。 Lipkovitz は、それを従来のデータベース・プログラミングでの「データベース・トリガー」にたとえた。「それは完全にインクリメンタルだ。」 Google は、新しいページがクロールされる度に、全体を再構築することなく、必要に応じてインデックスを更新出来る。
「開発者が、 BigTable 上でコードを実行するのを助ける “計算フレームワーク” もある。このシステムは、 Clossus で土台を支えられている。 Clossus は、 GFS2 としても知られている分散ストレージプラットフォームだ。元の GFS は、 Google が望むようにはスケールしなかった。」
Colossus は、 BigTable の為に特別にデザインされたものだ。そうした理由によって、 GFS がそうだったような「一般的な利用」には向いていない。それは、特に新しいCaffeine 検索インデックスシステムでの利用の為に作られたものだ。それでも、他のGoogle のサービスに、あるかたちでは利用されるかもしれない。ただ、それは、 Google のインフラ全体にわたるものとしてはデザインされたたぐいのものではない。
「 MapReduce は、決して死んだ訳ではない。Caffeine でもバッチ処理を使うケースも存在するし、 Mapreduce は、いまも他の沢山のGoogle のサービスのベースである。しかし、Caffeine登場以前は、インデックス・システムが MapReduce の最大のアプリケーションであった。それで、このプラットフォームの利用は、大きく減少してきた。」
2004 年に、 Google は GFS と MapReduceについての研究論文を発表した。これが、オープンソースの Hadoop プラットフォームの基礎になった。それは、 Yahoo, Facebook, Microsoft によって利用されている。しかし、 Google は GFS と MapReduceを超えて進もうとしている。
「世界の残りの部分が、我々より遅れていると主張するつもりはない。我々は、検索を役に立つものにするビジネスをしている。インフラを売るビジネスをしている訳ではない。」
Incrementally Indexing the Web with Percolator
2010 年 10 月 4 日Frank Dabek and Daniel Peng
at OSDI, 2010 https://docs.google.com/presentation/d/1gKD4FbaUIGtoimP6-ZB0iiW8V0KZt8fVET-Cfu5KiG8/present#slide=
id.i0
問題：Web にインデックスをつける
times.com
mit.edu
g.cn
fark.com
nyt.com
URL In Links Body
PageRank
times.com
mit.edu ... 1
mit.edu times.com ... 1
fark.com
times.com ... 3
g.cn fark.com,times.com
.... 7
indexing
出力 :サービス用のドキュメント
入力 : 元の生ドキュメント
MapReduce で重複を取り除く
Map Reduce
インデックス・システムは沢山の MapReduces の連鎖
ドキュメント解析
チェックサムでグループ化
逆リンク
MapReduce でのインデックスの更新
•新しいドキュメントにインデックスつけるべきか？o新しいドキュメントは、以前にクロールした文書のコピーかもしれない。
o全てのレポジトリーの再マップが要求される。
Map
repository
refresh
インデックス・システムの目標
理想的なインデックス・システムに何を望むか？ 大量のデータのレポジトリー
インデックスのサイズの上限まで インデックスのより高い質（沢山のリンクとか）
クロールとインデックスの間の遅延の小ささ「新鮮さ」
MapReduce のインデックス・システムは、クロールからインデックスまで、数日かかる。
インクリメンタルなインデックス付け
• ランダム・アクセス可能なレポジトリーを、 BigTable に保持する
• グローバル・スキャンを避けるインデックス•インクリメンタルに複製可能な状態が、 URL として、クロールされる
URL Contents Pagerank
Checksum Language
http://usenix.org/osdi10
<html>CFP, ....
6 0xabcdef01 ENGLISH
http://nyt.com/ <html>Lede ...
9 0xbeefcafe ENGLISH
BigTable 上のインクリメンタルなインデックス付け
Checksum Canonical
URL Checksum PageRank IsCanonical?nyt.com 0xabcdef01 6
0xabcdef01 nyt.com
nytimes.com 0xabcdef01 9
nytimes.com
no
二つの URL を同時に処理すると、何が起きる？
yes
Percolator: インクリメンタルなインフラ
BigTable に分散トランザクションを追加
(0) Transaction t; (1) string contents = t.Get(row, "raw", "doc"); (2) Hash h = Hash32(contents); ... // Potential conflict with concurrent execution (3) t.Set(h, "canonical", "dup_table", row); ... (4) t.Commit(); // TODO: add retry logic
Simple API: Get(), Set(), Commit(), Iterate
Bigtable の構造
Bigtable は整列された (row, column, timestamp)
のストアであるColumn1 Column2 Column3
RowOne
3:2:1: "I'm at timestamp 1"
3:2: "I'm at timestamp 2"1:
3:2:1:
RowTwo3:2:1:
3:2:1:
3:2:1:
• データは行範囲で tablet に分割される• Tablet は、沢山のマシンに分散されている
分散トランザクションの実装
• snapshot isolation semantics を与える• Multi-version protocol (Bigtable の timestampに map)
• Two phase commit クライアントが調整する• Locks は、 Bigtable の特別なカラムに入れられる
"balance"
balance:data
balance:commit
balance:lock
Alice5:4:3: $10
5:4: data @ 33:
5:4:3:
Transaction Commit
balance:data balance:commit
Alice3: $10
4: data @ 33:
Bob3: $10
4: data @ 33:
balance:data balance:commit
balance:lock
Alice5: $154:3: $10
4: data @ 33:
6:5: lock4:3:
Bob 4:3: $10
4: data @ 33:
6:5:4:3:
balance:data balance:commit
balance:lock
Alice5: $154:3: $10
4: data @ 33:
6:5: lock4:3:
Bob5: $54:3: $10
4: data @ 33:
6:5: lock4:3:
balance:data balance:commit
balance:lock
Alice5: $154:3: $10
6: data @ 55:4: data @ 33:
5:4:3:
Bob5: $54:3: $10
4: data @ 33:
5: lock4:3:
balance:data
balance:commit
balance:lock
Alice5: $154:3: $10
6: data @ 55:4: data @ 33:
5:4:3:
Ben 5: $54:3: $10
6: data @ 55:4: data @ 33:
5:4:3:
Transaction t;int a_bal = t.Get("Alice", "balance");int b_bal = t.Get("Bob", "balance");t.Set("Alice", "balance", a_bal + 5);t.Set("Bob", "balance", b_bal - 5);t.Commit();
Notifications: tracking work
ユーザーは、 "observer" をカラムに登録する•カラム中の行に書き込みが起きると実行される•それぞれの observer は、新しいトランザクションで走る
•書き込みごとに最大で一回実行される：メッセージの畳み込み
DocumentProcessor
DocumentProcessor
DocumentProcessor
RawDocumentLoader
RawDocumentLoader
DocumentProcessor
DocumentExporter
LinkInverter
アプリケーションは、一連の observer のつながりとして構造化される
Notifications の実装
Dirty column: もし observers が走るべき行なら設定ランダム分散スキャン•中断している仕事を見つけ、 observer をスレッドプール
で走らせる•スキャンは効率的である。数ビットをみるだけ
No shards or work units: nothing to straggle
Dirty? balance:data ...
Alice Yes 5: $15
Bob No 5: $5
Running Percolator
Each machine runs:•Worker binary
linked with observer code.
•Bigtable tablet server
•GFS chunkserver
Observer Code
Percolator::RunWorker()
Tablet Server
Tablet Server
Tablet Server
...
x N
GFS GFS GFS
MR v. Percolator: Performance
Fraction of Repository refreshed / hour
Operating Point
MR v. Percolator: Experience
我々は、 MR ベースのパイプラインを Percolatorに変換した。
Pros:•新鮮さ : インデックスの遅延は数日から数分にまで落ちた•スケーラビリティ : o一層のスループット : もっと沢山の CPU を買えばいいoより大きなレポジトリー : ディスクスペースの制限のみ
•運用面 : 「落ちこぼれ」に耐性があるCons:•並列性を考える必要がある•ドキュメントあたりの処理コストが高価である (~2x)
Running 1000 threads on Linux
Percolator は、 thread-per-request モデルPros:•アプリケーションの開発者は、ストレートなコードを書け
る•スタックトレースが重要 デバッグ、プロファイルが容易•メニーコア・マシンに容易にスケールする
Cons:•カーネルのスケーラビリティ：プロセスが exit する
間、 1000 個のスレッドが働いている時、カーネルロックが保持される
•ローカルスレッドのストレージの検出がライブラリーにない
•キャッシュ等とのロックの競合
System Building by D. Rumsfeld
There are known unknowns. That is to say We know there are some things We do not know.But there are also unknown unknowns, The ones we don't know We don't know. — Sec. Donald Rumsfeld
Unknown unknowns
CPUs that get XOR wrong periodically: checksum "failures”
Bigtable scaling: can't delete files fast enough>50% of seeks going to useless readahead and
metadata.Incorrect resistor value: our workload powers off
machine
Advice:•Push performance debugging through all layers of
system•Expected weirdness proportional to machine count
結論
Percolator は、“ Caffeine” Web 検索インデックス・システムを構成している
•50% 新鮮な検索結果•3倍大きなレポジトリー
Web スケールの分散トランザクションの「存在証明」
Large-scale Incremental Processing Using Distributed Transactions and Notifications
Daniel Peng and Frank DabekPresented by Nick Radcliffehttp://courses.cs.vt.edu/cs5204/fall11-butt/lectures/perculator.pdf
Tradeoffs
Percolator trades efficient use of resources for scalability.
Caffeine (the Percolator-based indexing system) uses twice as many resources as the previous system to process the same crawl rate.
Roughly 30 times more CPU per transactions than a standard DBMS.
Overview of Percolator design Percolator is built on top of Bigtable. A percolator system consists of three binaries
that run on every machine in the cluster: Percolator worker Bigtable tablet server GFS chunkserver.
Overview of Percolator design
Data is organized into Bigtable rows and columns, with Percolator metadata stored alongside in special columns.
The Percolator library largely consists of Bigtable operations wrapped in Percolatorspecific computation.
Percolator adds multirow transactions and observers to Bigtable.
Overview of Percolator design
An observer is like an event-handler that is invoked whenever a user-specified column changes.
Percolator applications are structured as a series of observers.
Each observer completes a task and creates more work for “downstream” observers by writing to the table.
Large-scale Incremental Processing Using Distributed Transactions and Notifications
2010 年 10 月 4 日D Peng, F Dabek - OSDI, 2010 https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Peng.pdf
Transaction in BigTable
c:data データ自身を格納 c:lock コミットされていないトランザク
ションは、 この Cell に書き込む。 PrimaryLock の場所を含んでいる。
c:write コミットされた現在のデータ。 データのタイムスタンプを格納。
c:notify ヒント : observer が走る必要がある かもしれない
c:ack O Observer “O” が走った。最後に 成功した実行のタイムスタンプを格納。
初期状態： Joe の口座には 2 ドル、 Bob の口座には、 10 ドルが、はいっている。
bal:write に、データのタイムスタンプが書き込まれることによって初めて、そのデータは外部から見えるようになる。
送金のトランザクションは、 Lockカラムに書き込むことで Bob の口座の残高をロックすることから始まる。このロックは、このトランザクションのprimary である。
このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。
トランザクションは、次に Joe の口座をロックして、ふたたび開始タイムスタンプ 7 に、 Joe の新しい残高を書き込む。
このロックは、このトランザクションの secondaryである。 primary ロック（” Bob”行の” bal”カラム）への参照を含んでいる。
クラッシュでこのロックが立ち往生して、トランザクションがロックを解消したいと思った時、このロックの解消を同期するために primary の場所が必要になる。
トランザクションは、コミットのポイントに到達する。
primary ロックを消して、それをコミットタイムスタンプと呼ばれる新しいタイムスタンプ 8 の下で、新しい書き込みレコードと置き換える。この書き込みレコードは、データが格納されているタイムスタンプへのポインターを含んでいる。
これ以降、” Bob”行の” bal”カラムを読むものは、値 $3 を見ることになる。
トランザクションは、 secondary セルに書き込みデータを追加し、ロックを消去することで完了する。
この例の場合には、ただ一つの secondary Joe があるだけである。
Transaction in BigTable 詳細
1 class Transaction { 2 struct Write { Row row; Column col; string value; }; 3 vector<Write> writes_ ; 4 int start_ts_ ; 5 6 Transaction() : start_ts_(oracle.GetTimestamp()) {} 7 void Set(Write w) { writes_.push_back(w); }
クラス Transaction の働きを見てみよう。
まず、 Transaction のインスタンスの生成時に、start_ts_ には、その時点のタイムスタンプが入れられる。 ６行目。
データの読み込み： bool Get(Row row, Column c, string* value) の働き
row 中の、コンカレントな write を通知するロック c:lock を、過去から start_ts_ まで、チェックする。
ペンディングされたロックがあれば、クリーンを試みて待つ。なければ、次に進む。
c:write をチェックして、過去から start_ts_までにコミットされた、書き込みをみつける。なければ、データはない。
c:write からコミットされたタイムスタンプを取得。
c:data から、コミット・タイムスタンプ時点での値を読み出す。
8 bool Get(Row row, Column c, string* value) { 9 while (true) {10 bigtable::Txn T = bigtable::StartRowTransaction(row);11 // コンカレントな write を通知するロックをチェックする12 if (T.Read(row, c+"lock", [0, start_ts_])) {13 // ペンディングされたロックがあれば、クリーンを試みて待つ14 BackoffAndMaybeCleanupLock(row, c);15 continue;16 }1718 // スタート・タイムスタンプ以下の最新の書き込みをみつける。19 latest write = T.Read(row, c+"write", [0, start ts_]);20 if (!latest write.found()) return false; // データなし21 int data_ts = latest_write.start_timestamp();22 *value = T.Read(row, c+"data", [data ts, data ts]);23 return true;24 }25 }
書き込み前処理： bool Prewrite(Write w, Write primary) の働き
Prewrite は、セル c をロックしようとする。競合があると false を返し、 Abort する。
c:write をチェックし、スタート・タイムスタンプの後にコミットされたものであれば、Abort する
c:lock をチェックし、どんなタイムスタンプでもＬｏｃｋされていれば、 Abort する。
c:data に値を書き込む。 c:lock に、スタート・タイムスタンプ
と、 primary lock の場所を書き込む。 コミットする。
26 //Prewrite は、セル c をロックしようとする。競合があると false を返す。27 bool Prewrite(Write w, Write primary) {28 Column c = w.col;29 bigtable::Txn T = bigtable::StartRowTransaction(w.row);3031 // スタート・タイムスタンプの後にコミットされたものであれば、 Abort する32 if (T.Read(w.row, c+“write”, [start ts , ∞])) return false;33 // . . . あるいは、どんなタイムスタンプでもＬｏｃｋされていれば、 Abort する34 if (T.Read(w.row, c+"lock", [0, ∞])) return false;3536 T.Write(w.row, c+"data", start ts_, w.value);37 T.Write(w.row, c+"lock", start ts_,38 {primary.row, primary.col} ); // プライマリーの場所39 return T.Commit();40 }
コミット： bool Commit() の働き writes_ ベクターの先頭が primary 、それ以降を secondaries とする。
primary 、 secondaries への PreWrite が失敗すれば、コミット失敗。
コミット・タイムスタンプを取得する。 まず、 primary をコミット
c:lock のスタート・タイムスタンプ時点での値を読み込む。なければ、コミット失敗。
コミット・タイムスタンプの c:write に、 スタートタイムスタンプに書かれたデータへのポインターを書き込む。
コミット： bool Commit() の働き
コミット・タイムスタンプの c:lock を消す。 コミットする。
続いて、 secondaries をコミット。 secondaries の各Write ごとに、 コミット・タイムスタンプの c:write に、 スター
トタイムスタンプに書かれたデータへのポインターを書き込む。
コミット・タイムスタンプの c:lock を消す。 コミット成功
41 bool Commit() {42 Write primary = writes_[0];43 vector<Write> secondaries(writes_.begin()+1, writes_.end());44 if (!Prewrite(primary, primary)) return false;45 for (Write w : secondaries)46 if (!Prewrite(w, primary)) return false;4748 int commit_ts = oracle .GetTimestamp();4950 // Primary を、まずコミットする51 Write p = primary;52 bigtable::Txn T = bigtable::StartRowTransaction(p.row);53 if (!T.Read(p.row, p.col+"lock", [start_ts_, start_ts_]))54 return false; // 動作中に abort55 T.Write(p.row, p.col+"write", commit ts,56 start_ts_); // スタートタイムスタンプに書かれたデータへのポインター57 T.Erase(p.row, p.col+"lock", commit ts);58 if (!T.Commit()) return false; // コミットポイント59 // 第二フェーズに進む
60 // 第二フェーズ セカンダリーセルにレコードを書き出す61 for (Write w : secondaries) {62 bigtable::Write(w.row, w.col+"write", commit_ts, start_ts_);63 bigtable::Erase(w.row, w.col+"lock", commit ts);64 }65 return true;66 }
bool UpdateDocument(Document doc) {
Transaction t(&cluster); t.Set(doc.url(), "contents", "document", doc.contents());
int hash = Hash(doc.contents());
// dups table maps hash --> canonical URL string canonical; if (!t.Get(hash, "canonical-url", "dups", &canonical)) { // No canonical yet; write myself in t.Set(hash, "canonical-url", "dups", doc.url()); } // else this document already exists, ignore new copy
return t.Commit();}
Dremelインタラクティブなデータ分析
リアルタイムへの要求は、とまらない。 2010 年に論文が公開された Dremelは、 MapReduce の 100倍のスピードで、巨大なデータを、インタラクティブに解析する。以前から Google内部で利用されていたが、 2012 年、 BigQuery として、公開サービス開始。
Dremel: Interactive Analysis of Web-Scale Datasets
Proc. of the 36th Int'l Conf on Very Large Data Bases (2010), pp. 330-339http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//pubs/archive/36632.pdf
Dremel のアイデア 第一。分散検索エンジンで利用されている、木構造のアーキテクチャー。 Web 検索と同様に、検索は、木構造をたどって行われ、それを書き換える。検索結果は、下位の木構造から得られる答えを集約することで行われる。
第二。 Dremel は、 SQL-like な検索言語をサポートする。それは、 Hiveや Pig とはことなり、 Map-Reduce には変換されずに、ネーティブに検索を実行する。
Dremel のアイデア 第三。 Dremel は、カラム単位で分割された
データ構造を利用する。カラム型のストレージは、読み込むデータを少なくして、圧縮が簡単に出来るので、 CPU のコストを削減する。カラム型のデータ・ストアは、リレーショナルなデータの解析には採用されてきたが、我々の知る限り、ネストしたデータ構造へのその拡張は、行われてこなかった。
Google Dremel
Dremel が利用されている領域 クロールされた Web ドキュメントの解析 Android マーケットで、インスロールされたアプリ
の追跡 Google製品のクラッシュ報告 Google Books の OCR の結果 . スパムの解析 Google Map の map タイルのデバッグ Bigtable インスタンスの Tablet マイグレーション
の管理 Google の分散ビルドシステム上での実行テスト結果 数十万のディスクの Disk I/O 統計 Google データセンターで実行されているジョブの、リソース・モニタリング
Google のコードベースの、シンボルと従属性
message Document { required int64 DocId; optional group Links { repeated int64 Backward; repeated int64 Forward; } repeated group Name { repeated group Language { required string Code; optional string Country; } optional string Url; }}
Document
DocID Links? Name*
Backward* Forward* Language* Url?
Code Country?サンプルのスキーマ
Protocol Buffer
Code
DocID
Document
Links? 1 Names* 1 1
Backward* 1
2Forward* 1
2Language* 2
2Url? 2
Country? 3
Repetetion Level
Definition Level
2
０
DocId: 10Links Forward: 20 Forward: 40 Forward: 60Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A'Name Url: 'http://B'Name Language Code: 'en-gb' Country: 'gb'
DocId: 20Links Backward: 10 Backward: 30 Forward: 80Name Url: 'http://C‘
DocId: 10Links Forward: 20 Forward: 40 Forward: 60Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A'Name Url: 'http://B'Name Language Code: 'en-gb' Country: 'gb'
DocId: 20Links Backward: 10 Backward: 30 Forward: 80Name Url: 'http://C‘
DocId: 10Links Forward: 20 Forward: 40 Forward: 60Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A'Name Url: 'http://B'Name Language Code: 'en-gb' Country: 'gb'
DocId: 20Links Backward: 10 Backward: 30 Forward: 80Name Url: 'http://C‘
Document
DocID Links? Name*
Backward* Forward* Language* Url?
Code Country?
10 0 020 0 0
http://A 0 2http://B 1 2NULL 1 1http://C 0 2
20 0 240 1 260 1 280 0 2
NULL 0 110 0 230 1 2
en-us 0 2en 2 2NULL 1 1en-gb 1 2NULL 0 1
us 0 3NULL 2 2NULL 1 1gb 1 3NULL 0 1
サンプルの格納状態
Dremel の検索言語
SELECT DocId AS Id, COUNT(Name.Language.Code) WITHIN Name AS Cnt, Name.Url + ',' + Name.Language.Code AS StrFROM tWHERE REGEXP(Name.Url, '^http') AND DocId < 20;
Id: 10Name Cnt: 2 Language Str: 'http://A,en-us' Str: 'http://A,en'Name Cnt: 0
message QueryResult { required int64 Id; repeated group Name { optional uint64 Cnt; repeated group Language { optional string Str; }}}
出力結果 出力のスキーマ
検索の木構造
SELECT A, COUNT(B) FROM T GROUP BY A
SELECT A, SUM(c) FROM (R11 UNION ALL ...R1n) GROUP BY A
R1i = SELECT A, COUNT(B) AS c FROM T1i GROUP BY A
T1i は、レベル 1 のサーバー i で処理される、テーブルT のTablet の分割
MapReduce と Dremel
3000 nodes, 85 billion records
numRecs: table sum of int;numWords: table sum of int;emit numRecs <- 1;emit numWords <- CountWords(input.txtField);
Q1: SELECT SUM(CountWords(txtField)) / COUNT(*) FROM T1
結論 スキャンベースの検索は、一兆個以上のディスク上
のデータセットに対して、インタラクティブなスピードで実行出来る。
数千ノードを含むシステムで、カラムとサーバーの数に関して、ほとんどリニアーなスケーラビリティーを達成出来る。
DBMS とまったく同様に、 MapReduce は、カラム型のストレージの恩恵を受ける。
レコードの収集とパージングは、コストがかかる。ソフトウェアの層は（検索実行の層を超えて）、直接カラム指向のデータを利用出来るようになる必要がある。
SpannerGoogle の新しい分散データベース
2012 年に論文が公開された Spanner は、key-value をベースにした拡張性と、 RDB の ACID なトランザクション処理能力を併せ持つ強力な分散データベースである。タイムスタンプ・ベースのトランザクション処理に必要な正確な時間を得る為に、 GPSや原子時計を利用。その上に、時間の不確実性を組み込んでいる。
Spanner: Google’sGlobally-Distributed Database
Wilson Hsieh representing a host of authorsOSDI 2012
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdfhttp://research.google.com/archive/spanner.htmlVideo:https://www.usenix.org/conference/osdi12/elmo-building-globally-distributed-highly-available-database
171
Spanner とは何か？
分散マルチバージョンデータベース汎用のトランザクション (ACID)SQL言語のサポート スキーム化されたテーブルSemi-relational なデータモデル
既に、製品として稼働している Google の広告データのストレージとして sharded MySQL を置き換えている
OSDI 2012
172
Example: Social Network
OSDI 2012
User postsFriend listsUser postsFriend listsUser postsFriend listsUser postsFriend lists
US
Brazil
RussiaSpain
San FranciscoSeattleArizona
Sao PauloSantiagoBuenos Aires
MoscowBerlinKrakow
LondonParisBerlinMadridLisbon
User postsFriend lists
x1000
x1000
x1000
x1000
173
Spanner概観
特徴 : Lock-free な、分散 read トランザクション
特質 : 分散トランザクションの外的整合性保証 グローバルなスケールでは、最初のシステム
実装 : Concurrency control と Replicationと 2PC の統合 正当性とパフォーマンス
可能にした技術 : TrueTime Interval-based なグローバル時間
OSDI 2012
174
読み込みのトランザクション
友達の最近のポストのページを生成する 友達のリストとそのポストの整合的なビュー
OSDI 2012
何故、整合性が重要なのか？1. 不審な人物を友達から削除する2. Post P: “ 我々の政府は、抑圧的である…”
175
User postsFriend listsUser postsFriend lists
単一のマシン
Friend2 post
マイページの生成
Friend1 post
Friend1000 postFriend999 post
書き込みブロック
OSDI 2012
…
177
User postsFriend lists User postsFriend lists
複数のマシン
User postsFriend lists
マイページの生成
Friend2 postFriend1 post
Friend1000 postFriend999 post
User postsFriend lists
書き込みブロック
OSDI 2012
…
179
User postsFriend lists
User postsFriend lists
User postsFriend lists
複数のデータセンター
User postsFriend lists
マイページの生成
Friend2 post
Friend1 post
Friend1000 post
Friend999 post
OSDI 2012
…
US
Spain
Russia
Brazil
x1000
x1000
x1000
x1000
181
書き込みとバージョン管理 書き込みのトランザクションには、厳密な Two-Phase-
Lock を使う。 それぞれのトランザクション T には、タイムスタンプ s が割り当てられる。
トランザクション T によって書き込まれたデータは、タイムスタンプｓを持つ。
OSDI 2012
Time 8<8
[X]
[me]
15
[P]My friendsMy postsX’s friends
[]
[]
182
スナップショットを同期する
==外的整合性 :
コミットの順序は、グローバルな壁時計の順序を尊重する
OSDI 2012
==タイムスタンプの順序は、与えられた
グローバルな壁時計の順序を尊重する
タイムスタンプの順序 == コミットの順序
グローバルな壁時計
183
タイムスタンプとグローバル・クロック 書き込みのトランザクションについては、厳密な two-
phase locking を適用する。 ロックが保持されている間、タイムスタンプを割り当
てる。
T
Pick s = now()
Acquired locks Release locks
OSDI 2012
タイムスタンプの不変量
• タイムスタンプの順序 == コミットの順序
• タイムスタンプの順序は、グローバルな壁時計の順序を尊重する
T2
T3
T4
T1
TrueTime
“グローバルな壁時計の時間” は、ある制限の範囲だが、不確実性を持つ。
time
earliest latest
TT.now()
2*ε
186
タイムスタンプと TrueTime
T
Pick s = TT.now().latest
Acquired locks Release locks
Wait until TT.now().earliest > ss
OSDI 2012
average ε
Commit wait
average ε
コミットの Wait とレプリケーション
T
Acquired locks Release locks
Start consensus Notify slaves
Commit wait donePick s
Achieve consensus
188
Commit Wait and 2-Phase Commit
OSDI 2012
TC
Acquired locks Release locks
TP1
Acquired locks Release locks
TP2
Acquired locks Release locks
Notify participants of s
Commit wait doneCompute s for each
Start logging Done logging
Prepared
Compute overall s
Committed
Send s
189
Example
OSDI 2012
TP
Remove X from my friend list
Remove myself from X’s friend list
sC=6
sP=8
s=8 s=15
Risky post P
s=8
Time <8
[X]
[me]
15
TC T2
[P]My friendsMy postsX’s friends
8
[]
[]
190
我々がカバー出来たことは何か？
データセンター間の、ロックフリーな、 read トランザクション
外的整合性 タイムスタンプの割り当て TrueTime
時間の不確実性は、待つことでしのぐことが出来る
OSDI 2012
191
我々がカバーしなかったこと 現在の時刻を、どうよむのか。 アトミックなスキーマの変更
大部分は、ノン・ブロッキングである 未来のタイムスタンプでコミットする
過去のノン・ブロッキングな読み込み レプリカの効率的な更新
OSDI 2012
192
TrueTime Architecture
Datacenter 1 Datacenter n…Datacenter 2
GPS timemaster
GPS timemaster
GPS timemaster
Atomic-clock
timemaster
GPS timemaster
Client
OSDI 2012
GPS timemaster
Compute reference [earliest, latest] = now ± ε
193
TrueTime implementation
time
ε
0sec 30sec 60sec 90sec
+6ms
now = reference now + local-clock offsetε = reference ε + worst-case local-clock drift
referenceuncertainty
OSDI 2012
200 μs/sec
194
時計が狂うとどうなるか？
タイムスタンプの割り当てが、外的整合性を破ることになるだろう。
一年間のデータに基づけば、そういうことはありそうにない。 時計が狂うより、 CPU がおかしくなる可能性
の方が、６倍以上ありそうである。
OSDI 2012
195
将来の課題 TrueTime の改善
Lower ε < 1 ms データベースの諸特徴をきちんと構築す
る 基本的な特徴の実装を終える 多様な検索パターンを効果的にサポートする
OSDI 2012
196
結論 時計の不確実性を time API で具体化する
知らないことを知ることは、知らないことを知らないより、いいことである
不確実性を利用した、アルゴリズムを再考すること
強いセマンティックは達成可能である 大規模なスケール != 弱いセマンティックス
OSDI 2012
Knowledge GraphGoogle の新しい検索技術
2012 年の 5 月、 Google は、「 Knowledge Graph 」と名付けられた新しい検索サービスをアメリカで開始した。言うまでもなく検索は、 Google のコア・コンピーテンスである。 Googleは、検索にどのような新しさを持ち込もうとしているのか？
Google Knowledge Graph新しい検索の三つの特徴
正しい「もの」を見つける。（ Find the right thing ）
最良の要約を得る。（ Get the best summary ）
さらに深く、さらに広く。（ Go deeper and broader ）
検索結果のパーソナライズ
Google の検索結果の「パーソナライズ」 人々は、コンテキストとパーソナライズを混同している。この２つは別のものだ。コンテキストには、言語、場所、年度等が因子として含まれる。
過去の検索の履歴は、パーソナライズに利用されている。もし、「ローマ」を検索して次に「ホテル」を検索すれば、検索結果のいくつかは、ローマのホテルのものになるだろう。
履歴上の過去のクリックも、一つの因子となる。もし、検索結果中の一つのサイトに対してクリックして、明らかな嗜好を示せば、次の検索では、そのサイトは上位にランクされるかもしれない。
Google の検索結果の「パーソナライズ」 URL の最後の部分に、 &pws=0 を追加する
と機能する。ただ、パーソナライズを消すだけで、コンテキスト（言語、場所、年度）は消さない。
全てのパーソナライズをオフにする方法はある。 Google の立場は、ユーザーは自分のデータを所有するというものだ。ただ、その場合でも、コンテキストは、依然として、有効になっている。
"How Google Does Personalization with Jack Menzel” http://www.stonetemple.com/how-google-does-personalization-with-jack-menzel/
まとめ
資料編
Snapshot Isolation “A Critique of ANSI SQL Isolation Levels”
Spanner: Google’s Globally-Distributed Database
Snapshot Isolation
“A Critique of ANSI SQL Isolation Levels”http://t.co/2HBae9l5gK
Start-Timestamp Snapshot Isolation では、それぞれのトラン
ザクションは、 Start-Timestamp と呼ばれる、トランザクションを開始した時刻のデータのスナップショット（コミットされた）からデータを読み込む。この時刻は、トランザクションの最初の読み込みの時刻の前の時刻になる。
トランザクションの Start-Timestamp 以降にアクティブになった他のトランザクションによる更新は、このトランザクションからは見えない。
Read と Write
Snapshot Isolation の中のトランザクションは、その Start-Timestamp からのスナップショットのデータが維持可能である限り、読み込みがブロックされることはない。
トランザクションでの書き込み (updates, inserts, deletes) もまた、このスナップショットに反映される。もしトランザクションが、このデータに二度目のアクセス（ reads あるいは updates ）をするなら、ふたたび、読み出される。
Commit-Timestamp トランザクション T1 が、コミットの準備が
できた時、それは Commit-Timestamp を取得するのだが、それは、既に存在する Start-Timestamp あるいは Commit-Timestampより、大きな値を持つ。
トランザクションは、 T1 の実行間隔[StartTimestamp, Commit-Timestamp] 内に Commit-Timestamp を持つ他のトランザクション T2 が、 T1 が書き出したデータと同じデータを書き出していない場合に限り、コミットに成功する。
First-Commiter-Wins
そうでない場合、 T1 はアボートする。この「最初にコミットしたものが勝つ」という特徴が、更新が失われるのを防止する。
T1 がコミットされると、その Start-Timestamps が T1 の Commit-Timestampより大きい、全てのトランザクションに、その変更は見えるようになる。
Spanner: Google’s Globally-Distributed Database
James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat et al.
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ja//archive/spanner-osdi2012.pdf
Abstract
Abstract
Spanner は、スケーラブルで、マルチ・バージョン、グローバルに分散し、レプリカの同期を行う、 Google のデータベースである。
それは、グローバルなスケールでのデータの分散と外的整合的な分散トランザクションをサポートした、初めてのシステムである。
この論文は、 Spanner がどのような構造を持つか、その諸特徴、様々なデザインの決定の基礎にある理論的な根拠、時計の不確実性を明らかにする全く新しい time API について述べたものである。
Abstract
この API とその実装は、外的な整合性と、 Spanner の全域にわたる、過去のデータのブロックしない呼び出し、ロックのないread-only トランザクション、そしてアトミックなスキーマの変更といった強力な諸特徴をサポートする上で、 本質的に重要なものである。
1 Introduction
概観 Spanner は、 Google で、デザイン・構築・配備されたスケーラブルでグローバルな分散データベースである。
もっとも高い抽象のレベルでは、 それは、全世界に広がっているデータセンター内の沢山の Paxos状態マシン群をまたいで、データを分割したデータベースである。
Spanner は、数百のデータセンターをまたいだ数百万のマシンと、数兆行のデータベースにスケールアップするように設計されている。
Replica と Resharding データの複製は、グローバルな可用性と地理的な局
所性の為に利用されている。クライアントは、レプリカ間で自動的にフェール・オーバーする。
Spanner は、データの量やサーバーの数が変化するに応じて、マシン間でデータを再分割する。それは、マシン間で（データセンター間でさえ）、自動的にデータを移動して、負荷のバランスを取り、マシンの失敗に対応する。
アプリケーションは、広域の自然災害に直面しても、内部で、あるいは大陸をまたいでも、データを複製することによって、高い可用性の為に、 Spanner を利用出来る。
Replica と Availability 我々のシステムの最初の利用者は、 Google の広告
システムのバックエンドを書き換えた F１であった。F1 は、アメリカ全土に広がった 5 つのレプリカを利用した。
他のアプリの大部分は、相対的には独立な事故のモードを想定してではあるが、一つの地理的な領域内で、 3 から 5 のデータセンターに、データを複製するだろう。というのは、大部分のアプリケーションは、一つか二つのデータセンターで事故が起きても、生き残ることが出来る限りは、高い可用性の上の低い遅延の方を選ぶだろう。
Spanner の主なフォーカスは、データセンターをまたいだ複製データの管理に置かれている。
Spanner と BigTable ただ、我々は、この分散システムのインフラの上に、
データベースの重要な諸特徴を、デザインし実装することにも、非常に多くの時間をかけてきた。
たとえ、多くのプロジェクトが、 BigTable を使ってハッピーだとしても、我々は、ある種のアプリに取っては、 BigTable は使うには難しくなることがあるという不満を、一貫して受け取ってきた。例えば、複雑でスキーマが変化する、あるいは、広域に複製があるにしても、強い整合性が欲しいというようなアプリだ。（同じような要求は、他の著者からもなされていた。）
Spanner と BigTable
Google の多くのアプリケーションは、相対的には貧弱な書き込み性能にもかかわらず、半リレーショナルなデータモデルと、複製の同期のサポートの故に、 Megastore を選んできた。
その結果、 Spanner は、 BigTable のようなバージョンづけられた key-value ストアから、テンポラルなマルチバージョン・データベースへと進化してきた。
Spanner のデータ形式 データは、スキーマを持つ半リレーショナル
なテーブルに格納される。データはバージョンづけられ、それぞれのバージョンは、自動的にそのコミット・タイムでタイムスタンプが与えられる。古いデータのバージョンは、設定可能なガーベージコレクション・ポリシーの元に置かれる。そうして、アプリは、古いタイムスタンプのデータを読むことが出来る。
Spanner は、一般的な目的のトランザクションをサポートし、 SQL ベースの検索言語を提供する。
グローバルに分散したデータベースとしての Spanner の、興味深い特徴
第一に、データの複製の設定は、アプリによって細かい粒度でコントロール出来る。アプリは、どのデータセンターがどのデータを持つのか、データはユーザーからどのくらい離れているか（読み込みの遅延をコントロールする）、レプリカはお互いにどれくらい離れているか（書き込みの遅延をコントロールする）、そして、どのくらいの数のレプリカが維持されているか（耐久性・可用性・読み込みのパフォーマンスをコントロールする）等をコントロールする制約条件を指定出来る。
データは、また、データセンター間のリソースの利用のバランスをとるシステムによって、動的かつ透過的にデータセンター間を移動出来る。
グローバルに分散したデータベースとしての Spanner の、興味深い特徴
第二に、 Spanner は、分散データベースでは実装するのが難しい二つの特徴を持つ。 読み書きについての外的整合性 ある時点での、データベースをまたいだグローバ
ルに整合的な読み込み こうした特徴は、グローバルなスケールで、
たとえ実行中のトランザクションがあったとしても、整合的なバックアップ、整合的なMapReduce の実行、アトミックなスキーマの更新を、 Spanner に可能とする。
Timestamp こうした特徴は、たとえトランザクションが分散し
ていたとしても、 Spanner がトランザクションにグローバルに意味のあるコミット・タイムスタンプを割り当てるという事実によって可能になった。
このタイムスタンプは、シリアル化された順序を反映している。それに加えて、シリアル化された順序は、外的整合性（あるいは、それと等価だが、線形化可能性）を満たしている。すなわち、あるトランザクション T1 が、別のトランザクション T2 が始まる前にコミットするなら、 T1 のコミット・タイムスタンプは、 T2 のそれよりも小さい。
Spanner は、グローバルなスケールで、こうした保証を与えた最初のシステムである。
TrueTime API こうした性質を可能にした重要なもの
は、 TrueTime API とその実装である。 この API は、直接に、時計の不確実さを、あらわに示すものである。そして、 Spanner のタイムスタンプは、実装が提供する不確実さの範囲にディペンドしている。もし、不確実さが大きければ、 Spannerは、この不確実さを待つ為に、スピードを落とす。
この実装は、複数の現代的な時計（ GPS と原子時計）への参照を利用することで、不確実性を小さなもの（一般的には、 10ms 以下）にとどめようとする。
2 Implementation
2.1 Spanserver Software Stack2.2 Directories and Placement2.3 Data Model
Implementation
この節では、 Spanner の構造とその実装の基礎にある理論的な根拠を述べる。
その後、複製と局所性を管理するのに利用され、データ移動の単位である、「ディレクトリー」という抽象について述べる。
最後に、我々のデータモデルと、なぜSpanner がキー・バリュー・ストアではなくリレーショナル・データベースのように見えるのか、また、アプリケーションは如何にしてデータの局所性をハンドルすることが出来るのかについて述べる。
Universe と Zone
Spanner の配備は、「ユニバース」と呼ばれる。 Spanner がデータをグローバルに管理しているとしても、ほんの少数の稼働しているユニバースがあるだけだろう。
我々は現在、テスト / プレイグラウンド・ユニバースと、開発 /生産・ユニバースと、生産専用・ユニバースの三つを走らせている。
Spanner は、一群の「ゾーン」で組織されている。それぞれのゾーンは、大まかにいって、BigTable のサーバーに相当するものである。
Zone ゾーンは、管理上の配備の単位である。一群のゾー
ンは、また、その上にデータの複製を置くことが出来る、場所群でもある。
新しいデータセンターがサービスを開始したり、逆に、古いデータセンターがサービスを停止したりした場合、ゾーンを稼働中のシステムに追加したり取り除くことが出来る。
ゾーンは、物理的な隔離の単位でもある。データセンターには、一つかそれ以上のゾーンがあるかもしれない。例えば、異なったアプリのデータが同じデータセンター内の異なったサーバー群にまたがって分割されなければいけないような場合である。
Zonemaster と LocationProxy
図 1 は、 Spanner ユニバースのサーバーを図示したものである。
ゾーンは、一つのゾーン・マスターと、百から数千の間のスパンサーバーを持っている。前者は、スパンサーバーにデータを割り当てる。後者は、データをクライアントにサービスする。
ユーザーのデータに割り当てられたスパンサーバーの場所を特定する為に、そのゾーンのロケーション・プロキシーが利用される。
UniverseMaster とPlacementDriver ユニバース・マスターとプレスメント・ドライバーは、
現在のところ、一つしかない。 ユニバース・マスターは、第一義的には、全てのゾー
ンについてのステイタス情報が表示され、インタラクティブなデバッグの為に利用される、コンソールである。
プレスメント・ドライバーは、数分の単位のタイムスケールでの、ゾーンをまたいだデータの自動的な移動をハンドルする。プレスメント・ドライバーは、定期的にスパンサーバーと通信して、レプリカの更新条件に合致した、あるいは、負荷をバランスさせる為、移動すべきデータを見つける。
スペースの関係で、スパンサーバーについてのみ、詳しく述べることになろう。
2.1 Spanserver Software Stack
この節では、スパンサーバーの実装にフォーカスして、我々の BigTable をベースにした実装の上に、どのように、複製と分散トランザクションが、実現されたかを示す。
Spanserver Software Stack
ソストウェア・スタックは、次の図 2 に示されている。スタックの一番下では、スパンサーバーが、 100 個から 1000 個の間のタブレットと呼ばれるデータ構造のインスタンスに責任を持っている。
タブレットは、 BigTable のタブレットという抽象と同様のもので、その中では、次のようなマッピングのバッグを実装している。
(key:string, timestamp:int64) → string
Bigtable とは異なって、 Spanner は、タイムスタンプをデータに割り当てる。ここが、 Spanner がキー・バリュー・ストアよりは、マルチ・バージョン・データベースにずっと似ている重要なポイントである。
タブレットの状態は、 Bツリーに似た一群のファイルと write-ahead ログに格納されている。これらは全て Colossus と呼ばれる分散ファイルシステム（ Google File System の後継である）上にある。
複製をサポートする為に、それぞれのスパンサーバーは、それぞれのタブレット上に、一つの Paxos状態マシンを実装している。
( 初期の Spanner の具体化では、タブレットごとに複数の Paxos状態マシンをサポートしていた。それによって、もっと柔軟な複製の設定が可能となるのだが、そのデザインの複雑さの為に、我々は、それを放棄した。）
それぞれの状態マシンは、そのメタデータとログを対応するタブレットに格納する。
我々の Paxos の実装は、時間ベースのリーダーのリースで、デフォルトの長さが 10 秒の、長い期間のリーダーをサポートしている。
現在の Spanner の実装では、全ての Paxosが二度ログを書き出している。一つは、タブレットのログで、もう一つは Paxos のログである。この選択は、 expendiency によるもので、最終的には修正したいと思っている。
我々の Paxos の実装は、 WAN の遅延があるにもかかわらず、 Spanner のスループットを向上させる為に、パイプライン化されている。しかし、書き込みは、 Paxos によって、順番に実行される。
Paxos
Paxos状態マシンは、マッピングのバッグのレプリカを整合的に実装するのに利用されている。それぞれの複製のキー・バリュー・マッピングの状態は、対応するタブレットに格納される。
書き出しは、リーダーの Paxos プロトコルから開始されなければならない。読み出しのアクセスの状態は、十分更新されたどのレプリカの下にあるタブレットからでも直接に取得出来る。一群のレプリカは、集って、 Paxos グループを形成する。
リーダーである全てのレプリカのスパンサーバーは、コンカレンシーのコントロールを実装する為のロック・テーブルを実装している。
ロック・テーブルは、ツー・フェーズ・ロッキングの為の状態を含んでいる。それは、一連のキーをロック状態にマップする。（ロック・テーブルを効率的に管理する上で、長い期間、生き続けるリーダーを持つことは、本質的に重要であることに注意。）
BigTable でも Spanner でも、両方とも、我々は。長いトランザクション（例えば、レポートの生成。これ数分単位の時間がかかる）の為のデザインをしてきた。こうした処理は、衝突がある場合には、楽観的コンカレンシー・コントロールでは、貧弱な性能しか出ない。
読み込みのトランザクションのような同期を必要とする操作は、ロック・テーブルからロックを取得する。その他の操作は、ロック・テーブルをバイパスする。
リーダーである全てのレプリカでは、それぞれのスパンサーバーは、分散トランザクションをサポートする為にトランザクション・マネージャーも実装している。
トランザクション・マネージャーは、参加者のリーダーを実装する為に利用される。その他のレプリカは、参加者のスレーブとなる。
もしトランザクションが、一つの Paxosグループを含んでいるだけなら（大部分のトランザクションの場合）、それは、トランザクション・マネージャをバイパス出来る。というのは、ロック・テーブルと Paxos が一緒になって、トランザクションの保証を提供するからである。
もしトランザクションが一つ以上の Paxosグループを含んでいたら、これらのグループ・リーダーがツー・フェーズ・コミットの調整役を演ずる。
参加グループの一つが、調整役に選ばれる。そのグループの参加者のリーダーは、調整役リーダーと呼ばれ、グループのスレーブは、調整役スレーブと呼ばれる。
それぞれのトランザクション・マネージャの状態は。直下の Paxosグループに格納される。（それ故、複製される。）
2.2 Directories and Placement
2.2 Directories and Placement
キー・バリュー・マッピングのバッグの上で、Spanner の実装は、「ディレクトリー」と呼ばれる「バケット化」の抽象をサポートしている。それは、共通の接頭辞を共有する連続的なキーの集まりである。（ディレクトリーという言葉の選択は、歴史的な事情によるもので、もっと良い言葉は、「バケット」だったかもしれない。）
次のセクション 2.3 で、この接頭辞の起源を説明しよう。ディレクトリーのサポートは、キーを注意深く選ぶことによって、データの局所性をコントロールすることを可能にする。
ディレクトリーは、データの配置の単位である。ディレクトリー内の全てのデータは、同じ複製設定を持つ。
データが Paxosグループ間を移動する時、それは図 3 が示すように、ディレクトリーからディレクトリーへと移動する。
Spanner は、ディレクトリーを、あるPaxosグループから負荷を軽減する為に移動するかもしれない。 よくアクセスされるディレクトリーを同じグループにまとめたり、アクセスする人に近いグループにディレクトリーを移動したり。
クライアントの操作が実行中でも、ディレクトリーは移動出来る。 50MB のディレクトリーは、数秒で移動出来ると考えてよい。
Paxosグループが複数のディレクトリーを含みうるという事実は、 Spanner のタブレットが BigTable のタブレットとは違っていることを意味している。 Spanner のタブレットは、単一の連続するの辞書式順序の行空間の分割ではないのである。
その代わりに、 Spanner のタブレットは、複数の行空間の分割を包み込んだコンテナーなのである。しばしば一緒にアクセスされる複数のディレクトリーを、近い場所に置くことが可能であるということで、我々は、この決定を行った。
Movedir は、 Paxosグループ間でディレクトリーを移動させるバックグラウンドのタスクである。 Movedir はまた、レプリカをPaxosグループに追加したり削除するのに利用されている。というのも、 Spanner はPaxos の設定を変えるということを、まだ、サポートしていないからだ。
Movedir は、大きなかたまりのデータ移動の際に実行される、読み出し・書き込みのブロックを避ける為に、単一のトランザクションとしては、実装されていない。
その代わりに、 movedir は、データ移動が始まったという事実を登録し、データをバックグラウンドで移動する。
名目的なデータの量以外の全てのデータを移動し終わったら、 movedir は、この名目的な量をアトミックに移動する為にトランザクションを利用し、二つの Paxosグループのメタデータを更新する。
ディレクトリーは、また、その複製の地理的なプロパティ（短く、「配置」という）が、アプリによって指定される最小の単位である。
配置指定の言語は、複製の設定を管理する責任とは分離されている。
管理者は、二つの次元をコントロールする。レプリカの数と型、そして、これらのレプリカの地理的な配置である。管理者は、これらの二つの次元で、名前でオプションのメニューを作る。（例えば、 North America, replicated 5 ways with 1 witness というような ).
アプリは、それぞれのデータベース、あるいは、個々のディレクトリーを、これらのオプションの組み合わせでタグづけて、データがいかに複製されるかをコントロールする。
例えば、あるアプリでは、エンドユーザー各人のデータを、次のように、自身のディレクトリーに格納しているかもしれない。ユーザー A のデータはヨーロッパに 3 つのレプリカを持ち、ユーザー B のデータは、北米に 5つのレプリカを持つ、ということが可能になる。
説明を分かりやすくする為に、随分、単純化したのだが、実際には、 Spanner はディレクトリーがあまりに大きくなった時には、それを複数のフラグメントに分割するだろう。
フラグメントは、異なる Paxosグループでサービスを受ける（それ故、異なるサーバーで）かもしれない。 Movedir は、実際には、グループ間でディレクトリー全体ではなく、フラグメントを移動する。
2.3 Data Model
Spanner は、次のような一群のデータの諸特徴を、アプリケーションに示す。 スキーマ化された半リレーショナルなテーブル、検索言語、一般的な目的のトランザクションである。これらの諸特徴をサポートしようという動きは、様々なファクターによってドライブされていた。
スキーマ化された半リレーショナルなテーブルと同期的な複製をサポートするニーズは、 Megastore が広く受け入れられたことでサポートされた。
Google内では、すくなくとも 300 のアプリが、 Megastore （その相対的には低いパフォーマンスにもかかわらず）を利用している。というのも、そのデータ・モデルは、管理が単純だからである。
そして、データセンターをまたぐ同期複製のサポートによって。（ BigTable は、データセンター間では、 Eventually Consistent な同期複製しかサポートしていない）
Megastore を利用したよく知られた Googleのアプリには、次のものがある。
Gmail Picasa Calendar Android Market AppEngine
Spanner で、 SQL ライクな検索言語をサポートする必要も、インタラクティブなデータ分析ツールとしての Dremel の人気をみれば、明確であった。
最後に、 BigTable では、行をまたいだトランザクションが欠けていたことも、しばしば不満の種になった。 Percolator は、部分的には、この欠点に向けて開発されたものだった。
ある人たちは、一般的なツー・フェーズ・コミットは、それがもたらすパフォーマンスの問題や可用性の問題を考えれば、サポートするのは、あまりに高いものにつくと論じてきた。
我々は、アプリケーションの開発者に、トランザクションの過剰な使用によりボトルネックが生ずるというパフォーマンスの問題を扱わせることは、いつもトランザクションを欠いたままコードを書くより、ましなことだと信じている。
Paxos 上でツー・フェーズ・コミットを走らせることは、可用性の問題を軽減する。
アプリケーションのデータ・モデルは、実装でサポートされている、ディレクトリーでバケット化されたキー・バリュー・マッピングの層の上に作られる。
アプリは、ユニバースの中に、一つ、あるいはそれ以上のデータベースを生成する。それぞれのデータベースは、無制限の数のスキーマ化されたテーブルを含むことが出来る。テーブルは、行とカラムとバージョン値を持つ、リレーショナル・データベースに見える。
ここでは、 Spanner の検索言語については深く触れない。それは、 プロトコル・バッファーの値を持つフィールドをサポートする、いくつかの拡張をほどこした SQL に見える。
Spanner のデータ・モデルは、純粋にリレーショナルなものではない。そこでは、行は名前を持たなければならない。もっと正確に言えば、全てのテーブルは、一つあるいはそれ以上の、順序づけられたプライマリー・キー・カラムのセットを持つことを要求される。
この要請は、 Spanner が依然としてキー・バリュー・ストアに見えるところである。プライマリー・キーは行に対する名前を形成し、それぞれのテーブルは、プライマリー・キー・カラムから非プライマリー・キー・カラムへのマッピングを定義する。
行は、行のキーに（たとえそれが NULL であっても）ある値が定義されている時にのみ存在する。
こうした構造を課することは、アプリケーションにキーの選択を通じてデータの局所性をコントロールさせるので、有用である。
図 4 は、ユーザーごと、アルバムごとに、写真のメタデータを格納する、 Spanner のスキーマの例である。
スキーマ言語は、 Megastore のものと似ている。それに、全ての Spanner のデータベースは、クライアントによって、一つあるいはそれ以上の、テーブルの階層によって分割されなければならないという要請を付け加えたものである。
クライアントのアプリは、データベースのこの階層を、 INTERLEAVE IN宣言によって宣言する。階層のトップのテーブルは、ディレクトリー・テーブルである。
キー K を持つディレクトリー・テーブルは、辞書式順序で K で始まる、下位のテーブルの全ての行とともに、ディレクトリーを形成する。
ON DELETE CASCADE は、このディレクトリー中のある行の削除は、関連する子供の行を全て削除することを意味している。
この図はまた、この例のデータベースのインターリーブされたレイアウトを図示している。
例えば、 Albums(2,1) は、 Albums テーブルのユーザー id 2 、アルバム id 1 の行を表している。
このディレクトリーを形成するテーブルのインターリービングは重要である。なぜなら、それは、複数のテーブル間に存在するローカルな関係を、クライアントが記述することを可能にするからである。
それは、分割された分散データベースでは、よいパフォーマンスの為に必要である。それなしでは、 Spanner は、もっとも重要なローカルな関係性を知ることが出来ない。
3 TrueTime
ここでは、 TrueTime API について述べ、その実装をスケッチする。詳細は、別の論文に譲る。我々の目的は、こうした APIを持つことの力を示すことである。
TrueTime
テーブル 1 は、この API のメソッドである。 TrueTime は、時間を TTinterval として、時
間の不確実性で境界付けられた、ある区間として、はっきりと表現している。（クライアントに、時間の不確実性についての考えを、まったく与えない標準的な時間のインターフェースとは、違っている）
TTinterval の端点は、 TTstamp の型を持つ。 TT.now() メソッドは、その間に TT.now() が呼び出された絶対時間を含むことが保証されている TTinterval を返す。この時刻は、 UNIX の time に似ているが、うるう秒の補正をしてある。
その瞬間の誤差の範囲を ε と定義する。それは、区間の半分の長さで、平均的な誤差の範囲は ε となる。
TT.after() と TT.before() メソッドは、 TT.now() 関連の便利なラッパーである。
イベント e の絶対時間を、関数 t_{abs}(e)で表す。より形式的に述べれば、 t_{now}をイベントの呼び出しとしたとき、 TrueTime は、次のことを保証する。 tt = TT.now() 、 tt.earliest ≤ t_{abs}(t_{now}) ≤ tt.latest
TrueTime で使われている基礎になる時間の参照は、 GPS と原子時計である。 TrueTimeは、二つの形式の時間を参照する。というのも、この二つは、失敗のモードが異なっているから。
GPS のソース参照の脆弱性は、 アンテナやレシーバの事故、ローカルな電波の干渉、正しくないうるう秒の処理やなりすまし等に関連した失敗を含んでいる。
原子時計は GPS とは関係なく、それぞれ独立に失敗することがある。あまりに長い時間の間隔は、 周波数エラーで大きくずれることがある。
TrueTime は、データセンターごとのタイム・マスター・マシンと、マシンごとのタイム・スレーブ・デーモンで実装されている。
マスターの大部分は、専用アンテナを備えたGPS受信機を持っている。これらのマスターは、アンテナ事故や電波の干渉、なりすましの危険を軽減する為に、物理的に離れて設置される。
残りのマスター（われわれは、それを「ハルマゲドン・マスター」と読んでいる）は、原子時計を装備している。
原子時計は、高価なものではない。ハルマゲドン・マスターのコストは、 GPS マスターのコストと同じオーダーである。
全てのマスターの時間参照は、定期的に、相互に比較される。それぞれのマスターはまた、参照時間と自分のローカル時計とのクロス・チェックも行う。もし、重大な相違があれば、自分をマスターから外す。
同期の間、ハルマゲドン・サーバーは、ゆっくり増えていく時間の不確実性を広告する。それは、最悪ケースの時計のずれを適用して、保守的に導きだされる。
GPS マスターは、典型的にはゼロに近いものとして、不確実性を広告する。
全てのデーモンは、一つのマスターによるエラーの脆弱性を軽減する為に、多様なマスターに投票する。あるものは、近くのデータセンターから選ばれた GPS マスターを、あるものは、遠くのデータセンターの GPS マスターを、あるものはハルマゲドン・マスターを選ぶ。
デーモンは、嘘つきを検出し排除し、ローカル・マシンの時計を、嘘つきではない時計に同期する為に、 Marzullo のアルゴリズムの変種を適用する。
壊れたローカル時計から守る為に、コンポーネントの仕様と操作環境から導かれる最悪ケースより大きな変動を繰り返すマシンは、取り除かれる。
同期の間、デーモンは、ゆっくり増えていく時間の不確実性を広告する。 ε は、最悪ケースの時計のずれを適用して、保守的に導きだされる。
ε はまた、タイム・マスターの不確実性と、タイム・マスターに対する通信遅延にディペンドする。
我々の製品版の環境では、 ε は、投票間隔では、約 1ms から 7ms の間を変動する、のこぎりの歯状の関数である。 ε は、それ故、大部分の時間 4ms である。
デーモンの投票間隔は、現在 30 秒であり、現在の変異率は、毎秒あたり 200 マイクロ秒に設定されている。
のこぎり歯は、 0 から 6ms の範囲の値を持つ。残りの 1ms は、タイム・サーバーに対する通信遅延である。
事故が起きた時は、こののこぎり歯から乖離する可能性がある。例えば、タイム・マスターが一時的に使えなくなった場合は、データセンター全体で、 ε の値の増大を引き起こす。同様に、過負荷なマシンやネットワーク・リンクは、一時的で局所的な ε のスパイクを引き起こすことがある。
4 Concurrency Control
この節では、 TrueTime が、コンカレンシーのコントロールまわりの正確性という性質を、いかに保証しているのか、また、これらの性質が外的整合なトランザクション、ロックのない Read-Only トランザクション、過去のデータのブロックしない読み込みといった特徴を実装するのにどのように利用されているかを述べる。
これらの諸特徴は、例えば、全てのデータベースで、タイムスタンプ t での正当性検査の読み込みが、 t で既にコミットされている全てのトランザクションの効果を、正確に見ることを保証する。
さらに言えば、それは Paxos によって見られる書き込みを（ここで、コンテキストが明確でないが、 Paxos の書き込みという）、 Spanner のクライアントの書き込みとを区別する為にも重要である。
例えば、 TPC は、準備フェーズで Paxos の書き込みを生成するが、それは Spanner のクライアントの書き込みには、照応してはいない。
4.1 Timestamp Management
テーブル 2 は、 Spanner がサポートしている操作をまとめたものである。
Spanner の実装は、 read-write トランザクションと read-only トランザクション（スナップショット・トランザクションとよばれたもの）、スナップショット read をサポートしている。
単独の書き込みは、 read-write トランザクションとして実装されている。
スナップショットではない単独の読み出しは、read-only トランザクションとして実装されている。
双方ともに、内部的にはリトライされる。（クライアントは、自分でリトライのコードを各必要はない）
read-only transaction read-only トランザクションは、スナップショッ
ト・アイソレーションのパフォーマンスの利点をもったタイプのトランザクションである。
read-only トランザクションは、いかなる書き込みも持っていないと、あらかじめ宣言されていなければならない。それは、単純に、いかなる書き込みのない read-write トランザクションではない。
read-only トランザクションは、ロックなしで、システムが選んだタイムスタンプで実行される。だから、書き込みはブロックされない。
read-only トランザクションでの読み込みの実行は、十分にアップデートされた全てのレプリカ上で遂行される。
Snapshot read スナップショット read は、ロックなしに実行される過去の読み出しである。
クライアントは、スナップショット read の為にタイムスタンプを指定出来る。あるいは、望むタイムスタンプの古さの上限を与えて、Spanner にタイムスタンプを選ばせることも出来る。
どちらの場合でも、スナップショット readの実行は、十分にアップデートされた全てのレプリカ上で遂行される。
read-only トランザクションでも、スナップショット read でも、双方で、いったんタイムスタンプが選ばれれば、そのタイムスタンプがガーベージ・コレクトされていない限りは、コミットは不可避である。結果として、クライアントはリトライ・ループの内部で、結果をバッファリングする必要を避けられる。
サーバーが失敗した時、クライアントは、タイムスタンプと現在の読み込み位置を繰り返し与えて、内部的に、異なるサーバーにクエリーを続ける。
4.1.1 Paxos Leader Leases
Spanner の Paxos の実装では、リーダーを長生きさせる為に（デフォルトでは、 10秒）、リースを使っている。
潜在的なリーダーは、リースの投票のリクエストを送る。定足数に達するリースの投票を受け取ると、リーダーは、リースがあることを知る。
レプリカは書き込みに成功すると暗黙にリースの投票を拡大し、リーダーは、リースの期限切れに近づくと、リースの投票の拡張をリクエストする。
リーダーのリースの期間を、それがリースの投票が定足数に達したことを見つけた時にスタートし、もはや、その定足数に達しない時（いくつかが終了したので）に終わるものと定義しよう。
Spanner は、 次のような、相互に関連のないという原則にディペンドしている。それぞれの Paxosグループにとって、それぞれの Paxosリーダーのリース期間は、他の全てのリーダーのリース期間とは、切り離されている。
Spanner の実装は、 Paxos のリーダーが、スレーブをリースの投票から解放することによって、仕事を放棄することを認めている。
相互に関係がないことを変わらないように維持する為に、 Spanner は、放棄が許可されうる場合でも制約を設けている。
smax を、リーダーが利用出来る最大のタイムスタンプとしよう。次節以降で、いつsmax が進んでいくかを記述するだろう。 任務を放棄する以前に、リーダーはTT.after(smax) が真になるまで、待たないといけない。
4.1.2 Assigning Timestamps to RW Transactions
read と write のトランザクションは、ツー・フェーズ・ロッキングを使用している。その結果、全てのロックが獲得されるなら、いかなる時間でもタイムスタンプを割り当てられうる。ただし、その前に、全てのロックが解放されてなければならない。
あるトランザクションでは、 Spanner は、Paxos が Paxos の write に割り当てたタイムスタンプ、これはトランザクションのコミットを表しているのだが、そのタイムスタンプを割り当てる。
Spanner は、次のような、単調性の原則にディペンドしている。
それぞれの Paxosグループの内部では、 Spanner は、リーダーをまたいでさえ、Paxos write に単調増加する順番にタイムスタンプを割り当てる。
一つのリーダーのレプリカは、自明なことだが、単調増加順にタイムスタンプを割り当てられる。
この原則は、リーダーをまたいで、分離性の原則を利用することで、強められる。
リーダーは、リーダーのリースの期間の範囲の中でのみ、タイムスタンプを割り当てることが出来る。
タイムスタンプ s が割り当てられた時、 s は、最大、分離性が保存されるまでしか進められない。
整合性の原則： もし、トランザクション T2 のスタートが、
トランザクション T1 のコミットよりもあとであるなら、 T2 のコミットのタイムスタンプは、 T1 のコミットのタイムスタンプより大きいものでなければならない。
トランザクション Ti のスタートとコミットのイベントを e_i^start と e_i^commit としよう。そして、トランザクション Ti のコミット・タイムスタンプを s:i としよう。
この原則は、次のようになる。 t_{abs}(e_1^commit) < t_{abs}(e_2^start) ⇒ s_1 < s_2
トランザクションを実行し、タイムスタンプを割り当てるプロトコルは、 Start とCommit wait という二つのルールに従う。それは、これらは、以下に示すように、一緒になって、この原則を保証する。
Start ルール 協調リーダーに Ti の write のコミットのリク
エストが到着するイベントを、 e_i^serverとしよう。
Ti write の協調リーダーは、 e_i^server 以降に計算された TT.now.latest よりも、小さくない値を、コミット・タイムスタンプ s:iを割り当てる。
ここでは参加者リーダーは、関係ないことに注意しよう。 4.2.1節で、次のルールの実装で、彼らがいかに巻き込まれるかを記述する。
Commit Wait ルール 協調リーダーは、 TT.after(s_i) が真になるま
でクライアントは Ti でコミットされたデータが見えないことを保証する。
Commit wait は、 s_i が、 Ti のコミットの絶対時間より小さいことを保証する。すなわち、s_i < t_{abs}(e_i^commit) である。
Commit wait の実装は、 4.2.1節で記述される。
Proof: s_1 < t_{abs}(e_1^commit )
(commit wait) t_{abs}(e_1^commit) < t_{abs}
(e_2^start ) (assumption) t_{abs}(e_2^start) <= t_{abs}
(e_2^server ) (causality) t_{abs}(e_2^server ) <=s_2
(start) s_1 < s_2
(transitivity)
4.1.3 Serving Reads at a Timestamp
4.1.2節で記述した単調性の原則は、 Spanner が、ある read を満たすように、レプリカの状態が十分更新されているかを、正しく決定することを可能にする。
全てのレプリカは、セーフ・タイム t_safe と呼ばれる値をチェックする。それは、レプリカが更新された最大のタイムスタンプである。
レプリカは、もし、 t <= t_safe であるタイムスタンプ t でならば、 read を満たす。
t_safe = min(t_safe^Paxos, t_safe^TM)
とする。ここで、それぞれの Paxos状態マシンは、セーフ・タイム t_safe^Paxos を、それぞれのトランザクション・マネージャは、セーフ・タイム t_safe^TM を持っているとする。
t_safe^Paxos は単純である。それは、もっとも最近適用された Paxos write のタイムスタンプである。 なぜなら、タイムスタンプは単調に増加し、 write は順番に適用されるから。 Paxos に関しては、 writeは、 t_safe^Paxos 以下ではもはや起きることはない。
t_safe^TM は、もし準備された（ただしコミットされていない）トランザクション -- すなわち、 two-phase commit の二つのフェーズの途中にあるトランザクションがゼロであれば、レプリカでは ∞ である。
(参加しているスレーブでは、 t_safe^TM は、実際に、レプリカのリーダーのトランザクション・マネージャを参照している。この状態をこのスレーブは、 Paxos write で渡されたメタデータを通じて推論出来る。）
もし、このようなトランザクションが一つでもあるなら、その時、これらのトランザクションによって影響を受ける状態は、「不定」である。参加者のレプリカは、これらのトランザクションがコミットされたのかを、未だ、知らない。
4.2.1節で議論したように、コミット・プロトコルは全ての参加者が準備段階のトランザクションのタイムスタンプの下限を知っていることを保証する。
全ての参加者のリーダーは（あるグループ g にとって）、トランザクション Ti に対して、準備タイムスタンプ s_{i,g}^prepare を、その準備レコードに割り当てる。
協調リーダーは、トランザクションのタイムスタンプが、全ての参加グループ上で、 s_i >= s_{i,g^}prepare であることを保証する。 それゆえ、グループ g の全てのレプリカにとって、 g で準備された全てのトランザクション T_i 上で、t_safe^TM = min_i(s_{i,g}^prepare) – 1 である。
4.1.4 Assigning Timestamps to RO Transactions
read-only トランザクションは、二つのフェーズで実行される。
まず、タイムスタンプ sread を割り当て、ついで sread でのスナップショット read として、トランザクションの read を実行する。
スナップショット read は、十分にアップデートされた、全てのレプリカで実行可能である。
トランザクションがスタートしてからの後であれば、どんな時間でも、 write について4.1.2節でおこなったのと類似の議論によって、単純な割り当て sread = TT.now().latest は、外的な整合性を保存する。
しかし、こうしたタイムスタンプは、もし、t_safe が十分に進んでいない場合、 s_readでのデータの read の実行にブロックを要求することがある。（加えて、 s_read の選択は分離性を保存する為に、 s_max を進ませるかもしれないことに留意）
ブロックの機会を減らす為には、 Spannerは、外的整合性を保証するもっとも古いタイムスタンプを割り当てるべきである。 4.2.2節で、どのようにこうしたタイムスタンプが選ばれるかを説明する。
4.2 Details
この節では、以前には省かれた、 read-write トランザクションと read-only トランザクションの実践的な詳細について説明する。同時に、アトミックなスキーマの変更の際に利用される特別なトランザクションについて述べる。そして、これまで述べた基本的なスキーマの精密化について述べる。
4.2.1 Read-Write Transactions
Bigtable と同じように、トランザクションの間に起きた write は、クライアントでコミットされるまでバッファーに置かれる。その結果、トランザクション中の read は、 write トランザクションの影響を見ることが出来ない。
このデザインは、 Spanner ではうまく機能している。なぜなら、 read は、読み込まれたどんなデータでもタイムスタンプを返すのに、コミットされていない write は、まだ、タイムスタンプを持たないからである。
read-write トランザクション中の read は、デッドロックを避ける為に、 wound-wait を利用する。
クライアントは適当なグループのレプリカのリーダーに、 read を発行する。それは、 read ロックを獲得してから、もっとも最近のデータを読む。
クライアントのトランザクションがオープンな間、クライアントは、参加者のリーダーがそのトランザクションをタイムアウトしないように keepalive メッセージを送る。
クライアントが全ての read と write のバッファリングを終えたとき、 two-phase commit を始める。
クライアントは調整グループを選び、それぞれの参加者リーダーに、調整者の ID と全てのバッファーされている write とともに、コミット・メッセージを送る。
クライアントが two-phase commit を走らせることで、広域のリンクで、データを二度送ることを避ける。
調整者ではない参加者リーダーは、最初にwrite ロックを獲得する。
それから、以前のトランザクションで割り当てられたどのタイムスタンプよりも大きな値を持つ準備されたタイムスタンプを選び（単調性を保存するため）、 Paxos を通じて準備されたレコードをログに書き込む。
その時、全ての参加者は、準備したタイムスタンプを調整者に通知する。
調整者のリーダーも、最初に write ロックを獲得するが、準備のフェーズはスキップする。調整者は、全ての参加者のリーダーから聞いてから、トランザクション全体のタイムスタンプを選ぶ。
コミットのタイムスタンプ s は、全ての準備のタイムスタンプより大きいか等しい（ 4.1.3 で議論された制約を満たすため）もので、調整者がコミットメッセージを受け取った時点での TT.now().latest より大きく、かつ、リーダーが以前のトランザクションに割り当てた全てのタイムスタンプより大きい（再び、単調性を保存する為に）ものでなければならない。
調整リーダーは、 Paxos を通じてコミット・レコードをログする。（あるいは、もし、他の参加者を待っている間にタイムアウトになれば、 abort する）
どんな調整レプリカがコミット・レコードを適用することを許す以前に、調整リーダーは、 TT.after(s)まで待つ。こうして、 4.1.2 で述べた、 commit-wait ルールに従う。
調整リーダーは TT.now().latest に基づいてタイムスタンプを選ぶので、今度は、タイムスタンプが過去に属することが保証されるまで待つ。期待される待ち時間は、最小で、 2 ∗ ε である。 この待ちは、典型的には、 Paxos の通信とオーバーラップしている。
commit wait の後で、調整者は、クライアントと全ての参加リーダーに、コミットのタイムスタンプを送る。それぞれの参加者は、 Paxos を通じてトランザクションの出力をログに書き込む。全ての参加者は、同じタイムスタンプを適用し、そしてロックを解除する。
4.2.2 Read-Only Transactions
タイムスタンプを割り当てるには、 read にかかわる全ての Paxosグループの間で、交渉のフェーズが必要である。その結果、 Spanner は、全ての read-only トランザクションに対して、ある範囲の表現を要求する。それは、全てのトランザクションによって読まれるであろう、キー達を要約した表現である。 Spanner は、単独のクエリーに対して、自動的にその範囲を推論する。
もし、このスコープの値が、一つの Paxosグループによってサーブされるのなら、そのクライアントはそのグループ・リーダーに、 read-only トランザクションを発行する。（現在の Spanner の実装は、 Paxosリーダーのもとでは、 read-only トランザクションのタイムスタンプしか選べない）
そのリーダーは、 s_read を割り当て、 readを実行する。一つのサイトでの read では、Spanner は、一般的には、 TT.now().latestよりはましな仕事をする。
LastTS() を、ある Paxosグループで最後にコミット write された最後のタイムスタンプとしよう。
もし、準備中のトランザクションがないのなら、割り当ては、 s_read = LastTS()で、 s_read = LastTS() で、自明のことだが、外的整合性を満たす。このトランザクションは最後の書き込みの結果を見ていて、それゆえに、その後に順序付けられている。
もし、スコープの値が、複数の Paxosグループによってサーブされているなら、いくつかの選択肢がある。もっとも複雑な選択肢は、全てのグループ・リーダーと一回り LasTTS() に基づいた s_read についてコミュニケーションを行うことである。
Spanner は、現在は、単純な選択を実装している。クライアントは一連の交渉を避けて、その read を s_read = TT.now().latest で実行させる。 ( それは、safe time が来るまで待たないといけない）
トランザクションのすべての read は、十分にアップデートされたレプリカに送られることが出来る。
4.2.3 Schema-Change Transactions
TrueTime は、 Spanner に、アトミックなスキーマの変更のサポートを可能にする。それは通常のトランザクションでは実行が難しいだろう。なぜならば、参加者の数（データベース内のグループの数）が、数百万になりうるから。
Bigtable は、一つのデータセンター内で、アトミックなスキーマの変更をサポートしていたが、ただ、そのスキーマ変更は、全ての操作をブロックした。
Spanner のスキーマ変更トランザクションは、一般的には、通常のトランザクションのブロックしない変種である。
第一に、それは未来のタイムスタンプを、はっきりと割り当てる。それは準備フェーズで登録される。その結果、数千台のサーバーをまたいだスキーマの変更は、他の並行する活動に、最低限の障害をもたらすだけで完遂されうる。
第二に、暗黙のうちにスキーマにディペンドしている read と write は、全ての登録されている時間 t のスキーマ変更のタイムスタンプと同期する。それらは、そのタイムスタンプが、 t に先行していれば、前に進むが、もしそのタイムスタンプが t の後で、スキーマ変更のタイムスタンプの後ろだとブロックしなければならない。 TrueTime なしでは、スキーマ変更が、時間 t で起きると定義することは無意味である。
4.2.4 Refinements
先に定義された t_safe^TM は弱点を持っている。一つの安全な準備段階のトランザクションが、 t_safe を進めることを妨げる。その結果、後のタイムスタンプを持っているread は実行出来ない。たとえ、その read がそのトランザクションと競合することがなくても。
こうした偽の競合は、キー範囲から準備段階のトランザクションのタイムスタンプへの細かい精度でのマッピングで、 t_safe^TM を増やしてやることで、取り除くことが出来る。
この情報は、ロック・テーブルに格納出来る。ロック・テーブルは既に、キー範囲をロック・メタデータにマップしている。 read が到着した時、キー範囲の高精度のタイムスタンプについて、それがその read と競合するかチェックするだけでいい。
先に定義した LastTS() も似たような弱点を持っている。もし、トランザクションがコミットしたばかりなら、競合しない read-only トランザクションも、そのトランザクションの後に続くように、 sread を割り当てられる。その結果、 read の実行は遅らせられることがあり得る。
この弱点は、同様に、ロック・テーブル内のキー範囲からコミット・タイムスタンプへの高い精度のマッピングで、 LastTS() を増加させてやれば手当が出来る。（我々は、まだ、この最適化を実装していない）
read-only なトランザクションが到着したら、トランザクションが競合する場合には、競合する準備段階のトランザクションがないなら（それは、高精度のタイムスタンプから決定出来る）、 LastTS() の値の最大値を取ることで、タイムスタンプを割り当てることが出来る。
先に定義した t_safe^Paxos も、 Paxos write が不在では先に進めないという点で弱点を持っている。すなわち、時間 t でのスナップショッ t_read は、 その最後の writeが t 以前に起きた Paxos グループでは実行されない。
Spanner は、この問題に、リーダーのリースの間隔の分離性の利点を利用することで対応する。
それぞれの Paxosリーダーは、未来の writeタイムスタンプが起きるようにしきい値を保ちながら、 t_safe^Paxos を前に進める。
それは、 Paxos のシーケンス数 n から、 Paxos のシーケンス数 n + 1 で割り当てられる最小のタイムスタンプへのマッピングである、 MinNextTS(n) を維持している。
レプリカは、 n を通じて適応されたとき、 t_safe^Paxos を MinNextTS(n) − 1 に進められる。
単独のリーダーは、 MinNextTS （）の約束を簡単に実行出来る。なぜなら、 MinNextTS （）で約束されたタイムスタンプは、リーダーのリースの期間の中にあるからである。分離性の原則は、リーダーをまたいで MinNextTS （）の約束を実行する。
もし、リーダーが、リーダーのリースの終点を超えて MinNextTS （）を進めることを望むなら、まず、リースを延長しなければならない。分離性を保存する為に、 s_max は常に MinNextTS （）の最大値より進んでいることに留意。
リーダーは、デフォールトでは、 8 秒おきにMinNextTS （）の値を進める。こうして、準備段階のトランザクションがなくても、アイドル状態の Paxos グループの正常なスレーブは、最悪ケースでも８秒古いのよりも大きなタイムスタンプ read をサービス出来る。
リーダーは、また、スレーブからの要求に応じて、 MinNextTS （）を進めることがある。