Your SlideShare is downloading. ×
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?

3,055

Published on

Published in: Technology
0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,055
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
66
Comments
0
Likes
19
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 大規模分散システムの現在 GFS, MapReduce, BigTableはどう進化したか @maruyama097 丸山不二夫
  • 2. Agenda  大規模分散システムの成立  すべては、ここから始まった GFS, MapReduce, BigTable  GFSからGFS2へ  Caffeine 新しい検索システム  Dremel インタラクティブなデータ分析  Spanner 新しい分散データベース  Knowledge Graph 新しい検索技術  資料編
  • 3. 大規模分散システムの成立 21世紀の初頭、かってない巨大な規模の分 散システムがネットワーク上で稼働を始めた。 現在のITを領導しているのは、こうした大規 模分散システムを所有し、その上でサービス を提供しているGoogle, Amazon, Apple, Facebookといった企業達である。
  • 4. Google
  • 5. Amazon
  • 6. Apple
  • 7. Facebook
  • 8. Microsoft
  • 9. Google Google
  • 10. Google
  • 11. Google
  • 12. Facebook
  • 13. Microsoft
  • 14. クラウドとクラウド・デバイスの時代  クラウドの時代は、21世紀になってから本格的に 始動した。すぐ後を追って、クラウド・デバイスの 時代が始まった。  2004年 Google上場  2004年 Google GFS,MapReduce,BigTable の論文公表  2006年 Amazon EC2, S3  2007年 Apple iPhone  2008年 Microsoft Azure  2008年 Google Android  2012年 Facebook上場
  • 15. Googleの社是とスタンス  全世界の情報を、組織し、アクセス可能にすると いう夢は、ほとんど達成可能なところにまで来て いる!  “我々は、検索を人々の役に立つようにするという ビジネスをしている。インフラを売るビジネスをし ている訳ではない。” --- Lipkovitz, Google
  • 16. Facebookの社是とスタンス  Facebookは、本来、会社となるために作られた ものではなかった。それは、次のような社会的使 命を達成するために作られた。 世界を、もっとオープンで、つながったものに!  このテクノロジーと、構築されるべきインフラの規 模は、前例のないものです。私たちは、これこそ が私たちが集中することの出来る、もっとも重要 な問題だと確信しています。 -- 「Facebook上場申請文書」
  • 17. 現代の大規模分散システムが ハンドルするデータの規模
  • 18. 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 = 40PB
  • 19. Facebook       毎月のアクティブ・ユーザ 8億4500万人 一日の投稿 25億 一日の「いいね」 27億 一日にアップロードされる写真 3億枚 Facebook上の友人関係 1000億 30分ごとに105TBのデータがスキャンされる。
  • 20. Big Dataは、大きいか小さいか? 1K 1,000人 千人 1M 1,000,000人 百万人 1G 1,000,000,000人 十億人 世界人口 7G人 世界の一人一人に、2バイトコードで、1000字程 度の個人情報のプロファイルを与えるとすると、 2 x 8 x 1K x 7G = 2 x 7TBのディスクがあれ ばいい。  日本人一億人なら、200GBで十分。今なら2Tの ディスクが、秋葉原で一万円で買える。     
  • 21. Windows Azure SQL データベース の最大容量は、150G
  • 22. Amazon DB インスタンス
  • 23. なぜ、大規模分散システムに 注目する必要があるのか?
  • 24. なぜ、大規模分散システムに 注目する必要があるのか?  大規模分散システムが取り組んでいるのは、 Web上のネットワーク・メディアの発展によって、 止まることなく増え続けるアクセスと情報の増大 の中で、リアルタイム性を追求するという、現代の IT技術のもっとも重要な課題である。  大規模分散システムは、新しいネットワーク・マー ケットの台頭の中で、大規模の情報をハンドルし ながらリアルタイム性を志向し、同時に、正確なト ランザクションを担保することを求められている。 これらの課題は、技術的に挑戦的なものである。
  • 25. なぜ、大規模分散システムに 注目する必要があるのか?  重要なことは、こうした技術的な探求が、新しい サービスの開発をめぐる、ビジネスの競争によっ てドライブされていることである。  サービス利用者から見て”Publicクラウド”と言わ れるものは、ビジネスの主体からみれば、 Google、Amazon、Microsoft...らが「所有」す る”Privateクラウド”であると考えることも出来る。  彼らのビジネスの力の一つは、大規模分散シス テムを開発し運用し、新しいサービスを提供し続 ける技術的な力にある。
  • 26. なぜ、大規模分散システムに 注目する必要があるのか?  また、現代のITビジネスの競争力の中核の一つ は、大規模分散システムでのみ提供可能なサー ビスにある。検索サービス、エンタープライズ向け クラウド・サービス、ソーシャル・ネットワーク・サー ビスは、その代表的なものである。  ただ、現在の大規模分散システムは、その力を全 面的に開花させている訳ではない。それは発展 途上にある。また、それによって提供可能な新し いサービスも、今後、続々と登場してくるであろう。 そこには、ビジネス的にも、もっと大きな可能性が ある。
  • 27. なぜ、大規模分散システムに 注目する必要があるのか?  一般の企業・一般の開発者にとっても、こうした技 術は無縁ではない。それが現代の技術とビジネ スの課題を反映したものである以上、そこから派 生した技術は、遅かれ早かれ、時代のIT技術に 深い影響を与えていくだろうから。
  • 28. Googleの大規模分散技術 21世紀のクラウドとクラウド・デバイスの時代 を牽引してきたのはGoogleである。Google は、大規模分散処理のシステム技術において もいまだ卓越した地位を占めている。彼らは、 処理のリアルタイム化・正確なトランザクション の実現にむけて、そのインフラ技術の見直し をすすめている。
  • 29. すべては、ここから始まった  2003年 The Google File System  2004年 MapReduce  2006年 BigTable
  • 30. The Google File System GFSは、安価なPCサーバからなるクラスタ上に構築 された分散ファイルシステムである。クラスタは、 2,000台以上のchunkserverからなり、Googleに は、30以上のClusterがある。 GFSは、ペタバイトサイズのファイルシステムであり、 read/write 2,000MB/s 以上の性能がある http://209.85.163.132/papers/gfs-sosp2003.pdf
  • 31. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System Gobioff氏は、2008年3月11日、悪性リンパ腫で亡くなった。
  • 32. GFS Architecture Application (file name,chunk index) GFS Master /foo/bar Chunk 2ef0 File NameSpace GFS Client (chunk handle, chunk location) Instruction to chunkserver Chunkserver state (chunk handle,byte range) GFS chunkserver GFS chunkserver Linux File System Linux File System chunk data ・・・・ ・・・・ ・・・・
  • 33. MapReduce: Simplified Data Processing on Large Clusters MapReduce は、関数型のプログラミン グ・モデルに基づいた、大規模なデー タ・セットの処理・生成を行う http://209.85.163.132/papers/mapreduce-osdi04.pdf
  • 34. Jeffrey Dean and Sanjay Ghemawat MapReduce: Simplied Data Processing on Large Clusters
  • 35. Master Worker Partition0 Partition1 Split 0 Split 1 Split 2 Worker Worker Worker 入力ファイルと その分割 Output file1 Partition0 Partition1 Split 3 Split 4 Output file0 Worker Partition0 Partition1 Mapの フェーズ Local Disk上の 中間出力ファイル Reduceの フェーズ 最終出力 ファイル
  • 36. Bigtable: A Distributed Storage System for Structured Data Bigtable は、数千台のサーバ上のペタ バイト単位の非常に大きなサイズにまで スケールするようにデザインされた、構 造化されたデータを管理する、分散スト レージ・システムである。 http://209.85.163.132/papers/bigtable-osdi06.pdf http://video.google.com/videoplay? docid=7278544055668715642&q=bigtable
  • 37. 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
  • 38. Bigtable Client BigTableシステム構成 Bigtable Client Library Open Bigtable セル Bigtable Master メタデータのオペレーションを実行 ロードバランシング Bigtable Tablet Server Bigtable Tablet Server Bigtable Tablet Server サーバデータ サーバデータ サーバデータ Cluster Sheduling System フェイルオーバのハンドリング モニタリング Google File System タブレットデータの 保持 ログ Chubby Lock Service メタデータ保持、 マスター選定のハンドリング
  • 39. GFSからGFS2へ 2009年、GoogleはGFSのデザインの見直し を示唆。バッチ・システムの効率を上げる為に デザインされた、シングル・マスターのGFSは、 分散マルチ・マスターのシステムに変わる。 同時期に開発が始まったMegastoreは、現 在のGoogleのサービスの主力になる。
  • 40. 2009年7月、Google大規模障害
  • 41. 2009年7月、Google大規模障害  2009年7月2日, 6:45 AM から12:35 PM ま で、Google App Engineに大規模な障害発生。  この障害の根本的な原因は、データセンタ内の ノードが、サーバー側できちんとしたチェックを行 わずに、不適切に構成されたFileHandleを送り つけたことに起因するGFS Master serverのバ グであった。これを処理しようとして、Masterは、 スタック・オーバーフローを起こした。
  • 42. 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.
  • 43. 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, and that thus the Datastore is not usable in the primary datacenter at that time.
  • 44. 2009年9月、Bigtableの見直し  2009年9月14日、Ryan Barrettは、“Migration to a Better Datastore”を発表 http://googleappengine.blogspot.jp/2009/09/mig ration-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.
  • 45. 2011年1月 Megastore: Providing Scalable, Highly Available Storage for Interactive Services  http://www.cidrdb.org/cidr2011/Papers/CIDR1 1_Paper32.pdf cf. 日本 2012年6月20日 ファースト・サーバー社事故
  • 46. Megastore
  • 47. MegaStore  Megastoreを利用したよく知られたGoogleのア プリには、次のものがある。      Gmail Picasa Calendar Android Market AppEngine
  • 48. HDFSのAvatar Node  ちなみに、Facebookが、HDFSのMaster Nodeの二重化、いわゆ、Avatar Nodeの実装 の次の論文を発表したのは、2011年の SIGMODでのことであった。  “Apache Hadoop goes Realtime at Facebook” http://dl.acm.org/citation.cfm?id=19894 38&bnc=1
  • 49. GFS: Evolution on Fast-forward 事故直後の2009年8月1日、Sean Quinlanは、ACMとのインタビューに応え、 GFSのデザインの見直しを示唆。 http://queue.acm.org/detail.cfm?id= 1594206
  • 50. GFS: Evolution on Fast-forward  GFSの単一マスターで行くという決定は、実際に は、設計の非常に早い段階でなされたものだ。主 要には、デザインをシンプルなものにするというの が、その理由だ。  ただ、問題は、すぐに起きていた。ストレージの容 量が、数百テラからペタバイトに、さらには数十ペ タに増大するにつれて、マスターが維持しなけれ ばならないメタデータの割合は、増えていった。
  • 51. GFS: Evolution on Fast-forward  同様に、データのボリュームとともに、リカバリー のデータを探す為にメタデータをスキャンするとい うような操作がリニアなスケールで増えていく。こ うして、マスターに要求される仕事の量は、本質 的に増大する。
  • 52. GFS: Evolution on Fast-forward  GFSが、いまや、多くの挑戦にさらされているの は、疑問の余地はない。一例を挙げれば、不断に 増大するユーザーの大群と直面していて遅延が 大きな問題となるアプリケーションを、本来は、 バッチ・システムの効率を上げる為にデザインさ れたシステムの上でサポートしていることの、不 格好さは、誰の目にも明らかである。
  • 53. GFS: Evolution on Fast-forward  BigTableの登場は、この点では、いくらかの助け にはなった。ただ、明らかになったのは、 BigTableは、実際には、GFSとは、最良の組み 合わせではなかったということだ。事実、この組み 合わせは、GFSシステムの単一マスターのデザ インのボトルネックとしての限界を、他の場合より も、はるかに明らかなものとしただけだった。
  • 54. GFS: Evolution on Fast-forward  これした理由から、Googleの技術者達は、過去 2年間というもの、BigTableの利点を最大限生 かしながら、現GFSに取っては特に困難であると 証明されているいくつかの問題を攻略する、新し い分散マスターシステムのデザインに取り組んで きた。
  • 55. 問題  マスターは、秒あたり数千の処理しか終えること が出来ない。  MapReduceは、かなりの数のファイルをオープ ンしようとする、千ものタスクを走らせるかもしれ ない。
  • 56. 現在の実装 Cellあたり一つのマスター  歴史的には、データセンターに一つのCellという のが目標だったが、結局、multi-cellアプローチ をとった。  データセンターに複数のCellがある。ネットワーク をまたいで、複数のCellは、関連づけられた、た だし異なったファイルシステムとして機能する。
  • 57. 現在の実装 複数のGFSマスター  chunk サーバー群の上に、複数のGFSサー バーを置く。  配下のストレージ・プールが、複数のGFSマス ターを持つように設定出来る。  異なったCellをまたいだデータの分割には、アプ リケーションが責任を持つ。
  • 58. 現在の実装 Name Space  それぞれのアプリケーションが、マスターを持つと しよう。(一つか、少数のマスターを)  Name Spaceが、これらを全てをアプリケーショ ンから隠す。namespaceを分割する静的な方法  ログ処理システムでは、いったん一つのCellのロ グを使い果たすと、複数のGFS Cell に移動する。  Namespaceファイルは、ログ・データが、異なる Cellをまたがって分割されているかを記述する。
  • 59. 現在の実装 マスターのパフォーマンスチューニング  最終的には、マスターのパフォーマンスのチュー ニングにかなりの努力をした。特定のバイナリー のチューニングに多くの力を注ぎ込むのは、 Googleでは、あまりないことである。  一般的に、我々のアプローチは、ほどほどに動く ようになったら、スケールさせることにフォーカス するというものだ。これはたいていはうまく機能し て、一般的には、スケールさせることでパフォーマ ンスが得られる。
  • 60.  この例の場合には、インパクトを持ち始めた一つ のボトルネックがあったわけだが、我々は、マス ターの負荷を軽くすることに、更に努力することが 価値があると感じていた。  数千の処理から、数万の処理にスケールした時 点で、マスターは、ボトルネックになった。
  • 61. ふりかえり  GFSは、記録的な短期間で製品化された。 3人 のチームが、一年足らずで配備にまでこぎ着けた。 GFSが稼働している最大級のファイル・システム であることを想起してほしい。  開発スピードの優位性は、Googleに、巨大な成 長を可能にした。
  • 62.  GFSの機能を最初に利用したのは、 大規模なク ローリングとindexシステムだった。  GFSの利用の第二の波は、大規模なデータを格 納することだった。GFSは、この新しいユースケー スにも適応出来るように調整された。  様々なアプリケーションが、GFSをイメージして開 発されるようになった。
  • 63. Additional problems  急速な成長の中で、64MBのチャンク・サイズが 問題になった。Googleが扱うデータが巨大な為 になされたものであったが、Gmailのように、多く のファイルは、64MB以下で十分だった。  ファイル数のカウントは、また、別の問題になった。 ログの数が増え続けた。フロントエンドのサー バーはログを書き出すのだが、それがクラッシュ すると、更に大量のログを吐き出す。それは、想 定よりはるかに大きなデータだった。
  • 64. Additional Improvements  ファイル数の増大が問題だった。マスターのメモ リーが枯渇する前に、調整可能なのは、高々限ら れた数のファイルだ。  それぞれのファイルについて、メモリーに格納さ れるメタデータが必要になった。ファイル名とチャ ンクの情報。  もし、平均的なファイルサイズが、64MB以下で あれば、ストレージに対するマスター上のオブジェ クトの数の比率は低下する。
  • 65.  この問題に対応する為に、オブジェクトを大きな ファイルにまとめ、その内容のテーブルを作った。  また、ファイル数とストレージの容量にquotaをか けた。大体、引っかかるのはファイル数のquota の方だった。
  • 66. Additional Improvements  全面的に新しいデザインの作業を始める。  分散マルチ・マスター・モデル。  1MBの新しいファイルサイズ。  ファイル数問題への対応  一万個の10KBのファイルを読む方が、100個の1MB のファイルを読むより、シークに時間がかかる。  一つのマスターに100M個のファイル。数百のマス ターという構成。
  • 67. BigTable 構造化されたデータの分散ストレージ  ファイル数の増大に対する対応策–小さなものを集約する  数千台のマシンをまたぎ、ペタバイトまでスケールする。  GFS上に構築され、GFS上で稼働し、GFSの原理と矛盾が ないように設計された。  アプリケーションにも見られるが、実際には、インフラの一 部  システムのエラーに非常に敏感に対応  クローリングとindexシステムに利用された  沢山の小規模なデータを利用するアプリは、BigTable を使う  BigTableは、単にファイル数問題を扱うために設計さ れたものではない。それ以上の意図があった
  • 68. BigTable  もともとのアイデアは、SSTableとログ、たった二 つだけの基本構造を持つというものだった。 SSTables– Stored String Tables (key-value pair)  BigTableは、mutableなログと、データを圧縮し たimmutableなSSTableの上に構築された。  GFSには、どんなデータでも書き込みが出来る。 しかし、大部分のユーザーは、結局、BigTable の二つのデータ構造、SSTableとログを使うよう になった。
  • 69. More initial GFS limitations/ improvements  初期のGFSは、低い遅延の上に、高帯域(高ス ループット)を実現するようにデザインされていた。  バッチのアプリケーションでは、Single point of failureも許される。  ただ、ビデオのサービスでは、そうはいかない。
  • 70.  GFSでは三重化されたファイルに書き出すのだ が、もし、chunkserverが死んだり、調子が悪く なると、一つのchunkのレプリカを作る。この作業 に10秒から一分かかる。  大規模なMapReduceの処理ならそれでもいい が、Gmailでは、一分の遅れは受け入れられな い。  初期のマスターのフェイル・オーバーには、数分 かかっていたが、今では、それは数十秒に短縮さ れた。
  • 71. More initial GFS limitations/ improvements  MapReduceベースの世界から、BigTableのよ うなものに依存したインタラクティブな世界に移行 すること。  バッチ志向の処理用にデザインされたファイルシ ステムの上に、インタラクティブなDBを構築する ことは、挑戦的な課題だ。
  • 72.  Bigtable – トランザクション・ログがボトルネック。  二つのログファイルを同時に開いて、一つに書き込む。 それがいっぱいになったら、もう一つに書き出し、最後 にマージする。  Gmail は、マルチ・ホーム  Gmailアカウントの一つのインスタンスが不調になっ たら、他のデータセンターに移る。(これは、可用性を 高めるのを助ける)
  • 73. Compatibility issues:  ドライバーとドライブのミスマッチが、データ破壊を 引き起こした(全てのIDEプロトコルのバージョン をサポートしていなかった)  厳格なチェックサムの実行が必要  でも、少しデータの読み込みが遅れるのはOKである  これらの対策は、マスターに新しいデータを追加 して、もっと沢山の状態を管理することで可能に なった。
  • 74. Consistency Issues  あるファイルを複数回読むと、異なるデータが返 ることがある。  GFSは、全てのデータが全てのレプリカに書き出 されないと、次に進まない。問題は、クライアント がクラッシュした時に起きる。
  • 75. Consistency Issues  RecordAppend 複数のライターがログに追加 出来る。ゆるい整合性。  全てのレプリカが書き込まれたという保証がない。 データは、チャンクに一度以上、違った順序で、違った チャンクに書き込まれうる。等々。  問題があれば、新しいプライマリーが新しいオフ セットを取り出す。  ファイルを指定出来ない  ゆるい整合性は、価値があるというより苦痛になる  ファイルあたり単一の書き込み、順番付けされた書き 込みが、整合性の為には必要である。
  • 76. Initial GFS aspect that still works Snapshot of chunk  レプリカを置き換える  クライアントが書き込めないロックを取り消す  GFSは、snapshot機能もサポートしている – clone  非常に強力なのに、広くは利用されていない  実装が難しい。ただ、本当のsnapshotとして、実装を 試みた。
  • 77. 結論  GFSの成績表は、10年経った今でも、ポジティブ である。  成功によってではなく、まだ力を発揮しているとい う点で。  スケールもアプリケーションも、1990年代後半の 想像をはるかに超えている。
  • 78.  チャレンジなのは、ユーザーを前にした、遅延に 敏感なアプリケーションを、バッチのスループット の為にデザインされたシステムの上でサポートす ること。  BigTableは助けになった。しかしそれは、GFSと ぴったりあっていた訳ではない。むしろそれは、ボ トルネックの限界を、明らかにした。  BigTableの利点を最大限生かした、分散マス ターのシステムをデザインすること。
  • 79. Caffeine Googleの新しい検索システム 2010年6月、Googleは新しい検索システム Caffeineを稼働。MapReduceの利用を廃し て、BigTable上でリアルタイムにインデックス 付けを行う方式に移行。あわせて、BigTable のトランザクション処理に大幅な改良を加える。
  • 80. Our new search index: Caffeine 2010年6月8日 Google Webmaster Central Blog http://googlewebmastercentral.blogs pot.jp/2010/06/our-new-searchindex-caffeine.html
  • 81.  本日、Caffeineと呼ばれる新しいWebインデキ シング・システムが完成したことを報告します。 Caffeineは、Web検索で、以前のインデックスよ り50パーセント新しい結果を提供します。それは、 私たちが提供してきた中で、最大のWebコンテン ツのコレクションです。  それが、ニュースであれ、ブログであれ、フォーラ ムへの投稿であれ、それが公開されると、以前に 可能だったものよりはるかに早く、関連するコンテ ンツへのリンクを見つけることが出来ます。
  • 82.  では、なぜ、私たちは新しいインデキシング・シス テムを構築したのでしょうか? Web上のコンテ ンツは、開花の時期を迎えています。単にサイズ や数が増えたばかりではなく、ビデオや画像、 ニュースやリアルタイムに更新されるものが登場 し、普通のWebページもリッチで複雑なものに なっています。加えて、人々の検索に対する期待 も、以前に比べて高度なものになっています。検 索者は、最新の関連するコンテンツを見つけるこ とを望み、公開者は、公開した瞬間にでも、それ が見つかることを期待します。
  • 83. Webの進化に対応し、高まるユーザーの期待に応える為に、 私たちは、Caffeineを構築しました。この図は、古いインデキシング システムがどのように働いていたかを、Caffeineとの比較で図示 したものです。
  • 84.  古いインデックスは、いくつかの層を持っていまし た。そのいくつかは、他のものより早く更新されて いました。主要な層は、二週間に一回更新されて いました。古いインデックスの層を更新する為に は、Web全体を分析してきました。そのことは、私 たちがページを見つけるのと、それをユーザーに 利用可能にすることの間には、大きな遅れがあっ たことを意味します。
  • 85.  Caffeineでは、私たちは、Webの小さな部分を 分析し、検索インデックスを全体的には連続した ベースの下で更新します。新しいページ、あるい は、既存のページに新しい情報を発見すると、こ れらを直接インデックスに追加することが出来ま す。こうして、それがいつどこで公開されても、い まだかってなかった新鮮な情報を、ユーザーは見 つけることが出来るのです。
  • 86.  Caffeineでは、私たちは、巨大な規模でWeb ページのインデックス付けを行います。実際、 Caffeineは、毎秒 数十万のページをパラレルに 処理します。もし、それを紙で積み上げたら毎秒3 マイルの高さになるでしょう。Caffeineは、一つ のデータベースに約一億ギガバイトのストレージ をあてています。そして一日に数十万ギガバイト の割合で情報を追加しています。この情報を蓄え るには、大型のiPadが、625,000個必要です。 これを端から端にならべると、40マイル以上にな ります。
  • 87.  私たちは、Caffeineを未来を胸に抱いて構築し ました。単に新しい情報を与えるだけでなく、オン ライン上の情報の増大とともにスケールし、より関 連する検索結果をユーザーに届ける、さらに高速 で分かりやすい検索エンジンを構築する、それは 強固な土台なのです。ですので、期待して注目し てください。今後の数ヶ月のうちにも、さらなる改 良が行われることを。
  • 88. Google Caffeine jolts worldwide search machine 2010年6月9日 Interview with Matt http://www.theregister.co.uk/2010/0 6/09/google_completes_caffeine_sea rch_index_overhaul/
  • 89.  本質的には、Googleはバッチ型のインデックス・ システムから、その場でリアルタイムでインデック スを更新するシステムに移行したのだ。  「我々の技術は、ページをクロールするやいなや ページにインデックスをつけることを可能にした。 過去には、インデックスの更新の度に、Web全体 の分析を行っていたので、我々は大規模なバッチ で(しばしば数十億ページに及ぶ)ページにイン デックスをつけていた。Caffeineでは、Webの小 さな部分で分析が出来るので、 インデックスを連 続的に更新出来る。」
  • 90.  「このことは、次のようにも考えることが出来る。 我々は、数十億のドキュメントのインデックス付け のバッチから、(それぞれ一つの文書に対して)数 十億の「バッチ」を処理するシステムに変わったの だと」
  • 91. Google search index splits with MapReduce Welds BigTable to file system 'Colossus’ 2010年9月9日 Interview with Lipkovitz http://www.theregister.co.uk/2010/0 9/09/google_caffeine_explained/
  • 92.  新しい検索のインフラは、GFS分散ファイルシス テムの改修版を使用している。これは、Google File System 2、GFS2と呼ばれていたのだが、 Googleの内部では、Lipkovitzがいうように Colossusとして知られているという。  「Caffeineはデータベース・ドリブンで、BigTable を変化させたインデックス・システムである。 Googleは、このシステムを論じた論文を、来月 行われるUSENIX Symposium on Operating Systems Design and Implementation (OSDI) で発表する。」
  • 93.  「我々は、非常に膨大なデータから出発して、そ れを処理してきた。8時間かそれくらい後に、この 全体の処理の出力がなされる。その結果をまた、 サービス用のシステムにコピーする。我々は、そ うした処理を連続的に行ってきた。」  MapReduceは、Googleが望むように出来るだ け早くインデックスを更新することを、Googleに 許さなかった。リアルタイムWebの時代、Google は数秒のうちにインデックスを更新することを求 められていた。
  • 94.  過去数年の間、MapReduceは、MITのデータ ベースの権威 Mike Stonebraker のような 人々から批判を受けてきた。Lipkovitzによれば、 Google自身、大分前から「同じような認識」に到 達していたという。  「MapReduceは、リアルタイムに近い出来事に 必要な計算には、向いていない。MapReduceは、 一連のバッチ処理からなる。一般的には、最初の 処理が終わるまでは、次のフェーズあるいは次の 処理を始めることは出来ない。」
  • 95.  「MapReduceは、“おちこぼれ”の問題に悩まさ れていた。map-reduceの一連のシリーズに基 づいたシステムを作ろうとすれば、ある程度の確 率で、何かうまくいかないことが起きる。その確率 は、処理の数を増やそうと思えばそれだけ大きな ものになる。問題が起きた時、ほんの少しの時間 ですむ処理でさえも、何も出来なくなる。だから、 我々は、MapReduceを取り除いた。」
  • 96.  Caffeineでは、Googleは、既にBigTableに格 納されているWebマップを直接変更することで、 インデックスを更新出来る。このシステムは、 BigTable上で動く、あるフレームワークを含んで いる。Lipkovitzは、それを従来のデータベース・ プログラミングでの「データベース・トリガー」にた とえた。「それは完全にインクリメンタルだ。」 Googleは、新しいページがクロールされる度に、 全体を再構築することなく、必要に応じてインデッ クスを更新出来る。
  • 97.  「開発者が、BigTable上でコードを実行するのを 助ける “計算フレームワーク” もある。このシステ ムは、Clossusで土台を支えられている。 Clossusは、GFS2としても知られている分散スト レージプラットフォームだ。元のGFSは、Google が望むようにはスケールしなかった。」
  • 98.  Colossusは、BigTableの為に特別にデザインさ れたものだ。そうした理由によって、GFSがそう だったような「一般的な利用」には向いていない。 それは、特に新しいCaffeine検索インデックスシ ステムでの利用の為に作られたものだ。それでも、 他のGoogleのサービスに、あるかたちでは利用 されるかもしれない。ただ、それは、Googleのイ ンフラ全体にわたるものとしてはデザインされた たぐいのものではない。
  • 99.  「MapReduceは、決して死んだ訳ではない。 Caffeineでもバッチ処理を使うケースも存在する し、Mapreduceは、いまも他の沢山のGoogle のサービスのベースである。しかし、Caffeine登 場以前は、インデックス・システムがMapReduce の最大のアプリケーションであった。それで、この プラットフォームの利用は、大きく減少してきた。」
  • 100.  2004年に、GoogleはGFSとMapReduceにつ いての研究論文を発表した。これが、オープン ソースのHadoopプラットフォームの基礎になっ た。それは、Yahoo, Facebook, Microsoftに よって利用されている。しかし、GoogleはGFSと MapReduceを超えて進もうとしている。  「世界の残りの部分が、我々より遅れていると主 張するつもりはない。我々は、検索を役に立つも のにするビジネスをしている。インフラを売るビジ ネスをしている訳ではない。」
  • 101. Incrementally Indexing the Web with Percolator 2010年10月4日 Frank Dabek and Daniel Peng at OSDI, 2010 https://docs.google.com/presentation/d/1gKD4FbaUIGtoi mP6-ZB0iiW8V0KZt8fVET-Cfu5KiG8/present#slide=id.i0
  • 102. 問題:Webにインデックスをつける 出力: サービス用のドキュメント 入力: 元の生ドキュメント times.co m URL mit.ed u indexing In Links Body PageRank nyt.co m g.cn ... 1 ... 1 fark.com times.com ... 3 g.cn fark.co m times.co mit.edu m mit.edu times.com .... 7 fark.com, times.com
  • 103. MapReduceで重複を取り除く Reduce Map インデックス・システムは沢山のMapReducesの連鎖 ドキュメント 解析 チェックサ ムでグルー プ化 逆リンク
  • 104. MapReduceでのインデックスの更新 repository Map refresh • 新しいドキュメントにインデックスつけるべきか? o 新しいドキュメントは、以前にクロールした文書のコ ピーかもしれない。 o 全てのレポジトリーの再マップが要求される。
  • 105. インデックス・システムの目標 理想的なインデックス・システムに何を望むか?  大量のデータのレポジトリー  インデックスのサイズの上限まで  インデックスのより高い質(沢山のリンクとか)  クロールとインデックスの間の遅延の小ささ 「新鮮さ」 MapReduceのインデックス・システムは、クロール からインデックスまで、数日かかる。
  • 106. インクリメンタルなインデックス付け • ランダム・アクセス可能なレポジトリーを、 BigTableに保持する • グローバル・スキャンを避けるインデックス •インクリメンタルに複製可能な状態が、URLとして、 クロールされる URL Contents http://usenix.org/osd <html>CFP, i10 .... http://nyt.com/ <html>Lede ... Pagerank Checksum Language 6 0xabcdef01 ENGLISH 9 0xbeefcafe ENGLISH
  • 107. BigTable上のインクリメンタルな インデックス付け URL Checksum PageRank nyt.com 0xabcdef01 6 nytimes.com 0xabcdef01 9 IsCanonical? no yes Checksum Canonical 0xabcdef01 nytimes.com nyt.com 二つのURLを同時に処理すると、何が起きる?
  • 108. 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
  • 109. Bigtableの構造 Bigtableは整列された (row, column, timestamp) のストアである Column1 3: 2: RowOne 1: "I'm at timestamp 1" 3: RowTwo 2: 1: Column2 3: 2: "I'm at timestamp 2" 1: 3: 2: 1: Column3 3: 2: 1: 3: 2: 1: • データは行範囲でtabletに分割される • Tabletは、沢山のマシンに分散されている
  • 110. 分散トランザクションの実装 • snapshot isolation semanticsを与える • Multi-version protocol (Bigtableのtimestampにmap) • Two phase commit クライアントが調整する • Locksは、Bigtableの特別なカラムに入れられる "balance" Alice balance:data 5: 4: 3: $10 balance:commit 5: 4: data @ 3 3: balance:lock 5: 4: 3:
  • 111. Transaction Commit 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(); balance:data balance:data 5: $15 5: $15 Alice Alice 4: 4: 3: $10 3: $10 Ben Bob5: 5: $5 4: $5 3: $10 4: 3: $10 balance:commit balance:lock balance:commit balance:lock 6: data @ 5 6: 6: data @ 5 5: 5: lock 5: data @ 3 4: 4: 5: 3: 3: 4: 4: data @ 3 3: 3: 6: 6: data @ 5 5: lock 4: 4: 5: 5: data @ 3 3: 3: 4: data @ 3 4: 3: 3:
  • 112. Notifications: tracking work ユーザーは、"observer" をカラムに登録する カラム中の行に書き込みが起きると実行される それぞれのobserverは、新しいトランザクション で走る 書き込みごとに最大で一回実行される:メッセー ジの畳み込み Document • • • RawDocument RawDocumen Loader tLoader Document DocumentPr Processor ocessor DocumentPr Exporter ocessor DocumentPr LinkInverter ocessor アプリケーションは、一連のobserverのつながりと して構造化される
  • 113. Notificationsの実装 Dirty column: もしobserversが走るべき行なら設定 ランダム分散スキャン 中断している仕事を見つけ、observerをスレッドプール で走らせる スキャンは効率的である。数ビットをみるだけ • • No shards or work units: nothing to straggle Dirty? balance:data Alice Yes 5: $15 Bob No 5: $5 ...
  • 114. Running Percolator Each machine runs: Worker binary linked with observer code. Bigtable tablet server GFS chunkserver • • • Observer Code xN Percolator::RunWorker() Tablet Server GFS Tablet ... Server GFS Tablet Server GFS
  • 115. MR v. Percolator: Performance Operating Point Fraction of Repository refreshed / hour
  • 116. MR v. Percolator: Experience 我々は、MRベースのパイプラインをPercolatorに 変換した。 Pros: 新鮮さ: インデックスの遅延は数日から数分にまで落ちた スケーラビリティ: o 一層のスループット: もっと沢山のCPUを買えばいい o より大きなレポジトリー: ディスクスペースの制限のみ 運用面: 「落ちこぼれ」に耐性がある Cons: 並列性を考える必要がある ドキュメントあたりの処理コストが高価である(~2x) • • • • •
  • 117. Running 1000 threads on Linux Percolatorは、thread-per-request モデル Pros: アプリケーションの開発者は、ストレートなコードを書ける スタックトレースが重要 デバッグ、プロファイルが容易 メニーコア・マシンに容易にスケールする Cons: カーネルのスケーラビリティ:プロセスがexitする間、1000 個のスレッドが働いている時、カーネルロックが保持される ローカルスレッドのストレージの検出がライブラリーにない キャッシュ等とのロックの競合 • • • • • •
  • 118. 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
  • 119. 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 • •
  • 120. 結論 Percolatorは、“Caffeine” Web検索インデックス・シ ステムを構成している 50% 新鮮な検索結果 3倍大きなレポジトリー • • Webスケールの分散トランザクションの「存在証明」
  • 121. Large-scale Incremental Processing Using Distributed Transactions and Notifications Daniel Peng and Frank Dabek Presented by Nick Radcliffe http://courses.cs.vt.edu/cs5204/fall11butt/lectures/perculator.pdf
  • 122. 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.
  • 123. 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.
  • 124. 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.
  • 125. Overview of Percolator design  An observer is like an event-handler that is invoked whenever a userspecified 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.
  • 126. Large-scale Incremental Processing Using Distributed Transactions and Notifications 2010年10月4日 D Peng, F Dabek - OSDI, 2010 https://www.usenix.org/legacy/event s/osdi10/tech/full_papers/Peng.pdf
  • 127. Transaction in BigTable
  • 128.  c:data  c:lock データ自身を格納 コミットされていないトランザクションは、 このCellに書き込む。PrimaryLock の場所を含んでいる。  c:write コミットされた現在のデータ。 データのタイムスタンプを格納。  c:notify ヒント: observerが走る必要がある かもしれない  c:ack O Observer “O”が走った。最後に 成功した実行のタイムスタンプを格納。
  • 129.  初期状態: Joeの口座には2ドル、Bobの口座には、10 ドルが、はいっている。  bal:writeに、データのタイムスタンプが書き込まれること によって初めて、そのデータは外部から見えるようになる。
  • 130.  送金のトランザクションは、Lockカラムに書き込むことで Bobの口座の残高をロックすることから始まる。このロック は、このトランザクションのprimaryである。  このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。
  • 131.  トランザクションは、次にJoeの口座をロックして、ふたた び開始タイムスタンプ 7に、Joeの新しい残高を書き込む。  このロックは、このトランザクションのsecondaryである。 primaryロック(”Bob”行の”bal”カラム)への参照を含ん でいる。  クラッシュでこのロックが立ち往生して、トランザクションが ロックを解消したいと思った時、このロックの解消を同期す るためにprimaryの場所が必要になる。
  • 132.  トランザクションは、コミットのポイントに到達する。  primaryロックを消して、それをコミットタイムスタンプと呼 ばれる新しいタイムスタンプ 8の下で、新しい書き込みレ コードと置き換える。この書き込みレコードは、データが格 納されているタイムスタンプへのポインターを含んでいる。  これ以降、”Bob”行の”bal”カラムを読むものは、値 $3 を見ることになる。
  • 133.  トランザクションは、secondary セルに書き込みデータを 追加し、ロックを消去することで完了する。  この例の場合には、ただ一つのsecondary Joeがあるだ けである。
  • 134. Transaction in BigTable 詳細
  • 135. 1 2 3 4 5 6 7 class Transaction { struct Write { Row row; Column col; string value; }; vector<Write> writes_ ; int start_ts_ ; Transaction() : start_ts_(oracle.GetTimestamp()) {} void Set(Write w) { writes_.push_back(w); } クラスTransactionの働きを見てみよう。 まず、Transactionのインスタンスの生成時に、 start_ts_には、その時点のタイムスタンプが 入れられる。 6行目。
  • 136. データの読み込み:bool Get(Row row, Column c, string* value) の働き  row中の、コンカレントなwriteを通知するロック c:lockを、過去からstart_ts_まで、チェックする。  ペンディングされたロックがあれば、クリーンを試 みて待つ。なければ、次に進む。  c:writeをチェックして、過去からstart_ts_まで にコミットされた、書き込みをみつける。なければ、 データはない。  c:writeからコミットされたタイムスタンプを取得。  c:dataから、コミット・タイムスタンプ時点での値 を読み出す。
  • 137. 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 bool Get(Row row, Column c, string* value) { while (true) { bigtable::Txn T = bigtable::StartRowTransaction(row); // コンカレントなwriteを通知するロックをチェックする if (T.Read(row, c+"lock", [0, start_ts_])) { // ペンディングされたロックがあれば、クリーンを試みて待つ BackoffAndMaybeCleanupLock(row, c); continue; } // スタート・タイムスタンプ以下の最新の書き込みをみつける。 latest write = T.Read(row, c+"write", [0, start ts_]); if (!latest write.found()) return false; // データなし int data_ts = latest_write.start_timestamp(); *value = T.Read(row, c+"data", [data ts, data ts]); return true; } }
  • 138. 書き込み前処理:bool Prewrite(Write w, Write primary) の働き  Prewriteは、セルcをロックしようとする。競合が あるとfalseを返し、Abortする。  c:writeをチェックし、スタート・タイムスタンプの 後にコミットされたものであれば、Abortする  c:lockをチェックし、どんなタイムスタンプでもLo ckされていれば、Abortする。  c:dataに値を書き込む。  c:lockに、スタート・タイムスタンプと、primary lockの場所を書き込む。  コミットする。
  • 139. 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 //Prewriteは、セルcをロックしようとする。競合があるとfalseを返す。 bool Prewrite(Write w, Write primary) { Column c = w.col; bigtable::Txn T = bigtable::StartRowTransaction(w.row); // スタート・タイムスタンプの後にコミットされたものであれば、Abortする if (T.Read(w.row, c+“write”, [start ts , ∞])) return false; // . . . あるいは、どんなタイムスタンプでもLockされていれば、Abortする if (T.Read(w.row, c+"lock", [0, ∞])) return false; T.Write(w.row, c+"data", start ts_, w.value); T.Write(w.row, c+"lock", start ts_, {primary.row, primary.col} ); // プライマリーの場所 return T.Commit(); }
  • 140. コミット:bool Commit() の働き  writes_ベクターの先頭がprimary、それ以降を secondariesとする。  primary、secondariesへのPreWriteが失敗 すれば、コミット失敗。  コミット・タイムスタンプを取得する。  まず、primaryをコミット  c:lockのスタート・タイムスタンプ時点での値を読み込 む。なければ、コミット失敗。  コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。
  • 141. コミット:bool Commit() の働き  コミット・タイムスタンプのc:lockを消す。  コミットする。  続いて、secondariesをコミット。secondaries の各Writeごとに、  コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。  コミット・タイムスタンプのc:lockを消す。  コミット成功
  • 142. 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; 47 48 int commit_ts = oracle .GetTimestamp(); 49 50 // 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; // 動作中にabort 55 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 // 第二フェーズに進む
  • 143. 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 }
  • 144. 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();
  • 145. Dremel インタラクティブなデータ分析 リアルタイムへの要求は、とまらない。2010 年に論文が公開されたDremelは、 MapReduceの100倍のスピードで、巨大な データを、インタラクティブに解析する。以前か らGoogle内部で利用されていたが、2012年、 BigQueryとして、公開サービス開始。
  • 146. Dremel: Interactive Analysis of Web-Scale Datasets Proc. of the 36th Int'l Conf on Very Large Data Bases (2010), pp. 330339 http://static.googleusercontent.com/ external_content/untrusted_dlcp/rese arch.google.com/ja//pubs/archive/36 632.pdf
  • 147. Dremelのアイデア  第一。分散検索エンジンで利用されている、木構 造のアーキテクチャー。Web検索と同様に、検索 は、木構造をたどって行われ、それを書き換える。 検索結果は、下位の木構造から得られる答えを 集約することで行われる。  第二。Dremelは、SQL-likeな検索言語をサ ポートする。それは、HiveやPigとはことなり、 Map-Reduceには変換されずに、ネーティブに 検索を実行する。
  • 148. Dremelのアイデア  第三。Dremelは、カラム単位で分割されたデー タ構造を利用する。カラム型のストレージは、読み 込むデータを少なくして、圧縮が簡単に出来るの で、CPUのコストを削減する。カラム型のデータ・ ストアは、リレーショナルなデータの解析には採 用されてきたが、我々の知る限り、ネストしたデー タ構造へのその拡張は、行われてこなかった。
  • 149. Google Dremel
  • 150. Dremelが利用されている領域           クロールされたWebドキュメントの解析 Androidマーケットで、インスロールされたアプリの追跡 Google製品のクラッシュ報告 Google BooksのOCRの結果. スパムの解析 Google Mapのmapタイルのデバッグ BigtableインスタンスのTabletマイグレーションの管理 Googleの分散ビルドシステム上での実行テスト結果 数十万のディスクのDisk I/O 統計 Googleデータセンターで実行されているジョブの、リソー ス・モニタリング  Googleのコードベースの、シンボルと従属性
  • 151. 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; }} Protocol Buffer Document DocID Links? Backward* Name* Forward* サンプルのスキーマ Language* Code Url? Country?
  • 152. Document Repetetion Level Definition Level DocID 0 Links? 1 Names* 1 1 Backward* 1 Forward* 1 Language* 2 Url? 2 2 2 2 Code 2 Country? 3
  • 153. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
  • 154. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
  • 155. DocId: 10 Links Forward: 20 Forward: 40 Forward: 60 Name Language Code: 'en-us‘ Country: 'us' Language Code: 'en' Url: 'http://A' Name Url: 'http://B' Name Language Code: 'en-gb' Country: 'gb' DocId: 20 Links Backward: 10 Backward: 30 Forward: 80 Name Url: 'http://C‘
  • 156. サンプルの格納状態 Document DocID 10 0 0 20 0 0 Links? Backward* NULL 0 1 10 02 30 12 Name* Forward* 20 40 60 80 0 1 1 0 2 2 2 2 Language* Url? http://A 0 2 Code Country? http://B 1 2 NULL 11 http://C 0 2 en-us 0 2 us 03 en 2 2 NULL 2 2 NULL 1 1 NULL 1 1 en-gb 1 2 gb 13 NULL 0 1 NULL 0 1
  • 157. Dremelの検索言語 SELECT DocId AS Id, COUNT(Name.Language.Code) WITHIN Name AS Cnt, Name.Url + ',' + Name.Language.Code AS Str FROM t WHERE REGEXP(Name.Url, '^http') AND DocId < 20; 出力結果 Id: 10 Name 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; }}}
  • 158. 検索の木構造  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の分割
  • 159. MapReduceとDremel 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 3000 nodes, 85 billion records
  • 160. 結論  スキャンベースの検索は、一兆個以上のディスク上の データセットに対して、インタラクティブなスピードで実行出 来る。  数千ノードを含むシステムで、カラムとサーバーの数に関 して、ほとんどリニアーなスケーラビリティーを達成出来る。  DBMSとまったく同様に、MapReduceは、カラム型のス トレージの恩恵を受ける。  レコードの収集とパージングは、コストがかかる。ソフト ウェアの層は(検索実行の層を超えて)、直接カラム指向 のデータを利用出来るようになる必要がある。
  • 161. Spanner Googleの新しい分散データベース 2012年に論文が公開されたSpannerは、 key-valueをベースにした拡張性と、RDBの ACIDなトランザクション処理能力を併せ持つ 強力な分散データベースである。タイムスタン プ・ベースのトランザクション処理に必要な正 確な時間を得る為に、GPSや原子時計を利用。 その上に、時間の不確実性を組み込んでいる。
  • 162. Spanner: Google’s Globally-Distributed Database Wilson Hsieh representing a host of authors OSDI 2012 http://static.googleusercontent.com/external_content/untrusted_dlcp/ research.google.com/ja//archive/spanner-osdi2012.pdf http://research.google.com/archive/spanner.html Video: https://www.usenix.org/conference/osdi12/elmo-building-globallydistributed-highly-available-database
  • 163. Spannerとは何か? 分散マルチバージョンデータベース 汎用のトランザクション(ACID) SQL言語のサポート スキーム化されたテーブル Semi-relationalなデータモデル 既に、製品として稼働している  Googleの広告データのストレージとして  sharded MySQL を置き換えている OSDI 2012 171
  • 164. Example: Social Network x1000 x1000 San Francisco Brazil Seattle User posts Arizona Friend lists US x1000 Spain OSDI 2012 Sao Paulo Santiago Buenos Aires London Paris Berlin Madrid Lisbon x1000 Moscow Berlin Krakow Russia 172
  • 165. Spanner概観  特徴: Lock-freeな、分散readトランザクション  特質: 分散トランザクションの外的整合性保証  グローバルなスケールでは、最初のシステム  実装: Concurrency controlとReplication と2PCの統合  正当性とパフォーマンス  可能にした技術: TrueTime  Interval-basedなグローバル時間 OSDI 2012 173
  • 166. 読み込みのトランザクション  友達の最近のポストのページを生成する  友達のリストとそのポストの整合的なビュー 何故、整合性が重要なのか? 1. 不審な人物を友達から削除する 2. Post P: “我々の政府は、抑圧的である…” OSDI 2012 174
  • 167. 単一のマシン マイページの生成 Friend1 post Friend2 post … Friend999 post Friend1000 post OSDI 2012 User posts Friend lists 175
  • 168. 複数のマシン Friend1 post Friend2 post User posts Friend lists … Friend999 post Friend1000 post OSDI 2012 マイページの生成 User posts Friend lists 177
  • 169. 複数のデータセンター Friend1 post US User posts x1000 Friend lists Friend2 post Spain … User posts x1000 Friend lists マイページの生成 Friend999 post Brazil User posts x1000 Friend lists Friend1000 post Russia User posts x1000 Friend lists OSDI 2012 179
  • 170. 書き込みとバージョン管理  書き込みのトランザクションには、厳密なTwo-PhaseLockを使う。  それぞれのトランザクションTには、タイムスタンプsが割り当 てられる。  トランザクションTによって書き込まれたデータは、タイムスタ ンプsを持つ。 Time <8 My friends [X] My posts X’s friends [me] OSDI 2012 8 15 [] [P] [] 181
  • 171. スナップショットを同期する グローバルな壁時計 == 外的整合性: コミットの順序は、グローバルな壁時計の 順序を尊重する == タイムスタンプの順序は、与えられた グローバルな壁時計の 順序を尊重する タイムスタンプの順序 == コミットの順序 OSDI 2012 182
  • 172. タイムスタンプとグローバル・クロック  書き込みのトランザクションについては、厳密な two-phase lockingを適用する。  ロックが保持されている間、タイムスタンプを割り当 てる。 Acquired locks Release locks T Pick s = now() OSDI 2012 183
  • 173. タイムスタンプの不変量 • タイムスタンプの順序 == コミットの順序 T 1 T 2 • タイムスタンプの順序は、グローバルな壁時計 の順序を尊重する T 3 T 4
  • 174. TrueTime  “グローバルな壁時計の時間” は、ある制限の 範囲だが、不確実性を持つ。 TT.now() earliest time latest 2*ε
  • 175. タイムスタンプとTrueTime Acquired locks Release locks T Pick s = TT.now().latest s Wait until TT.now().earliest > s Commit wait average ε OSDI 2012 average ε 186
  • 176. コミットのWaitとレプリケーション Achieve consensus Start consensus Notify slaves Acquired locks Release locks T Pick s Commit wait done
  • 177. Commit Wait and 2-Phase Commit Start logging Done logging Acquired locks Release locks TC Acquired locks Committed Notify participants of s Release locks TP1 Acquired locks TP2 Release locks Prepared Send s Compute s for each Commit wait done Compute overall s OSDI 2012 188
  • 178. Example Remove X from my friend list Risky post P TC T2 sC=6 TP s=8 s=15 Remove myself from X’s friend list sP=8 s=8 Time 8 My friends My posts X’s friends OSDI 2012 <8 [X] 15 [] [P] [me] [] 189
  • 179. 我々がカバー出来たことは何か?  データセンター間の、ロックフリーな、read トラ ンザクション  外的整合性  タイムスタンプの割り当て  TrueTime  時間の不確実性は、待つことでしのぐことが出来る OSDI 2012 190
  • 180. 我々がカバーしなかったこと  現在の時刻を、どうよむのか。  アトミックなスキーマの変更  大部分は、ノン・ブロッキングである  未来のタイムスタンプでコミットする  過去のノン・ブロッキングな読み込み  レプリカの効率的な更新 OSDI 2012 191
  • 181. TrueTime Architecture GPS timemaster GPS timemaster GPS timemaster GPS timemaster Atomicclock timemaster GPS timemaster Client Datacenter 1 Datacenter 2 … Datacenter n Compute reference [earliest, latest] = now ± ε OSDI 2012 192
  • 182. TrueTime implementation now = reference now + local-clock offset ε = reference ε + worst-case local-clock drift ε +6ms reference uncertainty 0sec OSDI 2012 200 μs/sec time 30sec 60sec 90sec 193
  • 183. 時計が狂うとどうなるか?  タイムスタンプの割り当てが、外的整合性を破 ることになるだろう。  一年間のデータに基づけば、そういうことはあ りそうにない。  時計が狂うより、CPUがおかしくなる可能性の方 が、6倍以上ありそうである。 OSDI 2012 194
  • 184. 将来の課題  TrueTimeの改善  Lower ε < 1 ms  データベースの諸特徴をきちんと構築する  基本的な特徴の実装を終える  多様な検索パターンを効果的にサポートする OSDI 2012 195
  • 185. 結論  時計の不確実性を time APIで具体化する  知らないことを知ることは、知らないことを知らない より、いいことである  不確実性を利用した、アルゴリズムを再考すること  強いセマンティックは達成可能である  大規模なスケール != 弱いセマンティックス OSDI 2012 196
  • 186. Knowledge Graph Googleの新しい検索技術 2012年の5月、Googleは、「Knowledge Graph」と名付けられた新しい検索サービス をアメリカで開始した。言うまでもなく検索は、 Googleのコア・コンピーテンスである。 Googleは、検索にどのような新しさを持ち込 もうとしているのか?
  • 187. Google Knowledge Graph 新しい検索の三つの特徴  正しい「もの」を見つける。(Find the right thing)  最良の要約を得る。(Get the best summary)  さらに深く、さらに広く。(Go deeper and broader)
  • 188. 検索結果のパーソナライズ
  • 189. Googleの 検索結果の「パーソナライズ」  人々は、コンテキストとパーソナライズを混同して いる。この2つは別のものだ。コンテキストには、 言語、場所、年度等が因子として含まれる。  過去の検索の履歴は、パーソナライズに利用さ れている。もし、「ローマ」を検索して次に「ホテル」 を検索すれば、検索結果のいくつかは、ローマの ホテルのものになるだろう。  履歴上の過去のクリックも、一つの因子となる。も し、検索結果中の一つのサイトに対してクリックし て、明らかな嗜好を示せば、次の検索では、その サイトは上位にランクされるかもしれない。
  • 190. Googleの 検索結果の「パーソナライズ」  URLの最後の部分に、&pws=0 を追加すると機 能する。ただ、パーソナライズを消すだけで、コン テキスト(言語、場所、年度)は消さない。  全てのパーソナライズをオフにする方法はある。 Googleの立場は、ユーザーは自分のデータを所 有するというものだ。ただ、その場合でも、コンテ キストは、依然として、有効になっている。 "How Google Does Personalization with Jack Menzel” http://www.stonetemple.com/ how-google-does-personalization-with-jack-menzel/
  • 191. まとめ
  • 192. Google
  • 193. Google
  • 194. 資料編  Snapshot Isolation “A Critique of ANSI SQL Isolation Levels”  Spanner: Google’s GloballyDistributed Database
  • 195. Snapshot Isolation “A Critique of ANSI SQL Isolation Levels” http://t.co/2HBae9l5gK
  • 196. Start-Timestamp  Snapshot Isolationでは、それぞれのトランザ クションは、Start-Timestampと呼ばれる、トラ ンザクションを開始した時刻のデータのスナップ ショット(コミットされた)からデータを読み込む。こ の時刻は、トランザクションの最初の読み込みの 時刻の前の時刻になる。  トランザクションのStart-Timestamp以降にア クティブになった他のトランザクションによる更新 は、このトランザクションからは見えない。
  • 197. ReadとWrite  Snapshot Isolationの中のトランザクションは、 そのStart-Timestampからのスナップショットの データが維持可能である限り、読み込みがブロッ クされることはない。  トランザクションでの書き込み(updates, inserts, deletes)もまた、このスナップショットに 反映される。もしトランザクションが、このデータに 二度目のアクセス(reads あるいは updates)を するなら、ふたたび、読み出される。
  • 198. Commit-Timestamp  トランザクションT1が、コミットの準備ができた時、 それはCommit-Timestampを取得するのだが、 それは、既に存在するStart-Timestampあるい は Commit-Timestampより、大きな値を持つ。  トランザクションは、T1の実行間隔 [StartTimestamp, Commit-Timestamp] 内にCommit-Timestampを持つ他のトランザ クションT2が、 T1が書き出したデータと同じデー タを書き出していない場合に限り、コミットに成功 する。
  • 199. First-Commiter-Wins  そうでない場合、T1はアボートする。この「最初に コミットしたものが勝つ」という特徴が、更新が失 われるのを防止する。  T1がコミットされると、そのStart-Timestamps がT1のCommit-Timestampより大きい、全て のトランザクションに、その変更は見えるようにな る。
  • 200. Spanner: Google’s GloballyDistributed Database James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat et al. http://static.googleusercontent.com/external_conten t/untrusted_dlcp/research.google.com/ja//archive/sp anner-osdi2012.pdf
  • 201. Abstract
  • 202. Abstract  Spannerは、スケーラブルで、マルチ・バージョン、 グローバルに分散し、レプリカの同期を行う、 Googleのデータベースである。  それは、グローバルなスケールでのデータの分散 と外的整合的な分散トランザクションをサポートし た、初めてのシステムである。  この論文は、Spannerがどのような構造を持つ か、その諸特徴、様々なデザインの決定の基礎 にある理論的な根拠、時計の不確実性を明らか にする全く新しい time APIについて述べたもの である。
  • 203. Abstract  このAPIとその実装は、外的な整合性と、 Spannerの全域にわたる、過去のデータのブ ロックしない呼び出し、ロックのないread-onlyト ランザクション、そしてアトミックなスキーマの変更 といった強力な諸特徴をサポートする上で、 本質 的に重要なものである。
  • 204. 1 Introduction
  • 205. 概観  Spannerは、Googleで、デザイン・構築・配備さ れたスケーラブルでグローバルな分散データベー スである。  もっとも高い抽象のレベルでは、 それは、全世界 に広がっているデータセンター内の沢山のPaxos 状態マシン群をまたいで、データを分割したデー タベースである。  Spannerは、数百のデータセンターをまたいだ数 百万のマシンと、数兆行のデータベースにスケー ルアップするように設計されている。
  • 206. ReplicaとResharding  データの複製は、グローバルな可用性と地理的な局所性 の為に利用されている。クライアントは、レプリカ間で自動 的にフェール・オーバーする。  Spannerは、データの量やサーバーの数が変化するに 応じて、マシン間でデータを再分割する。それは、マシン 間で(データセンター間でさえ)、自動的にデータを移動し て、負荷のバランスを取り、マシンの失敗に対応する。  アプリケーションは、広域の自然災害に直面しても、内部 で、あるいは大陸をまたいでも、データを複製することに よって、高い可用性の為に、Spannerを利用出来る。
  • 207. ReplicaとAvailability  我々のシステムの最初の利用者は、Googleの広告シス テムのバックエンドを書き換えたF1であった。F1は、アメ リカ全土に広がった5つのレプリカを利用した。  他のアプリの大部分は、相対的には独立な事故のモード を想定してではあるが、一つの地理的な領域内で、3から 5のデータセンターに、データを複製するだろう。というの は、大部分のアプリケーションは、一つか二つのデータセ ンターで事故が起きても、生き残ることが出来る限りは、 高い可用性の上の低い遅延の方を選ぶだろう。  Spannerの主なフォーカスは、データセンターをまたいだ 複製データの管理に置かれている。
  • 208. SpannerとBigTable  ただ、我々は、この分散システムのインフラの上に、デー タベースの重要な諸特徴を、デザインし実装することにも、 非常に多くの時間をかけてきた。  たとえ、多くのプロジェクトが、BigTableを使ってハッピー だとしても、我々は、ある種のアプリに取っては、 BigTableは使うには難しくなることがあるという不満を、 一貫して受け取ってきた。例えば、複雑でスキーマが変化 する、あるいは、広域に複製があるにしても、強い整合性 が欲しいというようなアプリだ。(同じような要求は、他の 著者からもなされていた。)
  • 209. SpannerとBigTable  Googleの多くのアプリケーションは、相対的には 貧弱な書き込み性能にもかかわらず、半リレー ショナルなデータモデルと、複製の同期のサポー トの故に、Megastoreを選んできた。  その結果、Spannerは、BigTableのようなバー ジョンづけられたkey-valueストアから、テンポラ ルなマルチバージョン・データベースへと進化して きた。
  • 210. Spannerのデータ形式  データは、スキーマを持つ半リレーショナルな テーブルに格納される。データはバージョンづけ られ、それぞれのバージョンは、自動的にそのコ ミット・タイムでタイムスタンプが与えられる。古い データのバージョンは、設定可能なガーベージコ レクション・ポリシーの元に置かれる。そうして、ア プリは、古いタイムスタンプのデータを読むことが 出来る。  Spannerは、一般的な目的のトランザクションを サポートし、SQLベースの検索言語を提供する。
  • 211. グローバルに分散したデータベースとしての Spannerの、興味深い特徴  第一に、データの複製の設定は、アプリによって細かい粒 度でコントロール出来る。アプリは、どのデータセンターが どのデータを持つのか、データはユーザーからどのくらい 離れているか(読み込みの遅延をコントロールする)、レプ リカはお互いにどれくらい離れているか(書き込みの遅延 をコントロールする)、そして、どのくらいの数のレプリカが 維持されているか(耐久性・可用性・読み込みのパフォー マンスをコントロールする)等をコントロールする制約条件 を指定出来る。  データは、また、データセンター間のリソースの利用のバ ランスをとるシステムによって、動的かつ透過的にデータ センター間を移動出来る。
  • 212. グローバルに分散したデータベースとしての Spannerの、興味深い特徴  第二に、Spannerは、分散データベースでは実 装するのが難しい二つの特徴を持つ。  読み書きについての外的整合性  ある時点での、データベースをまたいだグローバルに 整合的な読み込み  こうした特徴は、グローバルなスケールで、たとえ 実行中のトランザクションがあったとしても、整合 的なバックアップ、整合的なMapReduceの実行、 アトミックなスキーマの更新を、Spannerに可能 とする。
  • 213. Timestamp  こうした特徴は、たとえトランザクションが分散していたとし ても、Spannerがトランザクションにグローバルに意味の あるコミット・タイムスタンプを割り当てるという事実によっ て可能になった。  このタイムスタンプは、シリアル化された順序を反映して いる。それに加えて、シリアル化された順序は、外的整合 性(あるいは、それと等価だが、線形化可能性)を満たし ている。すなわち、あるトランザクションT1が、別のトラン ザクションT2が始まる前にコミットするなら、T1のコミット・ タイムスタンプは、T2のそれよりも小さい。  Spannerは、グローバルなスケールで、こうした保証を与 えた最初のシステムである。
  • 214. TrueTime API  こうした性質を可能にした重要なものは、TrueTime API とその実装である。  このAPIは、直接に、時計の不確実さを、あらわに示すも のである。そして、Spannerのタイムスタンプは、実装が 提供する不確実さの範囲にディペンドしている。もし、不確 実さが大きければ、Spannerは、この不確実さを待つ為 に、スピードを落とす。  この実装は、複数の現代的な時計(GPSと原子時計)へ の参照を利用することで、不確実性を小さなもの(一般的 には、10ms以下)にとどめようとする。
  • 215. 2 Implementation 2.1 Spanserver Software Stack 2.2 Directories and Placement 2.3 Data Model
  • 216. Implementation  この節では、Spannerの構造とその実装の基礎 にある理論的な根拠を述べる。  その後、複製と局所性を管理するのに利用され、 データ移動の単位である、「ディレクトリー」という 抽象について述べる。  最後に、我々のデータモデルと、なぜSpanner がキー・バリュー・ストアではなくリレーショナル・ データベースのように見えるのか、また、アプリ ケーションは如何にしてデータの局所性をハンド ルすることが出来るのかについて述べる。
  • 217. UniverseとZone  Spannerの配備は、「ユニバース」と呼ばれる。 Spannerがデータをグローバルに管理している としても、ほんの少数の稼働しているユニバース があるだけだろう。  我々は現在、テスト/プレイグラウンド・ユニバース と、開発/生産・ユニバースと、生産専用・ユニ バースの三つを走らせている。  Spannerは、一群の「ゾーン」で組織されている。 それぞれのゾーンは、大まかにいって、 BigTableのサーバーに相当するものである。
  • 218. Zone  ゾーンは、管理上の配備の単位である。一群のゾーンは、 また、その上にデータの複製を置くことが出来る、場所群 でもある。  新しいデータセンターがサービスを開始したり、逆に、古 いデータセンターがサービスを停止したりした場合、ゾー ンを稼働中のシステムに追加したり取り除くことが出来る。  ゾーンは、物理的な隔離の単位でもある。データセンター には、一つかそれ以上のゾーンがあるかもしれない。例え ば、異なったアプリのデータが同じデータセンター内の異 なったサーバー群にまたがって分割されなければいけな いような場合である。
  • 219. ZonemasterとLocationProxy  図1は、Spannerユニバースのサーバーを図示 したものである。  ゾーンは、一つのゾーン・マスターと、百から数千 の間のスパンサーバーを持っている。前者は、ス パンサーバーにデータを割り当てる。後者は、 データをクライアントにサービスする。  ユーザーのデータに割り当てられたスパンサー バーの場所を特定する為に、そのゾーンのロケー ション・プロキシーが利用される。
  • 220. UniverseMasterとPlacementDriver  ユニバース・マスターとプレスメント・ドライバーは、現在のと ころ、一つしかない。  ユニバース・マスターは、第一義的には、全てのゾーンにつ いてのステイタス情報が表示され、インタラクティブなデバッ グの為に利用される、コンソールである。  プレスメント・ドライバーは、数分の単位のタイムスケールで の、ゾーンをまたいだデータの自動的な移動をハンドルする。 プレスメント・ドライバーは、定期的にスパンサーバーと通信 して、レプリカの更新条件に合致した、あるいは、負荷をバラ ンスさせる為、移動すべきデータを見つける。  スペースの関係で、スパンサーバーについてのみ、詳しく述 べることになろう。
  • 221. 2.1 Spanserver Software Stack この節では、スパンサーバーの実装にフォー カスして、我々のBigTableをベースにした実 装の上に、どのように、複製と分散トランザク ションが、実現されたかを示す。
  • 222. Spanserver Software Stack  ソストウェア・スタックは、次の図2に示されている。 スタックの一番下では、スパンサーバーが、100 個から1000個の間のタブレットと呼ばれるデータ 構造のインスタンスに責任を持っている。  タブレットは、BigTableのタブレットという抽象と 同様のもので、その中では、次のようなマッピング のバッグを実装している。 (key:string, timestamp:int64) → string
  • 223.  Bigtableとは異なって、Spannerは、タイムスタンプを データに割り当てる。ここが、Spannerがキー・バリュー・ ストアよりは、マルチ・バージョン・データベースにずっと似 ている重要なポイントである。  タブレットの状態は、Bツリーに似た一群のファイルと write-aheadログに格納されている。これらは全て Colossusと呼ばれる分散ファイルシステム(Google File Systemの後継である)上にある。  複製をサポートする為に、それぞれのスパンサーバーは、 それぞれのタブレット上に、一つのPaxos状態マシンを実 装している。
  • 224.  (初期のSpannerの具体化では、タブレットごと に複数のPaxos状態マシンをサポートしていた。 それによって、もっと柔軟な複製の設定が可能と なるのだが、そのデザインの複雑さの為に、我々 は、それを放棄した。)  それぞれの状態マシンは、そのメタデータとログ を対応するタブレットに格納する。  我々のPaxosの実装は、時間ベースのリーダー のリースで、デフォルトの長さが10秒の、長い期 間のリーダーをサポートしている。
  • 225.  現在のSpannerの実装では、全てのPaxosが二 度ログを書き出している。一つは、タブレットのロ グで、もう一つはPaxosのログである。この選択 は、expendiencyによるもので、最終的には修 正したいと思っている。  我々のPaxosの実装は、WANの遅延があるにも かかわらず、Spannerのスループットを向上させ る為に、パイプライン化されている。しかし、書き 込みは、Paxosによって、順番に実行される。
  • 226. Paxos  Paxos状態マシンは、マッピングのバッグのレプ リカを整合的に実装するのに利用されている。そ れぞれの複製のキー・バリュー・マッピングの状 態は、対応するタブレットに格納される。  書き出しは、リーダーのPaxosプロトコルから開 始されなければならない。読み出しのアクセスの 状態は、十分更新されたどのレプリカの下にある タブレットからでも直接に取得出来る。一群のレプ リカは、集って、Paxos グループを形成する。
  • 227.  リーダーである全てのレプリカのスパンサーバー は、コンカレンシーのコントロールを実装する為の ロック・テーブルを実装している。  ロック・テーブルは、ツー・フェーズ・ロッキングの 為の状態を含んでいる。それは、一連のキーを ロック状態にマップする。(ロック・テーブルを効率 的に管理する上で、長い期間、生き続けるリー ダーを持つことは、本質的に重要であることに注 意。)
  • 228.  BigTableでもSpannerでも、両方とも、我々は。 長いトランザクション(例えば、レポートの生成。こ れ数分単位の時間がかかる)の為のデザインをし てきた。こうした処理は、衝突がある場合には、楽 観的コンカレンシー・コントロールでは、貧弱な性 能しか出ない。  読み込みのトランザクションのような同期を必要と する操作は、ロック・テーブルからロックを取得す る。その他の操作は、ロック・テーブルをバイパス する。
  • 229.  リーダーである全てのレプリカでは、それぞれの スパンサーバーは、分散トランザクションをサポー トする為にトランザクション・マネージャーも実装し ている。  トランザクション・マネージャーは、参加者のリー ダーを実装する為に利用される。その他のレプリ カは、参加者のスレーブとなる。
  • 230.  もしトランザクションが、一つのPaxosグループを 含んでいるだけなら(大部分のトランザクションの 場合)、それは、トランザクション・マネージャをバ イパス出来る。というのは、ロック・テーブルと Paxosが一緒になって、トランザクションの保証を 提供するからである。  もしトランザクションが一つ以上のPaxosグルー プを含んでいたら、これらのグループ・リーダーが ツー・フェーズ・コミットの調整役を演ずる。
  • 231.  参加グループの一つが、調整役に選ばれる。そ のグループの参加者のリーダーは、調整役リー ダーと呼ばれ、グループのスレーブは、調整役ス レーブと呼ばれる。  それぞれのトランザクション・マネージャの状態は。 直下のPaxosグループに格納される。(それ故、 複製される。)
  • 232. 2.2 Directories and Placement
  • 233. 2.2 Directories and Placement  キー・バリュー・マッピングのバッグの上で、 Spannerの実装は、「ディレクトリー」と呼ばれる 「バケット化」の抽象をサポートしている。それは、 共通の接頭辞を共有する連続的なキーの集まり である。(ディレクトリーという言葉の選択は、歴史 的な事情によるもので、もっと良い言葉は、「バ ケット」だったかもしれない。)  次のセクション2.3で、この接頭辞の起源を説明 しよう。ディレクトリーのサポートは、キーを注意深 く選ぶことによって、データの局所性をコントロー ルすることを可能にする。
  • 234.  ディレクトリーは、データの配置の単位である。 ディレクトリー内の全てのデータは、同じ複製設定 を持つ。  データがPaxosグループ間を移動する時、それ は図3が示すように、ディレクトリーからディレクト リーへと移動する。  Spannerは、ディレクトリーを、あるPaxosグルー プから負荷を軽減する為に移動するかもしれない。 よくアクセスされるディレクトリーを同じグループに まとめたり、アクセスする人に近いグループにディ レクトリーを移動したり。
  • 235.  クライアントの操作が実行中でも、ディレクトリー は移動出来る。50MBのディレクトリーは、数秒で 移動出来ると考えてよい。  Paxosグループが複数のディレクトリーを含みう るという事実は、Spannerのタブレットが BigTableのタブレットとは違っていることを意味し ている。Spannerのタブレットは、単一の連続す るの辞書式順序の行空間の分割ではないのであ る。
  • 236.  その代わりに、Spannerのタブレットは、複数の 行空間の分割を包み込んだコンテナーなのであ る。しばしば一緒にアクセスされる複数のディレク トリーを、近い場所に置くことが可能であるという ことで、我々は、この決定を行った。  Movedirは、Paxosグループ間でディレクトリー を移動させるバックグラウンドのタスクである。 Movedirはまた、レプリカをPaxosグループに追 加したり削除するのに利用されている。というのも、 SpannerはPaxosの設定を変えるということを、 まだ、サポートしていないからだ。
  • 237.  Movedirは、大きなかたまりのデータ移動の際に 実行される、読み出し・書き込みのブロックを避け る為に、単一のトランザクションとしては、実装さ れていない。  その代わりに、 movedirは、データ移動が始 まったという事実を登録し、データをバックグラウ ンドで移動する。  名目的なデータの量以外の全てのデータを移動 し終わったら、movedirは、この名目的な量をア トミックに移動する為にトランザクションを利用し、 二つのPaxosグループのメタデータを更新する。
  • 238.  ディレクトリーは、また、その複製の地理的なプロ パティ(短く、「配置」という)が、アプリによって指 定される最小の単位である。  配置指定の言語は、複製の設定を管理する責任 とは分離されている。  管理者は、二つの次元をコントロールする。レプリ カの数と型、そして、これらのレプリカの地理的な 配置である。管理者は、これらの二つの次元で、 名前でオプションのメニューを作る。(例えば、 North America, replicated 5 ways with 1 witness というような).
  • 239.  アプリは、それぞれのデータベース、あるいは、 個々のディレクトリーを、これらのオプションの組 み合わせでタグづけて、データがいかに複製され るかをコントロールする。  例えば、あるアプリでは、エンドユーザー各人の データを、次のように、自身のディレクトリーに格 納しているかもしれない。ユーザーAのデータは ヨーロッパに3つのレプリカを持ち、ユーザーBの データは、北米に5つのレプリカを持つ、ということ が可能になる。
  • 240.  説明を分かりやすくする為に、随分、単純化した のだが、実際には、Spannerはディレクトリーが あまりに大きくなった時には、それを複数のフラグ メントに分割するだろう。  フラグメントは、異なるPaxosグループでサービス を受ける(それ故、異なるサーバーで)かもしれな い。Movedirは、実際には、グループ間でディレ クトリー全体ではなく、フラグメントを移動する。
  • 241. 2.3 Data Model Spannerは、次のような一群のデータの諸特 徴を、アプリケーションに示す。 スキーマ化さ れた半リレーショナルなテーブル、検索言語、 一般的な目的のトランザクションである。 これらの諸特徴をサポートしようという動きは、 様々なファクターによってドライブされていた。
  • 242.  スキーマ化された半リレーショナルなテーブルと同 期的な複製をサポートするニーズは、Megastore が広く受け入れられたことでサポートされた。  Google内では、すくなくとも300のアプリが、 Megastore(その相対的には低いパフォーマンス にもかかわらず)を利用している。というのも、その データ・モデルは、管理が単純だからである。  そして、データセンターをまたぐ同期複製のサポー トによって。(BigTableは、データセンター間では、 Eventually Consistentな同期複製しかサポート していない)
  • 243.  Megastoreを利用したよく知られたGoogleのア プリには、次のものがある。      Gmail Picasa Calendar Android Market AppEngine
  • 244.  Spannerで、SQLライクな検索言語をサポートす る必要も、インタラクティブなデータ分析ツールと してのDremelの人気をみれば、明確であった。  最後に、BigTableでは、行をまたいだトランザク ションが欠けていたことも、しばしば不満の種に なった。Percolator は、部分的には、この欠点 に向けて開発されたものだった。  ある人たちは、一般的なツー・フェーズ・コミットは、 それがもたらすパフォーマンスの問題や可用性の 問題を考えれば、サポートするのは、あまりに高 いものにつくと論じてきた。
  • 245.  我々は、アプリケーションの開発者に、トランザク ションの過剰な使用によりボトルネックが生ずると いうパフォーマンスの問題を扱わせることは、い つもトランザクションを欠いたままコードを書くより、 ましなことだと信じている。  Paxos上でツー・フェーズ・コミットを走らせること は、可用性の問題を軽減する。
  • 246.  アプリケーションのデータ・モデルは、実装でサポートされ ている、ディレクトリーでバケット化されたキー・バリュー・ マッピングの層の上に作られる。  アプリは、ユニバースの中に、一つ、あるいはそれ以上の データベースを生成する。それぞれのデータベースは、無 制限の数のスキーマ化されたテーブルを含むことが出来 る。テーブルは、行とカラムとバージョン値を持つ、リレー ショナル・データベースに見える。  ここでは、Spannerの検索言語については深く触れない。 それは、 プロトコル・バッファーの値を持つフィールドをサ ポートする、いくつかの拡張をほどこしたSQLに見える。
  • 247.  Spannerのデータ・モデルは、純粋にリレーショ ナルなものではない。そこでは、行は名前を持た なければならない。もっと正確に言えば、全ての テーブルは、一つあるいはそれ以上の、順序づけ られたプライマリー・キー・カラムのセットを持つこ とを要求される。  この要請は、Spannerが依然としてキー・バ リュー・ストアに見えるところである。プライマリー・ キーは行に対する名前を形成し、それぞれの テーブルは、プライマリー・キー・カラムから非プラ イマリー・キー・カラムへのマッピングを定義する。
  • 248.  行は、行のキーに(たとえそれがNULLであって も)ある値が定義されている時にのみ存在する。  こうした構造を課することは、アプリケーションに キーの選択を通じてデータの局所性をコントロー ルさせるので、有用である。  図4は、ユーザーごと、アルバムごとに、写真のメ タデータを格納する、Spannerのスキーマの例で ある。
  • 249.  スキーマ言語は、Megastoreのものと似ている。 それに、全てのSpannerのデータベースは、クラ イアントによって、一つあるいはそれ以上の、テー ブルの階層によって分割されなければならないと いう要請を付け加えたものである。  クライアントのアプリは、データベースのこの階層 を、INTERLEAVE IN宣言によって宣言する。階 層のトップのテーブルは、ディレクトリー・テーブル である。
  • 250.  キーKを持つディレクトリー・テーブルは、辞書式 順序でKで始まる、下位のテーブルの全ての行と ともに、ディレクトリーを形成する。  ON DELETE CASCADE は、このディレクトリー 中のある行の削除は、関連する子供の行を全て 削除することを意味している。  この図はまた、この例のデータベースのインター リーブされたレイアウトを図示している。
  • 251.  例えば、Albums(2,1)は、Albumsテーブルの ユーザーid 2、アルバムid 1の行を表している。  このディレクトリーを形成するテーブルのインター リービングは重要である。なぜなら、それは、複数 のテーブル間に存在するローカルな関係を、クラ イアントが記述することを可能にするからである。  それは、分割された分散データベースでは、よい パフォーマンスの為に必要である。それなしでは、 Spannerは、もっとも重要なローカルな関係性を 知ることが出来ない。
  • 252. 3 TrueTime ここでは、TrueTime APIについて述べ、そ の実装をスケッチする。詳細は、別の論文に 譲る。我々の目的は、こうしたAPIを持つこと の力を示すことである。
  • 253. TrueTime  テーブル1は、このAPIのメソッドである。  TrueTimeは、時間をTTintervalとして、時間の 不確実性で境界付けられた、ある区間として、 はっきりと表現している。(クライアントに、時間の 不確実性についての考えを、まったく与えない標 準的な時間のインターフェースとは、違っている)
  • 254.  TTintervalの端点は、TTstampの型を持つ。  TT.now()メソッドは、その間にTT.now()が呼び 出された絶対時間を含むことが保証されている TTintervalを返す。この時刻は、UNIXのtime に似ているが、うるう秒の補正をしてある。  その瞬間の誤差の範囲を ε と定義する。それは、 区間の半分の長さで、平均的な誤差の範囲はε となる。  TT.after() と TT.before() メソッドは、 TT.now()関連の便利なラッパーである。
  • 255.  イベントeの絶対時間を、関数 t_{abs}(e)で表 す。より形式的に述べれば、t_{now}をイベント の呼び出しとしたとき、TrueTimeは、次のことを 保証する。tt = TT.now()、tt.earliest ≤ t bs ] ] t_{abs}(t_{now}) ≤ tt.latest
  • 256.  TrueTimeで使われている基礎になる時間の参 照は、GPSと原子時計である。TrueTimeは、二 つの形式の時間を参照する。というのも、この二 つは、失敗のモードが異なっているから。  GPSのソース参照の脆弱性は、 アンテナやレ シーバの事故、ローカルな電波の干渉、正しくな いうるう秒の処理やなりすまし等に関連した失敗 を含んでいる。  原子時計はGPSとは関係なく、それぞれ独立に 失敗することがある。あまりに長い時間の間隔は、 周波数エラーで大きくずれることがある。
  • 257.  TrueTimeは、データセンターごとのタイム・マス ター・マシンと、マシンごとのタイム・スレーブ・ デーモンで実装されている。  マスターの大部分は、専用アンテナを備えたGPS 受信機を持っている。これらのマスターは、アンテ ナ事故や電波の干渉、なりすましの危険を軽減 する為に、物理的に離れて設置される。  残りのマスター(われわれは、それを「ハルマゲド ン・マスター」と読んでいる)は、原子時計を装備し ている。
  • 258.  原子時計は、高価なものではない。ハルマゲドン・マスター のコストは、GPSマスターのコストと同じオーダーである。  全てのマスターの時間参照は、定期的に、相互に比較され る。それぞれのマスターはまた、参照時間と自分のローカ ル時計とのクロス・チェックも行う。もし、重大な相違があれ ば、自分をマスターから外す。  同期の間、ハルマゲドン・サーバーは、ゆっくり増えていく時 間の不確実性を広告する。それは、最悪ケースの時計のず れを適用して、保守的に導きだされる。  GPSマスターは、典型的にはゼロに近いものとして、不確 実性を広告する。
  • 259.  全てのデーモンは、一つのマスターによるエラー の脆弱性を軽減する為に、多様なマスターに投票 する。あるものは、近くのデータセンターから選ば れたGPSマスターを、あるものは、遠くのデータセ ンターのGPSマスターを、あるものはハルマゲド ン・マスターを選ぶ。  デーモンは、嘘つきを検出し排除し、ローカル・マ シンの時計を、嘘つきではない時計に同期する為 に、Marzulloのアルゴリズムの変種を適用する。
  • 260.  壊れたローカル時計から守る為に、コンポーネン トの仕様と操作環境から導かれる最悪ケースより 大きな変動を繰り返すマシンは、取り除かれる。  同期の間、デーモンは、ゆっくり増えていく時間の 不確実性を広告する。εは、最悪ケースの時計の ずれを適用して、保守的に導きだされる。  ε はまた、タイム・マスターの不確実性と、タイム・ マスターに対する通信遅延にディペンドする。
  • 261.  我々の製品版の環境では、ε は、投票間隔では、 約1msから7msの間を変動する、のこぎりの歯 状の関数である。ε は、それ故、大部分の時間 4msである。  デーモンの投票間隔は、現在30秒であり、現在 の変異率は、毎秒あたり200マイクロ秒に設定さ れている。  のこぎり歯は、0から6msの範囲の値を持つ。残 りの1msは、タイム・サーバーに対する通信遅延 である。
  • 262.  事故が起きた時は、こののこぎり歯から乖離する 可能性がある。例えば、タイム・マスターが一時的 に使えなくなった場合は、データセンター全体で、 εの値の増大を引き起こす。同様に、過負荷なマ シンやネットワーク・リンクは、一時的で局所的な εのスパイクを引き起こすことがある。
  • 263. 4 Concurrency Control この節では、TrueTimeが、コンカレンシーの コントロールまわりの正確性という性質を、い かに保証しているのか、また、これらの性質が 外的整合なトランザクション、ロックのない Read-Onlyトランザクション、過去のデータの ブロックしない読み込みといった特徴を実装す るのにどのように利用されているかを述べる。
  • 264.  これらの諸特徴は、例えば、全てのデータベース で、タイムスタンプ t での正当性検査の読み込み が、t で既にコミットされている全てのトランザク ションの効果を、正確に見ることを保証する。  さらに言えば、それはPaxosによって見られる書 き込みを(ここで、コンテキストが明確でないが、 Paxosの書き込みという)、Spannerのクライア ントの書き込みとを区別する為にも重要である。  例えば、TPCは、準備フェーズでPaxosの書き込 みを生成するが、それはSpannerのクライアント の書き込みには、照応してはいない。
  • 265. 4.1 Timestamp Management
  • 266.  テーブル2は、Spannerがサポートしている操作 をまとめたものである。  Spannerの実装は、read-writeトランザクション とread-onlyトランザクション(スナップショット・ト ランザクションとよばれたもの)、スナップショット readをサポートしている。
  • 267.  単独の書き込みは、read-writeトランザクション として実装されている。  スナップショットではない単独の読み出しは、 read-onlyトランザクションとして実装されている。  双方ともに、内部的にはリトライされる。(クライア ントは、自分でリトライのコードを各必要はない)
  • 268. read-only transaction  read-only トランザクションは、スナップショット・アイソ レーションのパフォーマンスの利点をもったタイプのトラン ザクションである。  read-only トランザクションは、いかなる書き込みも持っ ていないと、あらかじめ宣言されていなければならない。 それは、単純に、いかなる書き込みのないread-write ト ランザクションではない。  read-only トランザクションは、ロックなしで、システムが 選んだタイムスタンプで実行される。だから、書き込みは ブロックされない。  read-only トランザクションでの読み込みの実行は、十 分にアップデートされた全てのレプリカ上で遂行される。
  • 269. Snapshot read  スナップショット readは、ロックなしに実行される 過去の読み出しである。  クライアントは、スナップショット readの為にタイ ムスタンプを指定出来る。あるいは、望むタイムス タンプの古さの上限を与えて、Spannerにタイム スタンプを選ばせることも出来る。  どちらの場合でも、スナップショット readの実行 は、十分にアップデートされた全てのレプリカ上で 遂行される。
  • 270.  read-only トランザクションでも、スナップショット readでも、双方で、いったんタイムスタンプが選 ばれれば、そのタイムスタンプがガーベージ・コレ クトされていない限りは、コミットは不可避である。 結果として、クライアントはリトライ・ループの内部 で、結果をバッファリングする必要を避けられる。  サーバーが失敗した時、クライアントは、タイムス タンプと現在の読み込み位置を繰り返し与えて、 内部的に、異なるサーバーにクエリーを続ける。
  • 271. 4.1.1 Paxos Leader Leases  Spannerの Paxosの実装では、リーダーを長生 きさせる為に(デフォルトでは、10秒)、リースを 使っている。  潜在的なリーダーは、リースの投票のリクエストを 送る。定足数に達するリースの投票を受け取ると、 リーダーは、リースがあることを知る。  レプリカは書き込みに成功すると暗黙にリースの 投票を拡大し、リーダーは、リースの期限切れに 近づくと、リースの投票の拡張をリクエストする。
  • 272.  リーダーのリースの期間を、それがリースの投票 が定足数に達したことを見つけた時にスタートし、 もはや、その定足数に達しない時(いくつかが終 了したので)に終わるものと定義しよう。  Spannerは、 次のような、相互に関連のないと いう原則にディペンドしている。 それぞれのPaxosグループにとって、それぞれの Paxosリーダーのリース期間は、他の全てのリー ダーのリース期間とは、切り離されている。
  • 273.  Spannerの実装は、Paxosのリーダーが、ス レーブをリースの投票から解放することによって、 仕事を放棄することを認めている。  相互に関係がないことを変わらないように維持す る為に、Spannerは、放棄が許可されうる場合で も制約を設けている。  smaxを、リーダーが利用出来る最大のタイムス タンプとしよう。次節以降で、いつsmaxが進んで いくかを記述するだろう。 任務を放棄する以前に、 リーダーはTT.after(smax)が真になるまで、待 たないといけない。
  • 274. 4.1.2 Assigning Timestamps to RW Transactions  readとwriteのトランザクションは、ツー・フェー ズ・ロッキングを使用している。その結果、全ての ロックが獲得されるなら、いかなる時間でもタイム スタンプを割り当てられうる。ただし、その前に、 全てのロックが解放されてなければならない。  あるトランザクションでは、Spannerは、Paxos がPaxosのwriteに割り当てたタイムスタンプ、こ れはトランザクションのコミットを表しているのだが、 そのタイムスタンプを割り当てる。
  • 275.  Spannerは、次のような、単調性の原則にディペ ンドしている。  それぞれのPaxosグループの内部では、 Spannerは、リーダーをまたいでさえ、Paxos writeに単調増加する順番にタイムスタンプを割 り当てる。  一つのリーダーのレプリカは、自明なことだが、単 調増加順にタイムスタンプを割り当てられる。
  • 276.  この原則は、リーダーをまたいで、分離性の原則 を利用することで、強められる。  リーダーは、リーダーのリースの期間の範囲の中 でのみ、タイムスタンプを割り当てることが出来る。  タイムスタンプ s が割り当てられた時、s は、最 大、分離性が保存されるまでしか進められない。
  • 277. 整合性の原則:  もし、トランザクション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
  • 278.  トランザクションを実行し、タイムスタンプを割り当 てるプロトコルは、StartとCommit waitという二 つのルールに従う。それは、これらは、以下に示 すように、一緒になって、この原則を保証する。
  • 279. Startルール  協調リーダーにTiのwriteのコミットのリクエスト が到着するイベントを、e_i^serverとしよう。  Ti writeの協調リーダーは、e_i^server 以降 に計算された TT.now.latestよりも、小さくない 値を、コミット・タイムスタンプ s:iを割り当てる。  ここでは参加者リーダーは、関係ないことに注意 しよう。4.2.1節で、次のルールの実装で、彼らが いかに巻き込まれるかを記述する。
  • 280. Commit Wait ルール  協調リーダーは、TT.after(s_i)が真になるまで クライアントはTiでコミットされたデータが見えない ことを保証する。  Commit waitは、s_iが、Tiのコミットの絶対時 間より小さいことを保証する。すなわち、 s_i < t_{abs}(e_i^commit) である。  Commit waitの実装は、4.2.1節で記述される。
  • 281. 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)
  • 282. 4.1.3 Serving Reads at a Timestamp  4.1.2節で記述した単調性の原則は、Spanner が、あるreadを満たすように、レプリカの状態が 十分更新されているかを、正しく決定することを可 能にする。  全てのレプリカは、セーフ・タイム t_safe と呼ば れる値をチェックする。それは、レプリカが更新さ れた最大のタイムスタンプである。  レプリカは、もし、t <= t_safe であるタイムスタ ンプ t でならば、readを満たす。
  • 283.  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以下ではもはや起 きることはない。
  • 284.  t_safe^TMは、もし準備された(ただしコミットされていな い)トランザクション --すなわち、two-phase commitの 二つのフェーズの途中にあるトランザクションがゼロであ れば、レプリカでは ∞ である。  (参加しているスレーブでは、t_safe^TMは、実際に、レ プリカのリーダーのトランザクション・マネージャを参照して いる。この状態をこのスレーブは、Paxos writeで渡され たメタデータを通じて推論出来る。)  もし、このようなトランザクションが一つでもあるなら、その 時、これらのトランザクションによって影響を受ける状態は、 「不定」である。参加者のレプリカは、これらのトランザク ションがコミットされたのかを、未だ、知らない。
  • 285.  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 である。
  • 286. 4.1.4 Assigning Timestamps to RO Transactions  read-onlyトランザクションは、二つのフェーズで 実行される。  まず、タイムスタンプsreadを割り当て、ついで sreadでのスナップショットreadとして、トランザク ションのreadを実行する。  スナップショットreadは、十分にアップデートされ た、全てのレプリカで実行可能である。
  • 287.  トランザクションがスタートしてからの後であれば、 どんな時間でも、writeについて4.1.2節でおこ なったのと類似の議論によって、単純な割り当て sread = TT.now().latestは、外的な整合性を 保存する。  しかし、こうしたタイムスタンプは、もし、t_safeが 十分に進んでいない場合、s_readでのデータの readの実行にブロックを要求することがある。 (加えて、s_readの選択は分離性を保存する為 に、s_maxを進ませるかもしれないことに留意)
  • 288.  ブロックの機会を減らす為には、Spannerは、外 的整合性を保証するもっとも古いタイムスタンプを 割り当てるべきである。4.2.2節で、どのようにこ うしたタイムスタンプが選ばれるかを説明する。
  • 289. 4.2 Details この節では、以前には省かれた、read-write トラン ザクションとread-only トランザクションの実践的な 詳細について説明する。 同時に、アトミックなスキーマの変更の際に利用され る特別なトランザクションについて述べる。 そして、これまで述べた基本的なスキーマの精密化に ついて述べる。
  • 290. 4.2.1 Read-Write Transactions  Bigtableと同じように、トランザクションの間に起 きたwriteは、クライアントでコミットされるまで バッファーに置かれる。その結果、トランザクショ ン中のreadは、write トランザクションの影響を 見ることが出来ない。  このデザインは、Spannerではうまく機能してい る。なぜなら、readは、読み込まれたどんなデー タでもタイムスタンプを返すのに、コミットされてい ないwriteは、まだ、タイムスタンプを持たないか らである。
  • 291.  read-writeトランザクション中のreadは、デッド ロックを避ける為に、wound-waitを利用する。  クライアントは適当なグループのレプリカのリー ダーに、readを発行する。それは、readロックを 獲得してから、もっとも最近のデータを読む。  クライアントのトランザクションがオープンな間、ク ライアントは、参加者のリーダーがそのトランザク ションをタイムアウトしないようにkeepaliveメッ セージを送る。
  • 292.  クライアントが全てのreadとwriteのバッファリン グを終えたとき、two-phase commitを始める。  クライアントは調整グループを選び、それぞれの 参加者リーダーに、調整者のIDと全てのバッ ファーされているwriteとともに、コミット・メッセー ジを送る。  クライアントがtwo-phase commitを走らせるこ とで、広域のリンクで、データを二度送ることを避 ける。
  • 293.  調整者ではない参加者リーダーは、最初にwrite ロックを獲得する。  それから、以前のトランザクションで割り当てられ たどのタイムスタンプよりも大きな値を持つ準備さ れたタイムスタンプを選び(単調性を保存するた め)、Paxosを通じて準備されたレコードをログに 書き込む。  その時、全ての参加者は、準備したタイムスタン プを調整者に通知する。
  • 294.  調整者のリーダーも、最初にwriteロックを獲得 するが、準備のフェーズはスキップする。調整者 は、全ての参加者のリーダーから聞いてから、ト ランザクション全体のタイムスタンプを選ぶ。
  • 295.  コミットのタイムスタンプ s は、全ての準備のタイ ムスタンプより大きいか等しい(4.1.3で議論され た制約を満たすため)もので、調整者がコミット メッセージを受け取った時点での TT.now().latestより大きく、かつ、リーダーが以 前のトランザクションに割り当てた全てのタイムス タンプより大きい(再び、単調性を保存する為に) ものでなければならない。
  • 296.  調整リーダーは、Paxosを通じてコミット・レコードをログす る。(あるいは、もし、他の参加者を待っている間にタイム アウトになれば、abortする)  どんな調整レプリカがコミット・レコードを適用することを許 す以前に、調整リーダーは、TT.after(s)まで待つ。こうし て、4.1.2で述べた、commit-waitルールに従う。  調整リーダーは TT.now().latestに基づいてタイムスタ ンプを選ぶので、今度は、タイムスタンプが過去に属する ことが保証されるまで待つ。期待される待ち時間は、最小 で、2 ∗ εである。 この待ちは、典型的には、Paxosの通 信とオーバーラップしている。
  • 297.  commit waitの後で、調整者は、クライアントと 全ての参加リーダーに、コミットのタイムスタンプ を送る。それぞれの参加者は、Paxosを通じてト ランザクションの出力をログに書き込む。全ての 参加者は、同じタイムスタンプを適用し、そして ロックを解除する。
  • 298. 4.2.2 Read-Only Transactions  タイムスタンプを割り当てるには、readにかかわ る全てのPaxosグループの間で、交渉のフェーズ が必要である。その結果、Spannerは、全ての read-onlyトランザクションに対して、ある範囲の 表現を要求する。それは、全てのトランザクション によって読まれるであろう、キー達を要約した表 現である。Spannerは、単独のクエリーに対して、 自動的にその範囲を推論する。
  • 299.  もし、このスコープの値が、一つのPaxosグルー プによってサーブされるのなら、そのクライアント はそのグループ・リーダーに、read-only トラン ザクションを発行する。(現在のSpannerの実装 は、Paxosリーダーのもとでは、read-onlyトラン ザクションのタイムスタンプしか選べない)  そのリーダーは、s_readを割り当て、readを実 行する。一つのサイトでのreadでは、Spanner は、一般的には、TT.now().latestよりはましな 仕事をする。
  • 300.  LastTS() を、あるPaxosグループで最後にコ ミットwriteされた最後のタイムスタンプとしよう。  もし、準備中のトランザクションがないのなら、割 り当ては、s_read = LastTS()で、s_read = LastTS() で、自明のことだが、外的整合性を満 たす。このトランザクションは最後の書き込みの 結果を見ていて、それゆえに、その後に順序付け られている。
  • 301.  もし、スコープの値が、複数のPaxosグループによって サーブされているなら、いくつかの選択肢がある。もっとも 複雑な選択肢は、全てのグループ・リーダーと一回り LasTTS()に基づいたs_readについてコミュニケーション を行うことである。  Spannerは、現在は、単純な選択を実装している。クライ アントは一連の交渉を避けて、そのreadを s_read = TT.now().latest で実行させる。 (それは、safe time が来るまで待たないといけない)  トランザクションのすべてのreadは、十分にアップデート されたレプリカに送られることが出来る。
  • 302. 4.2.3 Schema-Change Transactions  TrueTimeは、Spannerに、アトミックなスキーマ の変更のサポートを可能にする。それは通常のト ランザクションでは実行が難しいだろう。なぜなら ば、参加者の数(データベース内のグループの 数)が、数百万になりうるから。  Bigtableは、一つのデータセンター内で、アトミッ クなスキーマの変更をサポートしていたが、ただ、 そのスキーマ変更は、全ての操作をブロックした。
  • 303.  Spannerのスキーマ変更トランザクションは、一 般的には、通常のトランザクションのブロックしな い変種である。  第一に、それは未来のタイムスタンプを、はっきり と割り当てる。それは準備フェーズで登録される。 その結果、数千台のサーバーをまたいだスキー マの変更は、他の並行する活動に、最低限の障 害をもたらすだけで完遂されうる。
  • 304.  第二に、暗黙のうちにスキーマにディペンドしてい るreadとwriteは、全ての登録されている時間 t のスキーマ変更のタイムスタンプと同期する。そ れらは、そのタイムスタンプが、tに先行していれ ば、前に進むが、もしそのタイムスタンプがtの後 で、スキーマ変更のタイムスタンプの後ろだとブ ロックしなければならない。TrueTimeなしでは、 スキーマ変更が、時間 tで起きると定義すること は無意味である。
  • 305. 4.2.4 Refinements  先に定義されたt_safe^TMは弱点を持っている。 一つの安全な準備段階のトランザクションが、 t_safeを進めることを妨げる。その結果、後のタ イムスタンプを持っているreadは実行出来ない。 たとえ、そのreadがそのトランザクションと競合す ることがなくても。  こうした偽の競合は、キー範囲から準備段階のト ランザクションのタイムスタンプへの細かい精度 でのマッピングで、t_safe^TMを増やしてやるこ とで、取り除くことが出来る。
  • 306.  この情報は、ロック・テーブルに格納出来る。ロッ ク・テーブルは既に、キー範囲をロック・メタデータ にマップしている。readが到着した時、キー範囲 の高精度のタイムスタンプについて、それがその readと競合するかチェックするだけでいい。
  • 307.  先に定義したLastTS()も似たような弱点を持っ ている。もし、トランザクションがコミットしたばかり なら、競合しないread-onlyトランザクションも、 そのトランザクションの後に続くように、sreadを 割り当てられる。その結果、readの実行は遅らせ られることがあり得る。  この弱点は、同様に、ロック・テーブル内のキー範 囲からコミット・タイムスタンプへの高い精度の マッピングで、LastTS()を増加させてやれば手 当が出来る。(我々は、まだ、この最適化を実装し ていない)
  • 308.  read-onlyなトランザクションが到着したら、トラ ンザクションが競合する場合には、競合する準備 段階のトランザクションがないなら(それは、高精 度のタイムスタンプから決定出来る)、LastTS() の値の最大値を取ることで、タイムスタンプを割り 当てることが出来る。
  • 309.  先に定義したt_safe^Paxosも、Paxos write が不在では先に進めないという点で弱点を持って いる。すなわち、時間 t でのスナップショッ t_readは、 その最後のwriteが t 以前に起きた Paxos グループでは実行されない。  Spannerは、この問題に、リーダーのリースの間 隔の分離性の利点を利用することで対応する。  それぞれのPaxosリーダーは、未来のwriteタイ ムスタンプが起きるようにしきい値を保ちながら、 t_safe^Paxosを前に進める。
  • 310.  それは、Paxosのシーケンス数 nから、Paxosの シーケンス数 n + 1 で割り当てられる最小のタ イムスタンプへのマッピングである、 MinNextTS(n) を維持している。  レプリカは、n を通じて適応されたとき、 t_safe^PaxosをMinNextTS(n) − 1 に進め られる。
  • 311.  単独のリーダーは、MinNextTS()の約束を簡単 に実行出来る。なぜなら、MinNextTS()で約束 されたタイムスタンプは、リーダーのリースの期間 の中にあるからである。分離性の原則は、リー ダーをまたいでMinNextTS()の約束を実行する。  もし、リーダーが、リーダーのリースの終点を超え てMinNextTS()を進めることを望むなら、まず、 リースを延長しなければならない。分離性を保存 する為に、s_maxは常にMinNextTS()の最大 値より進んでいることに留意。
  • 312.  リーダーは、デフォールトでは、8秒おきに MinNextTS()の値を進める。こうして、準備段階 のトランザクションがなくても、アイドル状態の Paxos グループの正常なスレーブは、最悪ケー スでも8秒古いのよりも大きなタイムスタンプread をサービス出来る。  リーダーは、また、スレーブからの要求に応じて、 MinNextTS()を進めることがある。

×