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

@maruyama097
丸山不二夫
Agenda
 大規模分散システムの成立
 すべては、ここから始まった
GFS, MapReduce, BigTable
 GFSからGFS2へ
 Caffeine 新しい検索システム
 Dremel インタラクティブなデータ分析
...
大規模分散システムの成立
21世紀の初頭、かってない巨大な規模の分
散システムがネットワーク上で稼働を始めた。
現在のITを領導しているのは、こうした大規
模分散システムを所有し、その上でサービス
を提供しているGoogle, Amazon, ...
Google
Amazon
Apple
Facebook
Microsoft
Google
Google
Google
Google
Facebook
Microsoft
クラウドとクラウド・デバイスの時代
 クラウドの時代は、21世紀になってから本格的に
始動した。すぐ後を追って、クラウド・デバイスの
時代が始まった。
 2004年 Google上場
 2004年 Google GFS,MapReduce...
Googleの社是とスタンス
 全世界の情報を、組織し、アクセス可能にすると
いう夢は、ほとんど達成可能なところにまで来て
いる!
 “我々は、検索を人々の役に立つようにするという

ビジネスをしている。インフラを売るビジネスをし
ている訳...
Facebookの社是とスタンス
 Facebookは、本来、会社となるために作られた
ものではなかった。それは、次のような社会的使
命を達成するために作られた。
世界を、もっとオープンで、つながったものに!
 このテクノロジーと、構築され...
現代の大規模分散システムが
ハンドルするデータの規模
Googleの検索エンジンが
処理するデータの量
 Googleの検索システムCaffeineが、一秒間に
処理するデータの量は、紙に印刷すると、3マイ
ル(4.8km)の高さになる
 A4の用紙に2KBの情報が入るとして、紙の厚さを0.2...
Facebook







毎月のアクティブ・ユーザ
8億4500万人
一日の投稿
25億
一日の「いいね」 27億
一日にアップロードされる写真 3億枚
Facebook上の友人関係 1000億
30分ごとに105TBのデータ...
Big Dataは、大きいか小さいか?
1K
1,000人
千人
1M
1,000,000人 百万人
1G
1,000,000,000人 十億人
世界人口 7G人
世界の一人一人に、2バイトコードで、1000字程
度の個人情報のプロファイルを与...
Windows Azure SQL データベース
の最大容量は、150G
Amazon DB インスタンス
なぜ、大規模分散システムに
注目する必要があるのか?
なぜ、大規模分散システムに
注目する必要があるのか?
 大規模分散システムが取り組んでいるのは、
Web上のネットワーク・メディアの発展によって、
止まることなく増え続けるアクセスと情報の増大
の中で、リアルタイム性を追求するという、現代の
...
なぜ、大規模分散システムに
注目する必要があるのか?
 重要なことは、こうした技術的な探求が、新しい
サービスの開発をめぐる、ビジネスの競争によっ
てドライブされていることである。
 サービス利用者から見て”Publicクラウド”と言わ
れ...
なぜ、大規模分散システムに
注目する必要があるのか?
 また、現代のITビジネスの競争力の中核の一つ
は、大規模分散システムでのみ提供可能なサー
ビスにある。検索サービス、エンタープライズ向け
クラウド・サービス、ソーシャル・ネットワーク・サ...
なぜ、大規模分散システムに
注目する必要があるのか?
 一般の企業・一般の開発者にとっても、こうした技
術は無縁ではない。それが現代の技術とビジネ
スの課題を反映したものである以上、そこから派
生した技術は、遅かれ早かれ、時代のIT技術に
深...
Googleの大規模分散技術
21世紀のクラウドとクラウド・デバイスの時代
を牽引してきたのはGoogleである。Google
は、大規模分散処理のシステム技術において
もいまだ卓越した地位を占めている。彼らは、
処理のリアルタイム化・正確なト...
すべては、ここから始まった
 2003年 The Google File System
 2004年 MapReduce
 2006年 BigTable
The Google File System
GFSは、安価なPCサーバからなるクラスタ上に構築
された分散ファイルシステムである。クラスタは、
2,000台以上のchunkserverからなり、Googleに
は、30以上のClusterがあ...
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
The Google File System
Gobioff氏は、2008年3月11日、悪性リンパ腫で亡くなった。
GFS Architecture
Application

(file name,chunk index)

GFS Master

/foo/bar
Chunk 2ef0

File NameSpace

GFS Client
(chunk ...
MapReduce: Simplified Data
Processing on Large Clusters
MapReduce は、関数型のプログラミン
グ・モデルに基づいた、大規模なデー
タ・セットの処理・生成を行う

http://20...
Jeffrey Dean and Sanjay Ghemawat
MapReduce: Simplied Data Processing on Large Clusters
Master

Worker

Partition0
Partition1

Split 0
Split 1

Split 2

Worker

Worker

Worker

入力ファイルと
その分割

Output
file1

Parti...
Bigtable: A Distributed Storage
System for Structured Data
Bigtable は、数千台のサーバ上のペタ
バイト単位の非常に大きなサイズにまで
スケールするようにデザインされた、構
造化...
Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh,
Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes,...
Bigtable Client

BigTableシステム構成

Bigtable Client
Library
Open

Bigtable セル

Bigtable Master

メタデータのオペレーションを実行
ロードバランシング

B...
GFSからGFS2へ
2009年、GoogleはGFSのデザインの見直し
を示唆。バッチ・システムの効率を上げる為に
デザインされた、シングル・マスターのGFSは、
分散マルチ・マスターのシステムに変わる。
同時期に開発が始まったMegasto...
2009年7月、Google大規模障害
2009年7月、Google大規模障害
 2009年7月2日, 6:45 AM から12:35 PM ま
で、Google App Engineに大規模な障害発生。
 この障害の根本的な原因は、データセンタ内の
ノードが、サーバー側できちん...
Transactions Across Datacenters
(Weekend Project)
 この障害事故の少し前、2009年5月27日 Google IO
で、Ryan Barrettは、自らのWeekend Projectとして、...
Post-mortem for
February 24th, 2010 outage
 After further analysis, we determine that
although power has returned to the ...
2009年9月、Bigtableの見直し
 2009年9月14日、Ryan Barrettは、“Migration
to a Better Datastore”を発表

http://googleappengine.blogspot.jp/2...
2011年1月
Megastore: Providing Scalable, Highly
Available Storage for Interactive Services
 http://www.cidrdb.org/cidr2011/...
Megastore
MegaStore
 Megastoreを利用したよく知られたGoogleのア
プリには、次のものがある。






Gmail
Picasa
Calendar
Android Market
AppEngine
HDFSのAvatar Node
 ちなみに、Facebookが、HDFSのMaster
Nodeの二重化、いわゆ、Avatar Nodeの実装
の次の論文を発表したのは、2011年の
SIGMODでのことであった。
 “Apache Ha...
GFS:
Evolution on Fast-forward
事故直後の2009年8月1日、Sean
Quinlanは、ACMとのインタビューに応え、
GFSのデザインの見直しを示唆。
http://queue.acm.org/detail.c...
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: Evolution on Fast-forward
 これした理由から、Googleの技術者達は、過去
2年間というもの、BigTableの利点を最大限生
かしながら、現GFSに取っては特に困難であると
証明されているいくつかの問題...
問題
 マスターは、秒あたり数千の処理しか終えること
が出来ない。
 MapReduceは、かなりの数のファイルをオープ
ンしようとする、千ものタスクを走らせるかもしれ
ない。
現在の実装

Cellあたり一つのマスター
 歴史的には、データセンターに一つのCellという
のが目標だったが、結局、multi-cellアプローチ
をとった。
 データセンターに複数のCellがある。ネットワーク
をまたいで、複数のCe...
現在の実装
複数のGFSマスター
 chunk サーバー群の上に、複数のGFSサー
バーを置く。
 配下のストレージ・プールが、複数のGFSマス
ターを持つように設定出来る。
 異なったCellをまたいだデータの分割には、アプ
リケーショ...
現在の実装
Name Space
 それぞれのアプリケーションが、マスターを持つと
しよう。(一つか、少数のマスターを)
 Name Spaceが、これらを全てをアプリケーショ
ンから隠す。namespaceを分割する静的な方法
 ログ処...
現在の実装
マスターのパフォーマンスチューニング
 最終的には、マスターのパフォーマンスのチュー
ニングにかなりの努力をした。特定のバイナリー
のチューニングに多くの力を注ぎ込むのは、
Googleでは、あまりないことである。
 一般的に、...
 この例の場合には、インパクトを持ち始めた一つ
のボトルネックがあったわけだが、我々は、マス
ターの負荷を軽くすることに、更に努力することが
価値があると感じていた。
 数千の処理から、数万の処理にスケールした時
点で、マスターは、ボトルネ...
ふりかえり
 GFSは、記録的な短期間で製品化された。 3人
のチームが、一年足らずで配備にまでこぎ着けた。
GFSが稼働している最大級のファイル・システム
であることを想起してほしい。
 開発スピードの優位性は、Googleに、巨大な成
...
 GFSの機能を最初に利用したのは、 大規模なク
ローリングとindexシステムだった。
 GFSの利用の第二の波は、大規模なデータを格
納することだった。GFSは、この新しいユースケー
スにも適応出来るように調整された。
 様々なアプリ...
Additional problems
 急速な成長の中で、64MBのチャンク・サイズが
問題になった。Googleが扱うデータが巨大な為
になされたものであったが、Gmailのように、多く
のファイルは、64MB以下で十分だった。
 ファ...
Additional Improvements
 ファイル数の増大が問題だった。マスターのメモ
リーが枯渇する前に、調整可能なのは、高々限ら
れた数のファイルだ。
 それぞれのファイルについて、メモリーに格納さ
れるメタデータが必要になった...
 この問題に対応する為に、オブジェクトを大きな
ファイルにまとめ、その内容のテーブルを作った。
 また、ファイル数とストレージの容量にquotaをか
けた。大体、引っかかるのはファイル数のquota
の方だった。
Additional Improvements
 全面的に新しいデザインの作業を始める。
 分散マルチ・マスター・モデル。
 1MBの新しいファイルサイズ。
 ファイル数問題への対応
 一万個の10KBのファイルを読む方が、100個の...
BigTable
構造化されたデータの分散ストレージ
 ファイル数の増大に対する対応策–小さなものを集約する
 数千台のマシンをまたぎ、ペタバイトまでスケールする。
 GFS上に構築され、GFS上で稼働し、GFSの原理と矛盾が
ないように...
BigTable
 もともとのアイデアは、SSTableとログ、たった二
つだけの基本構造を持つというものだった。
SSTables– Stored String Tables (key-value
pair)

 BigTableは、mu...
More initial GFS limitations/
improvements
 初期のGFSは、低い遅延の上に、高帯域(高ス
ループット)を実現するようにデザインされていた。
 バッチのアプリケーションでは、Single point...
 GFSでは三重化されたファイルに書き出すのだ
が、もし、chunkserverが死んだり、調子が悪く
なると、一つのchunkのレプリカを作る。この作業
に10秒から一分かかる。
 大規模なMapReduceの処理ならそれでもいい
が、G...
More initial GFS limitations/
improvements
 MapReduceベースの世界から、BigTableのよ
うなものに依存したインタラクティブな世界に移行
すること。
 バッチ志向の処理用にデザインされ...
 Bigtable – トランザクション・ログがボトルネック。
 二つのログファイルを同時に開いて、一つに書き込む。
それがいっぱいになったら、もう一つに書き出し、最後
にマージする。

 Gmail は、マルチ・ホーム
 Gmailア...
Compatibility issues:
 ドライバーとドライブのミスマッチが、データ破壊を
引き起こした(全てのIDEプロトコルのバージョン
をサポートしていなかった)
 厳格なチェックサムの実行が必要
 でも、少しデータの読み込みが...
Consistency Issues
 あるファイルを複数回読むと、異なるデータが返
ることがある。
 GFSは、全てのデータが全てのレプリカに書き出
されないと、次に進まない。問題は、クライアント
がクラッシュした時に起きる。
Consistency Issues
 RecordAppend 複数のライターがログに追加
出来る。ゆるい整合性。
 全てのレプリカが書き込まれたという保証がない。
データは、チャンクに一度以上、違った順序で、違った
チャンクに書き込まれ...
Initial GFS aspect that still
works Snapshot of chunk
 レプリカを置き換える
 クライアントが書き込めないロックを取り消す

 GFSは、snapshot機能もサポートしている –
c...
結論
 GFSの成績表は、10年経った今でも、ポジティブ
である。
 成功によってではなく、まだ力を発揮しているとい
う点で。
 スケールもアプリケーションも、1990年代後半の
想像をはるかに超えている。
 チャレンジなのは、ユーザーを前にした、遅延に
敏感なアプリケーションを、バッチのスループット
の為にデザインされたシステムの上でサポートす
ること。
 BigTableは助けになった。しかしそれは、GFSと
ぴったりあっていた訳ではない。...
Caffeine
Googleの新しい検索システム
2010年6月、Googleは新しい検索システム
Caffeineを稼働。MapReduceの利用を廃し
て、BigTable上でリアルタイムにインデックス
付けを行う方式に移行。あわせて、B...
Our new search index:
Caffeine
2010年6月8日
Google Webmaster Central Blog
http://googlewebmastercentral.blogs
pot.jp/2010/06/...
 本日、Caffeineと呼ばれる新しいWebインデキ
シング・システムが完成したことを報告します。
Caffeineは、Web検索で、以前のインデックスよ
り50パーセント新しい結果を提供します。それは、
私たちが提供してきた中で、最大のW...
 では、なぜ、私たちは新しいインデキシング・シス
テムを構築したのでしょうか? Web上のコンテ
ンツは、開花の時期を迎えています。単にサイズ
や数が増えたばかりではなく、ビデオや画像、
ニュースやリアルタイムに更新されるものが登場
し、普通...
Webの進化に対応し、高まるユーザーの期待に応える為に、
私たちは、Caffeineを構築しました。この図は、古いインデキシング
システムがどのように働いていたかを、Caffeineとの比較で図示
したものです。
 古いインデックスは、いくつかの層を持っていまし
た。そのいくつかは、他のものより早く更新されて
いました。主要な層は、二週間に一回更新されて
いました。古いインデックスの層を更新する為に
は、Web全体を分析してきました。そのことは、私
た...
 Caffeineでは、私たちは、Webの小さな部分を
分析し、検索インデックスを全体的には連続した
ベースの下で更新します。新しいページ、あるい
は、既存のページに新しい情報を発見すると、こ
れらを直接インデックスに追加することが出来ま
す...
 Caffeineでは、私たちは、巨大な規模でWeb
ページのインデックス付けを行います。実際、
Caffeineは、毎秒 数十万のページをパラレルに
処理します。もし、それを紙で積み上げたら毎秒3
マイルの高さになるでしょう。Caffein...
 私たちは、Caffeineを未来を胸に抱いて構築し
ました。単に新しい情報を与えるだけでなく、オン
ライン上の情報の増大とともにスケールし、より関
連する検索結果をユーザーに届ける、さらに高速
で分かりやすい検索エンジンを構築する、それは
...
Google Caffeine jolts
worldwide search machine
2010年6月9日
Interview with Matt
http://www.theregister.co.uk/2010/0
6/09/goog...
 本質的には、Googleはバッチ型のインデックス・
システムから、その場でリアルタイムでインデック
スを更新するシステムに移行したのだ。
 「我々の技術は、ページをクロールするやいなや
ページにインデックスをつけることを可能にした。
過去...
 「このことは、次のようにも考えることが出来る。
我々は、数十億のドキュメントのインデックス付け
のバッチから、(それぞれ一つの文書に対して)数
十億の「バッチ」を処理するシステムに変わったの
だと」
Google search index splits with
MapReduce
Welds BigTable to file system 'Colossus’

2010年9月9日
Interview with Lipkovitz
htt...
 新しい検索のインフラは、GFS分散ファイルシス
テムの改修版を使用している。これは、Google
File System 2、GFS2と呼ばれていたのだが、
Googleの内部では、Lipkovitzがいうように
Colossusとして知ら...
 「我々は、非常に膨大なデータから出発して、そ
れを処理してきた。8時間かそれくらい後に、この
全体の処理の出力がなされる。その結果をまた、
サービス用のシステムにコピーする。我々は、そ
うした処理を連続的に行ってきた。」
 MapRedu...
 過去数年の間、MapReduceは、MITのデータ
ベースの権威 Mike Stonebraker のような
人々から批判を受けてきた。Lipkovitzによれば、
Google自身、大分前から「同じような認識」に到
達していたという。
...
 「MapReduceは、“おちこぼれ”の問題に悩まさ
れていた。map-reduceの一連のシリーズに基
づいたシステムを作ろうとすれば、ある程度の確
率で、何かうまくいかないことが起きる。その確率
は、処理の数を増やそうと思えばそれだけ大...
 Caffeineでは、Googleは、既にBigTableに格
納されているWebマップを直接変更することで、
インデックスを更新出来る。このシステムは、
BigTable上で動く、あるフレームワークを含んで
いる。Lipkovitzは、そ...
 「開発者が、BigTable上でコードを実行するのを
助ける “計算フレームワーク” もある。このシステ
ムは、Clossusで土台を支えられている。
Clossusは、GFS2としても知られている分散スト
レージプラットフォームだ。元のG...
 Colossusは、BigTableの為に特別にデザインさ
れたものだ。そうした理由によって、GFSがそう
だったような「一般的な利用」には向いていない。
それは、特に新しいCaffeine検索インデックスシ
ステムでの利用の為に作られたも...
 「MapReduceは、決して死んだ訳ではない。
Caffeineでもバッチ処理を使うケースも存在する
し、Mapreduceは、いまも他の沢山のGoogle
のサービスのベースである。しかし、Caffeine登
場以前は、インデックス・シ...
 2004年に、GoogleはGFSとMapReduceにつ
いての研究論文を発表した。これが、オープン
ソースのHadoopプラットフォームの基礎になっ
た。それは、Yahoo, Facebook, Microsoftに
よって利用されてい...
Incrementally Indexing the
Web with Percolator
2010年10月4日
Frank Dabek and Daniel Peng
at OSDI, 2010
https://docs.google.co...
問題:Webにインデックスをつける
出力:
サービス用のドキュメント

入力:
元の生ドキュメント
times.co
m

URL

mit.ed
u

indexing

In Links

Body PageRank

nyt.co
m

...
MapReduceで重複を取り除く

Reduce

Map

インデックス・システムは沢山のMapReducesの連鎖
ドキュメント
解析

チェックサ
ムでグルー
プ化

逆リンク
MapReduceでのインデックスの更新
repository

Map

refresh

• 新しいドキュメントにインデックスつけるべきか?
o 新しいドキュメントは、以前にクロールした文書のコ
ピーかもしれない。
o 全てのレポジトリーの...
インデックス・システムの目標
理想的なインデックス・システムに何を望むか?
 大量のデータのレポジトリー
 インデックスのサイズの上限まで
 インデックスのより高い質(沢山のリンクとか)

 クロールとインデックスの間の遅延の小ささ
「...
インクリメンタルなインデックス付け

• ランダム・アクセス可能なレポジトリーを、
BigTableに保持する
• グローバル・スキャンを避けるインデックス
•インクリメンタルに複製可能な状態が、URLとして、
クロールされる

URL

Co...
BigTable上のインクリメンタルな
インデックス付け
URL
Checksum PageRank
nyt.com
0xabcdef01
6
nytimes.com 0xabcdef01
9

IsCanonical?
no
yes

Che...
Percolator:
インクリメンタルなインフラ
BigTableに分散トランザクションを追加
(0) Transaction t;
(1) string contents = t.Get(row, "raw", "doc");
(2) Ha...
Bigtableの構造
Bigtableは整列された (row, column, timestamp)
のストアである
Column1
3:
2:
RowOne
1: "I'm at
timestamp 1"
3:
RowTwo 2:
1:

...
分散トランザクションの実装

• snapshot isolation semanticsを与える

• Multi-version protocol (Bigtableのtimestampにmap)
• Two phase commit クラ...
Transaction Commit
Transaction t;
int a_bal = t.Get("Alice", "balance");
int b_bal = t.Get("Bob", "balance");
t.Set("Alice...
Notifications: tracking work
ユーザーは、"observer" をカラムに登録する
カラム中の行に書き込みが起きると実行される
それぞれのobserverは、新しいトランザクション
で走る
書き込みごとに最大で一回実...
Notificationsの実装
Dirty column: もしobserversが走るべき行なら設定
ランダム分散スキャン
中断している仕事を見つけ、observerをスレッドプール
で走らせる
スキャンは効率的である。数ビットをみるだけ
...
Running Percolator
Each machine runs:
Worker binary linked
with observer code.
Bigtable tablet server
GFS chunkserver

•
•...
MR v. Percolator: Performance

Operating Point

Fraction of Repository refreshed / hour
MR v. Percolator: Experience
我々は、MRベースのパイプラインをPercolatorに
変換した。
Pros:
新鮮さ: インデックスの遅延は数日から数分にまで落ちた
スケーラビリティ:
o 一層のスループット: も...
Running 1000 threads on Linux
Percolatorは、thread-per-request モデル
Pros:
アプリケーションの開発者は、ストレートなコードを書ける
スタックトレースが重要 デバッグ、プロファイル...
System Building by D. Rumsfeld
There are known unknowns.
That is to say
We know there are some things
We do not know.
But ...
Unknown unknowns
CPUs that get XOR wrong periodically: checksum "failures”
Bigtable scaling: can't delete files fast enoug...
結論
Percolatorは、“Caffeine” Web検索インデックス・シ
ステムを構成している
50% 新鮮な検索結果
3倍大きなレポジトリー

•
•

Webスケールの分散トランザクションの「存在証明」
Large-scale Incremental
Processing Using Distributed
Transactions and Notifications

Daniel Peng and Frank Dabek
Presented...
Tradeoffs
 Percolator trades efficient use of
resources for scalability.
 Caffeine (the Percolator-based indexing
system...
Overview of Percolator design
 Percolator is built on top of Bigtable.
 A percolator system consists of three binaries
t...
Overview of Percolator design
 Data is organized into Bigtable rows and
columns, with Percolator metadata
stored alongsid...
Overview of Percolator design
 An observer is like an event-handler
that is invoked whenever a userspecified column chang...
Large-scale Incremental
Processing Using Distributed
Transactions and Notifications

2010年10月4日
D Peng, F Dabek - OSDI, 20...
Transaction in BigTable
 c:data
 c:lock

データ自身を格納
コミットされていないトランザクションは、
このCellに書き込む。PrimaryLock
の場所を含んでいる。
 c:write コミットされた現在のデータ。
データのタイムスタンプを格...
 初期状態: Joeの口座には2ドル、Bobの口座には、10
ドルが、はいっている。
 bal:writeに、データのタイムスタンプが書き込まれること
によって初めて、そのデータは外部から見えるようになる。
 送金のトランザクションは、Lockカラムに書き込むことで
Bobの口座の残高をロックすることから始まる。このロック
は、このトランザクションのprimaryである。
 このトランザクションは、また、その開始タイムスタンプ 7
にデータを書...
 トランザクションは、次にJoeの口座をロックして、ふたた
び開始タイムスタンプ 7に、Joeの新しい残高を書き込む。
 このロックは、このトランザクションのsecondaryである。
primaryロック(”Bob”行の”bal”カラム)...
 トランザクションは、コミットのポイントに到達する。
 primaryロックを消して、それをコミットタイムスタンプと呼
ばれる新しいタイムスタンプ 8の下で、新しい書き込みレ
コードと置き換える。この書き込みレコードは、データが格
納されて...
 トランザクションは、secondary セルに書き込みデータを
追加し、ロックを消去することで完了する。
 この例の場合には、ただ一つのsecondary Joeがあるだ
けである。
Transaction in BigTable 詳細
1
2
3
4
5
6
7

class Transaction {
struct Write { Row row; Column col; string value; };
vector<Write> writes_ ;
int start_...
データの読み込み:bool Get(Row row,
Column c, string* value) の働き

 row中の、コンカレントなwriteを通知するロック
c:lockを、過去からstart_ts_まで、チェックする。
 ペン...
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:...
書き込み前処理:bool Prewrite(Write w,
Write primary) の働き

 Prewriteは、セルcをロックしようとする。競合が
あるとfalseを返し、Abortする。
 c:writeをチェックし、スタート...
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

//Prewriteは、セルcをロックしようとする。競合があるとfalseを返す。
bool Prewrite(Write w, Write prima...
コミット:bool Commit() の働き
 writes_ベクターの先頭がprimary、それ以降を
secondariesとする。
 primary、secondariesへのPreWriteが失敗
すれば、コミット失敗。
 コミッ...
コミット:bool Commit() の働き
 コミット・タイムスタンプのc:lockを消す。
 コミットする。

 続いて、secondariesをコミット。secondaries
の各Writeごとに、
 コミット・タイムスタンプの...
41 bool Commit() {
42 Write primary = writes_[0];
43 vector<Write> secondaries(writes_.begin()+1, writes_.end());
44 if (!...
60 // 第二フェーズ セカンダリーセルにレコードを書き出す
61 for (Write w : secondaries) {
62
bigtable::Write(w.row, w.col+"write", commit_ts, start...
bool UpdateDocument(Document doc) {
Transaction t(&cluster);
t.Set(doc.url(), "contents", "document", doc.contents());
int...
Dremel
インタラクティブなデータ分析
リアルタイムへの要求は、とまらない。2010
年に論文が公開されたDremelは、
MapReduceの100倍のスピードで、巨大な
データを、インタラクティブに解析する。以前か
らGoogle内部で...
Dremel: Interactive Analysis
of Web-Scale Datasets
Proc. of the 36th Int'l Conf on Very
Large Data Bases (2010), pp. 33033...
Dremelのアイデア
 第一。分散検索エンジンで利用されている、木構
造のアーキテクチャー。Web検索と同様に、検索
は、木構造をたどって行われ、それを書き換える。
検索結果は、下位の木構造から得られる答えを
集約することで行われる。
 ...
Dremelのアイデア
 第三。Dremelは、カラム単位で分割されたデー
タ構造を利用する。カラム型のストレージは、読み
込むデータを少なくして、圧縮が簡単に出来るの
で、CPUのコストを削減する。カラム型のデータ・
ストアは、リレーショナ...
Google Dremel
Dremelが利用されている領域











クロールされたWebドキュメントの解析
Androidマーケットで、インスロールされたアプリの追跡
Google製品のクラッシュ報告
Google BooksのOCRの...
message Document {
required int64 DocId;
optional group Links {
repeated int64 Backward;
repeated int64 Forward; }
repeate...
Document

Repetetion Level
Definition Level

DocID 0

Links? 1

Names* 1 1

Backward* 1 Forward* 1 Language* 2 Url? 2
2
2
...
DocId: 10
Links
Forward: 20
Forward: 40
Forward: 60
Name
Language
Code: 'en-us‘
Country: 'us'
Language
Code: 'en'
Url: 'ht...
DocId: 10
Links
Forward: 20
Forward: 40
Forward: 60
Name
Language
Code: 'en-us‘
Country: 'us'
Language
Code: 'en'
Url: 'ht...
DocId: 10
Links
Forward: 20
Forward: 40
Forward: 60
Name
Language
Code: 'en-us‘
Country: 'us'
Language
Code: 'en'
Url: 'ht...
サンプルの格納状態
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...
Dremelの検索言語
SELECT DocId AS Id,
COUNT(Name.Language.Code) WITHIN Name AS Cnt,
Name.Url + ',' + Name.Language.Code AS Str
F...
検索の木構造
 SELECT A, COUNT(B) FROM T GROUP BY A

 SELECT A, SUM(c) FROM (R11 UNION ALL ...R1n)
GROUP BY A
R1i = SELECT A, C...
MapReduceとDremel

numRecs: table sum of int;
numWords: table sum of int;
emit numRecs <- 1;
emit numWords <- CountWords(in...
結論
 スキャンベースの検索は、一兆個以上のディスク上の
データセットに対して、インタラクティブなスピードで実行出
来る。
 数千ノードを含むシステムで、カラムとサーバーの数に関
して、ほとんどリニアーなスケーラビリティーを達成出来る。
...
Spanner
Googleの新しい分散データベース
2012年に論文が公開されたSpannerは、
key-valueをベースにした拡張性と、RDBの
ACIDなトランザクション処理能力を併せ持つ
強力な分散データベースである。タイムスタン
...
Spanner: Google’s
Globally-Distributed Database
Wilson Hsieh
representing a host of authors
OSDI 2012
http://static.google...
Spannerとは何か?
分散マルチバージョンデータベース
汎用のトランザクション(ACID)
SQL言語のサポート
スキーム化されたテーブル
Semi-relationalなデータモデル

既に、製品として稼働している
 Googl...
Example: Social Network
x1000

x1000

San Francisco
Brazil
Seattle
User posts
Arizona
Friend lists

US
x1000
Spain
OSDI 20...
Spanner概観
 特徴: Lock-freeな、分散readトランザクション
 特質: 分散トランザクションの外的整合性保証
 グローバルなスケールでは、最初のシステム

 実装: Concurrency controlとRepli...
読み込みのトランザクション
 友達の最近のポストのページを生成する
 友達のリストとそのポストの整合的なビュー

何故、整合性が重要なのか?
1. 不審な人物を友達から削除する
2. Post P: “我々の政府は、抑圧的である…”
OSD...
単一のマシン

マイページの生成

Friend1 post
Friend2 post
…
Friend999 post
Friend1000 post

OSDI 2012

User posts
Friend lists

175
複数のマシン

Friend1 post
Friend2 post

User posts
Friend lists

…
Friend999 post
Friend1000 post

OSDI 2012

マイページの生成
User pos...
複数のデータセンター
Friend1 post
US

User posts
x1000
Friend lists

Friend2 post
Spain
…

User posts
x1000
Friend lists
マイページの生成

F...
書き込みとバージョン管理
 書き込みのトランザクションには、厳密なTwo-PhaseLockを使う。
 それぞれのトランザクションTには、タイムスタンプsが割り当
てられる。
 トランザクションTによって書き込まれたデータは、タイムスタ
...
スナップショットを同期する
グローバルな壁時計
==
外的整合性:
コミットの順序は、グローバルな壁時計の
順序を尊重する

==
タイムスタンプの順序は、与えられた
グローバルな壁時計の
順序を尊重する
タイムスタンプの順序 == コミットの...
タイムスタンプとグローバル・クロック
 書き込みのトランザクションについては、厳密な
two-phase lockingを適用する。
 ロックが保持されている間、タイムスタンプを割り当
てる。
Acquired locks

Release...
タイムスタンプの不変量
• タイムスタンプの順序 == コミットの順序
T
1

T
2

• タイムスタンプの順序は、グローバルな壁時計
の順序を尊重する
T
3

T
4
TrueTime
 “グローバルな壁時計の時間” は、ある制限の
範囲だが、不確実性を持つ。
TT.now()
earliest

time
latest

2*ε
タイムスタンプとTrueTime
Acquired locks

Release locks

T

Pick s = TT.now().latest s Wait until TT.now().earliest > s
Commit wait...
コミットのWaitとレプリケーション
Achieve consensus
Start consensus
Notify slaves
Acquired locks

Release locks

T
Pick s

Commit wait do...
Commit Wait and 2-Phase
Commit
Start logging Done logging
Acquired locks

Release locks

TC
Acquired locks

Committed
Noti...
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

...
我々がカバー出来たことは何か?
 データセンター間の、ロックフリーな、read トラ
ンザクション
 外的整合性
 タイムスタンプの割り当て
 TrueTime
 時間の不確実性は、待つことでしのぐことが出来る

OSDI 2012
...
我々がカバーしなかったこと
 現在の時刻を、どうよむのか。
 アトミックなスキーマの変更
 大部分は、ノン・ブロッキングである
 未来のタイムスタンプでコミットする

 過去のノン・ブロッキングな読み込み
 レプリカの効率的な更新
...
TrueTime Architecture
GPS
timemaster

GPS
timemaster

GPS
timemaster

GPS
timemaster

Atomicclock
timemaster

GPS
timemast...
TrueTime implementation
now = reference now + local-clock offset
ε = reference ε + worst-case local-clock drift

ε
+6ms

r...
時計が狂うとどうなるか?
 タイムスタンプの割り当てが、外的整合性を破
ることになるだろう。
 一年間のデータに基づけば、そういうことはあ
りそうにない。
 時計が狂うより、CPUがおかしくなる可能性の方
が、6倍以上ありそうである。

...
将来の課題
 TrueTimeの改善
 Lower ε < 1 ms

 データベースの諸特徴をきちんと構築する
 基本的な特徴の実装を終える
 多様な検索パターンを効果的にサポートする

OSDI 2012

195
結論
 時計の不確実性を time APIで具体化する
 知らないことを知ることは、知らないことを知らない
より、いいことである
 不確実性を利用した、アルゴリズムを再考すること

 強いセマンティックは達成可能である
 大規模なスケ...
Knowledge Graph
Googleの新しい検索技術
2012年の5月、Googleは、「Knowledge
Graph」と名付けられた新しい検索サービス
をアメリカで開始した。言うまでもなく検索は、
Googleのコア・コンピーテンス...
Google Knowledge Graph
新しい検索の三つの特徴
 正しい「もの」を見つける。(Find the right
thing)
 最良の要約を得る。(Get the best
summary)
 さらに深く、さらに広く。(...
検索結果のパーソナライズ
Googleの
検索結果の「パーソナライズ」
 人々は、コンテキストとパーソナライズを混同して
いる。この2つは別のものだ。コンテキストには、
言語、場所、年度等が因子として含まれる。
 過去の検索の履歴は、パーソナライズに利用さ
れている...
Googleの
検索結果の「パーソナライズ」
 URLの最後の部分に、&pws=0 を追加すると機
能する。ただ、パーソナライズを消すだけで、コン
テキスト(言語、場所、年度)は消さない。
 全てのパーソナライズをオフにする方法はある。
G...
まとめ
Google
Google
資料編
 Snapshot Isolation “A Critique of
ANSI SQL Isolation Levels”
 Spanner: Google’s GloballyDistributed Database
Snapshot Isolation
“A Critique of ANSI SQL Isolation
Levels”
http://t.co/2HBae9l5gK
Start-Timestamp
 Snapshot Isolationでは、それぞれのトランザ
クションは、Start-Timestampと呼ばれる、トラ
ンザクションを開始した時刻のデータのスナップ
ショット(コミットされた)からデータを読...
ReadとWrite
 Snapshot Isolationの中のトランザクションは、
そのStart-Timestampからのスナップショットの
データが維持可能である限り、読み込みがブロッ
クされることはない。
 トランザクションでの書...
Commit-Timestamp
 トランザクションT1が、コミットの準備ができた時、
それはCommit-Timestampを取得するのだが、
それは、既に存在するStart-Timestampあるい
は Commit-Timestampよ...
First-Commiter-Wins
 そうでない場合、T1はアボートする。この「最初に
コミットしたものが勝つ」という特徴が、更新が失
われるのを防止する。
 T1がコミットされると、そのStart-Timestamps
がT1のCom...
Spanner: Google’s GloballyDistributed Database
James C. Corbett, Jeffrey Dean, Michael Epstein,
Andrew Fikes, Christopher ...
Abstract
Abstract
 Spannerは、スケーラブルで、マルチ・バージョン、
グローバルに分散し、レプリカの同期を行う、
Googleのデータベースである。
 それは、グローバルなスケールでのデータの分散
と外的整合的な分散トランザクションを...
Abstract
 このAPIとその実装は、外的な整合性と、
Spannerの全域にわたる、過去のデータのブ
ロックしない呼び出し、ロックのないread-onlyト
ランザクション、そしてアトミックなスキーマの変更
といった強力な諸特徴をサポ...
1 Introduction
概観
 Spannerは、Googleで、デザイン・構築・配備さ
れたスケーラブルでグローバルな分散データベー
スである。
 もっとも高い抽象のレベルでは、 それは、全世界
に広がっているデータセンター内の沢山のPaxos
状態マシン群をま...
ReplicaとResharding
 データの複製は、グローバルな可用性と地理的な局所性
の為に利用されている。クライアントは、レプリカ間で自動
的にフェール・オーバーする。
 Spannerは、データの量やサーバーの数が変化するに
応じ...
ReplicaとAvailability
 我々のシステムの最初の利用者は、Googleの広告シス
テムのバックエンドを書き換えたF1であった。F1は、アメ
リカ全土に広がった5つのレプリカを利用した。
 他のアプリの大部分は、相対的には独...
SpannerとBigTable
 ただ、我々は、この分散システムのインフラの上に、デー
タベースの重要な諸特徴を、デザインし実装することにも、
非常に多くの時間をかけてきた。
 たとえ、多くのプロジェクトが、BigTableを使ってハッピ...
SpannerとBigTable
 Googleの多くのアプリケーションは、相対的には
貧弱な書き込み性能にもかかわらず、半リレー
ショナルなデータモデルと、複製の同期のサポー
トの故に、Megastoreを選んできた。
 その結果、Spa...
Spannerのデータ形式
 データは、スキーマを持つ半リレーショナルな
テーブルに格納される。データはバージョンづけ
られ、それぞれのバージョンは、自動的にそのコ
ミット・タイムでタイムスタンプが与えられる。古い
データのバージョンは、設定...
グローバルに分散したデータベースとしての
Spannerの、興味深い特徴
 第一に、データの複製の設定は、アプリによって細かい粒
度でコントロール出来る。アプリは、どのデータセンターが
どのデータを持つのか、データはユーザーからどのくらい
離...
グローバルに分散したデータベースとしての
Spannerの、興味深い特徴
 第二に、Spannerは、分散データベースでは実
装するのが難しい二つの特徴を持つ。
 読み書きについての外的整合性
 ある時点での、データベースをまたいだグロー...
Timestamp
 こうした特徴は、たとえトランザクションが分散していたとし
ても、Spannerがトランザクションにグローバルに意味の
あるコミット・タイムスタンプを割り当てるという事実によっ
て可能になった。
 このタイムスタンプは、...
TrueTime API
 こうした性質を可能にした重要なものは、TrueTime API
とその実装である。
 このAPIは、直接に、時計の不確実さを、あらわに示すも
のである。そして、Spannerのタイムスタンプは、実装が
提供する不...
2 Implementation
2.1 Spanserver Software Stack
2.2 Directories and Placement
2.3 Data Model
Implementation
 この節では、Spannerの構造とその実装の基礎
にある理論的な根拠を述べる。
 その後、複製と局所性を管理するのに利用され、
データ移動の単位である、「ディレクトリー」という
抽象について述べる。
 最後...
UniverseとZone
 Spannerの配備は、「ユニバース」と呼ばれる。
Spannerがデータをグローバルに管理している
としても、ほんの少数の稼働しているユニバース
があるだけだろう。
 我々は現在、テスト/プレイグラウンド・ユ...
Zone
 ゾーンは、管理上の配備の単位である。一群のゾーンは、
また、その上にデータの複製を置くことが出来る、場所群
でもある。
 新しいデータセンターがサービスを開始したり、逆に、古
いデータセンターがサービスを停止したりした場合、ゾー...
ZonemasterとLocationProxy
 図1は、Spannerユニバースのサーバーを図示
したものである。
 ゾーンは、一つのゾーン・マスターと、百から数千
の間のスパンサーバーを持っている。前者は、ス
パンサーバーにデータを割...
UniverseMasterとPlacementDriver
 ユニバース・マスターとプレスメント・ドライバーは、現在のと
ころ、一つしかない。
 ユニバース・マスターは、第一義的には、全てのゾーンにつ
いてのステイタス情報が表示され、イン...
2.1 Spanserver Software Stack
この節では、スパンサーバーの実装にフォー
カスして、我々のBigTableをベースにした実
装の上に、どのように、複製と分散トランザク
ションが、実現されたかを示す。
Spanserver Software Stack
 ソストウェア・スタックは、次の図2に示されている。
スタックの一番下では、スパンサーバーが、100
個から1000個の間のタブレットと呼ばれるデータ
構造のインスタンスに責任を持っている。...
 Bigtableとは異なって、Spannerは、タイムスタンプを
データに割り当てる。ここが、Spannerがキー・バリュー・
ストアよりは、マルチ・バージョン・データベースにずっと似
ている重要なポイントである。
 タブレットの状態は、...
 (初期のSpannerの具体化では、タブレットごと
に複数のPaxos状態マシンをサポートしていた。
それによって、もっと柔軟な複製の設定が可能と
なるのだが、そのデザインの複雑さの為に、我々
は、それを放棄した。)
 それぞれの状態マシ...
 現在のSpannerの実装では、全てのPaxosが二
度ログを書き出している。一つは、タブレットのロ
グで、もう一つはPaxosのログである。この選択
は、expendiencyによるもので、最終的には修
正したいと思っている。
 我々の...
Paxos
 Paxos状態マシンは、マッピングのバッグのレプ
リカを整合的に実装するのに利用されている。そ
れぞれの複製のキー・バリュー・マッピングの状
態は、対応するタブレットに格納される。
 書き出しは、リーダーのPaxosプロトコル...
 リーダーである全てのレプリカのスパンサーバー
は、コンカレンシーのコントロールを実装する為の
ロック・テーブルを実装している。
 ロック・テーブルは、ツー・フェーズ・ロッキングの
為の状態を含んでいる。それは、一連のキーを
ロック状態にマ...
 BigTableでもSpannerでも、両方とも、我々は。
長いトランザクション(例えば、レポートの生成。こ
れ数分単位の時間がかかる)の為のデザインをし
てきた。こうした処理は、衝突がある場合には、楽
観的コンカレンシー・コントロールでは...
 リーダーである全てのレプリカでは、それぞれの
スパンサーバーは、分散トランザクションをサポー
トする為にトランザクション・マネージャーも実装し
ている。
 トランザクション・マネージャーは、参加者のリー
ダーを実装する為に利用される。その...
 もしトランザクションが、一つのPaxosグループを
含んでいるだけなら(大部分のトランザクションの
場合)、それは、トランザクション・マネージャをバ
イパス出来る。というのは、ロック・テーブルと
Paxosが一緒になって、トランザクションの...
 参加グループの一つが、調整役に選ばれる。そ
のグループの参加者のリーダーは、調整役リー
ダーと呼ばれ、グループのスレーブは、調整役ス
レーブと呼ばれる。
 それぞれのトランザクション・マネージャの状態は。
直下のPaxosグループに格納さ...
2.2 Directories and Placement
2.2 Directories and Placement
 キー・バリュー・マッピングのバッグの上で、
Spannerの実装は、「ディレクトリー」と呼ばれる
「バケット化」の抽象をサポートしている。それは、
共通の接頭辞を共有する連続的なキ...
 ディレクトリーは、データの配置の単位である。
ディレクトリー内の全てのデータは、同じ複製設定
を持つ。
 データがPaxosグループ間を移動する時、それ
は図3が示すように、ディレクトリーからディレクト
リーへと移動する。
 Spann...
 クライアントの操作が実行中でも、ディレクトリー
は移動出来る。50MBのディレクトリーは、数秒で
移動出来ると考えてよい。
 Paxosグループが複数のディレクトリーを含みう
るという事実は、Spannerのタブレットが
BigTable...
 その代わりに、Spannerのタブレットは、複数の
行空間の分割を包み込んだコンテナーなのであ
る。しばしば一緒にアクセスされる複数のディレク
トリーを、近い場所に置くことが可能であるという
ことで、我々は、この決定を行った。
 Move...
 Movedirは、大きなかたまりのデータ移動の際に
実行される、読み出し・書き込みのブロックを避け
る為に、単一のトランザクションとしては、実装さ
れていない。
 その代わりに、 movedirは、データ移動が始
まったという事実を登録し...
 ディレクトリーは、また、その複製の地理的なプロ
パティ(短く、「配置」という)が、アプリによって指
定される最小の単位である。
 配置指定の言語は、複製の設定を管理する責任
とは分離されている。
 管理者は、二つの次元をコントロールする...
 アプリは、それぞれのデータベース、あるいは、
個々のディレクトリーを、これらのオプションの組
み合わせでタグづけて、データがいかに複製され
るかをコントロールする。
 例えば、あるアプリでは、エンドユーザー各人の
データを、次のように、自...
 説明を分かりやすくする為に、随分、単純化した
のだが、実際には、Spannerはディレクトリーが
あまりに大きくなった時には、それを複数のフラグ
メントに分割するだろう。
 フラグメントは、異なるPaxosグループでサービス
を受ける(そ...
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
大規模分散システムの現在 -- GFS, MapReduce, BigTableはどう変化したか?
Upcoming SlideShare
Loading in …5
×

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

5,058 views

Published on

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

No Downloads
Views
Total views
5,058
On SlideShare
0
From Embeds
0
Number of Embeds
110
Actions
Shares
0
Downloads
122
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

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

  1. 1. 大規模分散システムの現在 GFS, MapReduce, BigTableはどう進化したか @maruyama097 丸山不二夫
  2. 2. Agenda  大規模分散システムの成立  すべては、ここから始まった GFS, MapReduce, BigTable  GFSからGFS2へ  Caffeine 新しい検索システム  Dremel インタラクティブなデータ分析  Spanner 新しい分散データベース  Knowledge Graph 新しい検索技術  資料編
  3. 3. 大規模分散システムの成立 21世紀の初頭、かってない巨大な規模の分 散システムがネットワーク上で稼働を始めた。 現在のITを領導しているのは、こうした大規 模分散システムを所有し、その上でサービス を提供しているGoogle, Amazon, Apple, Facebookといった企業達である。
  4. 4. Google
  5. 5. Amazon
  6. 6. Apple
  7. 7. Facebook
  8. 8. Microsoft
  9. 9. Google Google
  10. 10. Google
  11. 11. Google
  12. 12. Facebook
  13. 13. Microsoft
  14. 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. 15. Googleの社是とスタンス  全世界の情報を、組織し、アクセス可能にすると いう夢は、ほとんど達成可能なところにまで来て いる!  “我々は、検索を人々の役に立つようにするという ビジネスをしている。インフラを売るビジネスをし ている訳ではない。” --- Lipkovitz, Google
  16. 16. Facebookの社是とスタンス  Facebookは、本来、会社となるために作られた ものではなかった。それは、次のような社会的使 命を達成するために作られた。 世界を、もっとオープンで、つながったものに!  このテクノロジーと、構築されるべきインフラの規 模は、前例のないものです。私たちは、これこそ が私たちが集中することの出来る、もっとも重要 な問題だと確信しています。 -- 「Facebook上場申請文書」
  17. 17. 現代の大規模分散システムが ハンドルするデータの規模
  18. 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. 19. Facebook       毎月のアクティブ・ユーザ 8億4500万人 一日の投稿 25億 一日の「いいね」 27億 一日にアップロードされる写真 3億枚 Facebook上の友人関係 1000億 30分ごとに105TBのデータがスキャンされる。
  20. 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. 21. Windows Azure SQL データベース の最大容量は、150G
  22. 22. Amazon DB インスタンス
  23. 23. なぜ、大規模分散システムに 注目する必要があるのか?
  24. 24. なぜ、大規模分散システムに 注目する必要があるのか?  大規模分散システムが取り組んでいるのは、 Web上のネットワーク・メディアの発展によって、 止まることなく増え続けるアクセスと情報の増大 の中で、リアルタイム性を追求するという、現代の IT技術のもっとも重要な課題である。  大規模分散システムは、新しいネットワーク・マー ケットの台頭の中で、大規模の情報をハンドルし ながらリアルタイム性を志向し、同時に、正確なト ランザクションを担保することを求められている。 これらの課題は、技術的に挑戦的なものである。
  25. 25. なぜ、大規模分散システムに 注目する必要があるのか?  重要なことは、こうした技術的な探求が、新しい サービスの開発をめぐる、ビジネスの競争によっ てドライブされていることである。  サービス利用者から見て”Publicクラウド”と言わ れるものは、ビジネスの主体からみれば、 Google、Amazon、Microsoft...らが「所有」す る”Privateクラウド”であると考えることも出来る。  彼らのビジネスの力の一つは、大規模分散シス テムを開発し運用し、新しいサービスを提供し続 ける技術的な力にある。
  26. 26. なぜ、大規模分散システムに 注目する必要があるのか?  また、現代のITビジネスの競争力の中核の一つ は、大規模分散システムでのみ提供可能なサー ビスにある。検索サービス、エンタープライズ向け クラウド・サービス、ソーシャル・ネットワーク・サー ビスは、その代表的なものである。  ただ、現在の大規模分散システムは、その力を全 面的に開花させている訳ではない。それは発展 途上にある。また、それによって提供可能な新し いサービスも、今後、続々と登場してくるであろう。 そこには、ビジネス的にも、もっと大きな可能性が ある。
  27. 27. なぜ、大規模分散システムに 注目する必要があるのか?  一般の企業・一般の開発者にとっても、こうした技 術は無縁ではない。それが現代の技術とビジネ スの課題を反映したものである以上、そこから派 生した技術は、遅かれ早かれ、時代のIT技術に 深い影響を与えていくだろうから。
  28. 28. Googleの大規模分散技術 21世紀のクラウドとクラウド・デバイスの時代 を牽引してきたのはGoogleである。Google は、大規模分散処理のシステム技術において もいまだ卓越した地位を占めている。彼らは、 処理のリアルタイム化・正確なトランザクション の実現にむけて、そのインフラ技術の見直し をすすめている。
  29. 29. すべては、ここから始まった  2003年 The Google File System  2004年 MapReduce  2006年 BigTable
  30. 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. 31. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System Gobioff氏は、2008年3月11日、悪性リンパ腫で亡くなった。
  32. 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. 33. MapReduce: Simplified Data Processing on Large Clusters MapReduce は、関数型のプログラミン グ・モデルに基づいた、大規模なデー タ・セットの処理・生成を行う http://209.85.163.132/papers/mapreduce-osdi04.pdf
  34. 34. Jeffrey Dean and Sanjay Ghemawat MapReduce: Simplied Data Processing on Large Clusters
  35. 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. 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. 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. 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. 39. GFSからGFS2へ 2009年、GoogleはGFSのデザインの見直し を示唆。バッチ・システムの効率を上げる為に デザインされた、シングル・マスターのGFSは、 分散マルチ・マスターのシステムに変わる。 同時期に開発が始まったMegastoreは、現 在のGoogleのサービスの主力になる。
  40. 40. 2009年7月、Google大規模障害
  41. 41. 2009年7月、Google大規模障害  2009年7月2日, 6:45 AM から12:35 PM ま で、Google App Engineに大規模な障害発生。  この障害の根本的な原因は、データセンタ内の ノードが、サーバー側できちんとしたチェックを行 わずに、不適切に構成されたFileHandleを送り つけたことに起因するGFS Master serverのバ グであった。これを処理しようとして、Masterは、 スタック・オーバーフローを起こした。
  42. 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. 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. 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. 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. 46. Megastore
  47. 47. MegaStore  Megastoreを利用したよく知られたGoogleのア プリには、次のものがある。      Gmail Picasa Calendar Android Market AppEngine
  48. 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. 49. GFS: Evolution on Fast-forward 事故直後の2009年8月1日、Sean Quinlanは、ACMとのインタビューに応え、 GFSのデザインの見直しを示唆。 http://queue.acm.org/detail.cfm?id= 1594206
  50. 50. GFS: Evolution on Fast-forward  GFSの単一マスターで行くという決定は、実際に は、設計の非常に早い段階でなされたものだ。主 要には、デザインをシンプルなものにするというの が、その理由だ。  ただ、問題は、すぐに起きていた。ストレージの容 量が、数百テラからペタバイトに、さらには数十ペ タに増大するにつれて、マスターが維持しなけれ ばならないメタデータの割合は、増えていった。
  51. 51. GFS: Evolution on Fast-forward  同様に、データのボリュームとともに、リカバリー のデータを探す為にメタデータをスキャンするとい うような操作がリニアなスケールで増えていく。こ うして、マスターに要求される仕事の量は、本質 的に増大する。
  52. 52. GFS: Evolution on Fast-forward  GFSが、いまや、多くの挑戦にさらされているの は、疑問の余地はない。一例を挙げれば、不断に 増大するユーザーの大群と直面していて遅延が 大きな問題となるアプリケーションを、本来は、 バッチ・システムの効率を上げる為にデザインさ れたシステムの上でサポートしていることの、不 格好さは、誰の目にも明らかである。
  53. 53. GFS: Evolution on Fast-forward  BigTableの登場は、この点では、いくらかの助け にはなった。ただ、明らかになったのは、 BigTableは、実際には、GFSとは、最良の組み 合わせではなかったということだ。事実、この組み 合わせは、GFSシステムの単一マスターのデザ インのボトルネックとしての限界を、他の場合より も、はるかに明らかなものとしただけだった。
  54. 54. GFS: Evolution on Fast-forward  これした理由から、Googleの技術者達は、過去 2年間というもの、BigTableの利点を最大限生 かしながら、現GFSに取っては特に困難であると 証明されているいくつかの問題を攻略する、新し い分散マスターシステムのデザインに取り組んで きた。
  55. 55. 問題  マスターは、秒あたり数千の処理しか終えること が出来ない。  MapReduceは、かなりの数のファイルをオープ ンしようとする、千ものタスクを走らせるかもしれ ない。
  56. 56. 現在の実装 Cellあたり一つのマスター  歴史的には、データセンターに一つのCellという のが目標だったが、結局、multi-cellアプローチ をとった。  データセンターに複数のCellがある。ネットワーク をまたいで、複数のCellは、関連づけられた、た だし異なったファイルシステムとして機能する。
  57. 57. 現在の実装 複数のGFSマスター  chunk サーバー群の上に、複数のGFSサー バーを置く。  配下のストレージ・プールが、複数のGFSマス ターを持つように設定出来る。  異なったCellをまたいだデータの分割には、アプ リケーションが責任を持つ。
  58. 58. 現在の実装 Name Space  それぞれのアプリケーションが、マスターを持つと しよう。(一つか、少数のマスターを)  Name Spaceが、これらを全てをアプリケーショ ンから隠す。namespaceを分割する静的な方法  ログ処理システムでは、いったん一つのCellのロ グを使い果たすと、複数のGFS Cell に移動する。  Namespaceファイルは、ログ・データが、異なる Cellをまたがって分割されているかを記述する。
  59. 59. 現在の実装 マスターのパフォーマンスチューニング  最終的には、マスターのパフォーマンスのチュー ニングにかなりの努力をした。特定のバイナリー のチューニングに多くの力を注ぎ込むのは、 Googleでは、あまりないことである。  一般的に、我々のアプローチは、ほどほどに動く ようになったら、スケールさせることにフォーカス するというものだ。これはたいていはうまく機能し て、一般的には、スケールさせることでパフォーマ ンスが得られる。
  60. 60.  この例の場合には、インパクトを持ち始めた一つ のボトルネックがあったわけだが、我々は、マス ターの負荷を軽くすることに、更に努力することが 価値があると感じていた。  数千の処理から、数万の処理にスケールした時 点で、マスターは、ボトルネックになった。
  61. 61. ふりかえり  GFSは、記録的な短期間で製品化された。 3人 のチームが、一年足らずで配備にまでこぎ着けた。 GFSが稼働している最大級のファイル・システム であることを想起してほしい。  開発スピードの優位性は、Googleに、巨大な成 長を可能にした。
  62. 62.  GFSの機能を最初に利用したのは、 大規模なク ローリングとindexシステムだった。  GFSの利用の第二の波は、大規模なデータを格 納することだった。GFSは、この新しいユースケー スにも適応出来るように調整された。  様々なアプリケーションが、GFSをイメージして開 発されるようになった。
  63. 63. Additional problems  急速な成長の中で、64MBのチャンク・サイズが 問題になった。Googleが扱うデータが巨大な為 になされたものであったが、Gmailのように、多く のファイルは、64MB以下で十分だった。  ファイル数のカウントは、また、別の問題になった。 ログの数が増え続けた。フロントエンドのサー バーはログを書き出すのだが、それがクラッシュ すると、更に大量のログを吐き出す。それは、想 定よりはるかに大きなデータだった。
  64. 64. Additional Improvements  ファイル数の増大が問題だった。マスターのメモ リーが枯渇する前に、調整可能なのは、高々限ら れた数のファイルだ。  それぞれのファイルについて、メモリーに格納さ れるメタデータが必要になった。ファイル名とチャ ンクの情報。  もし、平均的なファイルサイズが、64MB以下で あれば、ストレージに対するマスター上のオブジェ クトの数の比率は低下する。
  65. 65.  この問題に対応する為に、オブジェクトを大きな ファイルにまとめ、その内容のテーブルを作った。  また、ファイル数とストレージの容量にquotaをか けた。大体、引っかかるのはファイル数のquota の方だった。
  66. 66. Additional Improvements  全面的に新しいデザインの作業を始める。  分散マルチ・マスター・モデル。  1MBの新しいファイルサイズ。  ファイル数問題への対応  一万個の10KBのファイルを読む方が、100個の1MB のファイルを読むより、シークに時間がかかる。  一つのマスターに100M個のファイル。数百のマス ターという構成。
  67. 67. BigTable 構造化されたデータの分散ストレージ  ファイル数の増大に対する対応策–小さなものを集約する  数千台のマシンをまたぎ、ペタバイトまでスケールする。  GFS上に構築され、GFS上で稼働し、GFSの原理と矛盾が ないように設計された。  アプリケーションにも見られるが、実際には、インフラの一 部  システムのエラーに非常に敏感に対応  クローリングとindexシステムに利用された  沢山の小規模なデータを利用するアプリは、BigTable を使う  BigTableは、単にファイル数問題を扱うために設計さ れたものではない。それ以上の意図があった
  68. 68. BigTable  もともとのアイデアは、SSTableとログ、たった二 つだけの基本構造を持つというものだった。 SSTables– Stored String Tables (key-value pair)  BigTableは、mutableなログと、データを圧縮し たimmutableなSSTableの上に構築された。  GFSには、どんなデータでも書き込みが出来る。 しかし、大部分のユーザーは、結局、BigTable の二つのデータ構造、SSTableとログを使うよう になった。
  69. 69. More initial GFS limitations/ improvements  初期のGFSは、低い遅延の上に、高帯域(高ス ループット)を実現するようにデザインされていた。  バッチのアプリケーションでは、Single point of failureも許される。  ただ、ビデオのサービスでは、そうはいかない。
  70. 70.  GFSでは三重化されたファイルに書き出すのだ が、もし、chunkserverが死んだり、調子が悪く なると、一つのchunkのレプリカを作る。この作業 に10秒から一分かかる。  大規模なMapReduceの処理ならそれでもいい が、Gmailでは、一分の遅れは受け入れられな い。  初期のマスターのフェイル・オーバーには、数分 かかっていたが、今では、それは数十秒に短縮さ れた。
  71. 71. More initial GFS limitations/ improvements  MapReduceベースの世界から、BigTableのよ うなものに依存したインタラクティブな世界に移行 すること。  バッチ志向の処理用にデザインされたファイルシ ステムの上に、インタラクティブなDBを構築する ことは、挑戦的な課題だ。
  72. 72.  Bigtable – トランザクション・ログがボトルネック。  二つのログファイルを同時に開いて、一つに書き込む。 それがいっぱいになったら、もう一つに書き出し、最後 にマージする。  Gmail は、マルチ・ホーム  Gmailアカウントの一つのインスタンスが不調になっ たら、他のデータセンターに移る。(これは、可用性を 高めるのを助ける)
  73. 73. Compatibility issues:  ドライバーとドライブのミスマッチが、データ破壊を 引き起こした(全てのIDEプロトコルのバージョン をサポートしていなかった)  厳格なチェックサムの実行が必要  でも、少しデータの読み込みが遅れるのはOKである  これらの対策は、マスターに新しいデータを追加 して、もっと沢山の状態を管理することで可能に なった。
  74. 74. Consistency Issues  あるファイルを複数回読むと、異なるデータが返 ることがある。  GFSは、全てのデータが全てのレプリカに書き出 されないと、次に進まない。問題は、クライアント がクラッシュした時に起きる。
  75. 75. Consistency Issues  RecordAppend 複数のライターがログに追加 出来る。ゆるい整合性。  全てのレプリカが書き込まれたという保証がない。 データは、チャンクに一度以上、違った順序で、違った チャンクに書き込まれうる。等々。  問題があれば、新しいプライマリーが新しいオフ セットを取り出す。  ファイルを指定出来ない  ゆるい整合性は、価値があるというより苦痛になる  ファイルあたり単一の書き込み、順番付けされた書き 込みが、整合性の為には必要である。
  76. 76. Initial GFS aspect that still works Snapshot of chunk  レプリカを置き換える  クライアントが書き込めないロックを取り消す  GFSは、snapshot機能もサポートしている – clone  非常に強力なのに、広くは利用されていない  実装が難しい。ただ、本当のsnapshotとして、実装を 試みた。
  77. 77. 結論  GFSの成績表は、10年経った今でも、ポジティブ である。  成功によってではなく、まだ力を発揮しているとい う点で。  スケールもアプリケーションも、1990年代後半の 想像をはるかに超えている。
  78. 78.  チャレンジなのは、ユーザーを前にした、遅延に 敏感なアプリケーションを、バッチのスループット の為にデザインされたシステムの上でサポートす ること。  BigTableは助けになった。しかしそれは、GFSと ぴったりあっていた訳ではない。むしろそれは、ボ トルネックの限界を、明らかにした。  BigTableの利点を最大限生かした、分散マス ターのシステムをデザインすること。
  79. 79. Caffeine Googleの新しい検索システム 2010年6月、Googleは新しい検索システム Caffeineを稼働。MapReduceの利用を廃し て、BigTable上でリアルタイムにインデックス 付けを行う方式に移行。あわせて、BigTable のトランザクション処理に大幅な改良を加える。
  80. 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. 81.  本日、Caffeineと呼ばれる新しいWebインデキ シング・システムが完成したことを報告します。 Caffeineは、Web検索で、以前のインデックスよ り50パーセント新しい結果を提供します。それは、 私たちが提供してきた中で、最大のWebコンテン ツのコレクションです。  それが、ニュースであれ、ブログであれ、フォーラ ムへの投稿であれ、それが公開されると、以前に 可能だったものよりはるかに早く、関連するコンテ ンツへのリンクを見つけることが出来ます。
  82. 82.  では、なぜ、私たちは新しいインデキシング・シス テムを構築したのでしょうか? Web上のコンテ ンツは、開花の時期を迎えています。単にサイズ や数が増えたばかりではなく、ビデオや画像、 ニュースやリアルタイムに更新されるものが登場 し、普通のWebページもリッチで複雑なものに なっています。加えて、人々の検索に対する期待 も、以前に比べて高度なものになっています。検 索者は、最新の関連するコンテンツを見つけるこ とを望み、公開者は、公開した瞬間にでも、それ が見つかることを期待します。
  83. 83. Webの進化に対応し、高まるユーザーの期待に応える為に、 私たちは、Caffeineを構築しました。この図は、古いインデキシング システムがどのように働いていたかを、Caffeineとの比較で図示 したものです。
  84. 84.  古いインデックスは、いくつかの層を持っていまし た。そのいくつかは、他のものより早く更新されて いました。主要な層は、二週間に一回更新されて いました。古いインデックスの層を更新する為に は、Web全体を分析してきました。そのことは、私 たちがページを見つけるのと、それをユーザーに 利用可能にすることの間には、大きな遅れがあっ たことを意味します。
  85. 85.  Caffeineでは、私たちは、Webの小さな部分を 分析し、検索インデックスを全体的には連続した ベースの下で更新します。新しいページ、あるい は、既存のページに新しい情報を発見すると、こ れらを直接インデックスに追加することが出来ま す。こうして、それがいつどこで公開されても、い まだかってなかった新鮮な情報を、ユーザーは見 つけることが出来るのです。
  86. 86.  Caffeineでは、私たちは、巨大な規模でWeb ページのインデックス付けを行います。実際、 Caffeineは、毎秒 数十万のページをパラレルに 処理します。もし、それを紙で積み上げたら毎秒3 マイルの高さになるでしょう。Caffeineは、一つ のデータベースに約一億ギガバイトのストレージ をあてています。そして一日に数十万ギガバイト の割合で情報を追加しています。この情報を蓄え るには、大型のiPadが、625,000個必要です。 これを端から端にならべると、40マイル以上にな ります。
  87. 87.  私たちは、Caffeineを未来を胸に抱いて構築し ました。単に新しい情報を与えるだけでなく、オン ライン上の情報の増大とともにスケールし、より関 連する検索結果をユーザーに届ける、さらに高速 で分かりやすい検索エンジンを構築する、それは 強固な土台なのです。ですので、期待して注目し てください。今後の数ヶ月のうちにも、さらなる改 良が行われることを。
  88. 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. 89.  本質的には、Googleはバッチ型のインデックス・ システムから、その場でリアルタイムでインデック スを更新するシステムに移行したのだ。  「我々の技術は、ページをクロールするやいなや ページにインデックスをつけることを可能にした。 過去には、インデックスの更新の度に、Web全体 の分析を行っていたので、我々は大規模なバッチ で(しばしば数十億ページに及ぶ)ページにイン デックスをつけていた。Caffeineでは、Webの小 さな部分で分析が出来るので、 インデックスを連 続的に更新出来る。」
  90. 90.  「このことは、次のようにも考えることが出来る。 我々は、数十億のドキュメントのインデックス付け のバッチから、(それぞれ一つの文書に対して)数 十億の「バッチ」を処理するシステムに変わったの だと」
  91. 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. 92.  新しい検索のインフラは、GFS分散ファイルシス テムの改修版を使用している。これは、Google File System 2、GFS2と呼ばれていたのだが、 Googleの内部では、Lipkovitzがいうように Colossusとして知られているという。  「Caffeineはデータベース・ドリブンで、BigTable を変化させたインデックス・システムである。 Googleは、このシステムを論じた論文を、来月 行われるUSENIX Symposium on Operating Systems Design and Implementation (OSDI) で発表する。」
  93. 93.  「我々は、非常に膨大なデータから出発して、そ れを処理してきた。8時間かそれくらい後に、この 全体の処理の出力がなされる。その結果をまた、 サービス用のシステムにコピーする。我々は、そ うした処理を連続的に行ってきた。」  MapReduceは、Googleが望むように出来るだ け早くインデックスを更新することを、Googleに 許さなかった。リアルタイムWebの時代、Google は数秒のうちにインデックスを更新することを求 められていた。
  94. 94.  過去数年の間、MapReduceは、MITのデータ ベースの権威 Mike Stonebraker のような 人々から批判を受けてきた。Lipkovitzによれば、 Google自身、大分前から「同じような認識」に到 達していたという。  「MapReduceは、リアルタイムに近い出来事に 必要な計算には、向いていない。MapReduceは、 一連のバッチ処理からなる。一般的には、最初の 処理が終わるまでは、次のフェーズあるいは次の 処理を始めることは出来ない。」
  95. 95.  「MapReduceは、“おちこぼれ”の問題に悩まさ れていた。map-reduceの一連のシリーズに基 づいたシステムを作ろうとすれば、ある程度の確 率で、何かうまくいかないことが起きる。その確率 は、処理の数を増やそうと思えばそれだけ大きな ものになる。問題が起きた時、ほんの少しの時間 ですむ処理でさえも、何も出来なくなる。だから、 我々は、MapReduceを取り除いた。」
  96. 96.  Caffeineでは、Googleは、既にBigTableに格 納されているWebマップを直接変更することで、 インデックスを更新出来る。このシステムは、 BigTable上で動く、あるフレームワークを含んで いる。Lipkovitzは、それを従来のデータベース・ プログラミングでの「データベース・トリガー」にた とえた。「それは完全にインクリメンタルだ。」 Googleは、新しいページがクロールされる度に、 全体を再構築することなく、必要に応じてインデッ クスを更新出来る。
  97. 97.  「開発者が、BigTable上でコードを実行するのを 助ける “計算フレームワーク” もある。このシステ ムは、Clossusで土台を支えられている。 Clossusは、GFS2としても知られている分散スト レージプラットフォームだ。元のGFSは、Google が望むようにはスケールしなかった。」
  98. 98.  Colossusは、BigTableの為に特別にデザインさ れたものだ。そうした理由によって、GFSがそう だったような「一般的な利用」には向いていない。 それは、特に新しいCaffeine検索インデックスシ ステムでの利用の為に作られたものだ。それでも、 他のGoogleのサービスに、あるかたちでは利用 されるかもしれない。ただ、それは、Googleのイ ンフラ全体にわたるものとしてはデザインされた たぐいのものではない。
  99. 99.  「MapReduceは、決して死んだ訳ではない。 Caffeineでもバッチ処理を使うケースも存在する し、Mapreduceは、いまも他の沢山のGoogle のサービスのベースである。しかし、Caffeine登 場以前は、インデックス・システムがMapReduce の最大のアプリケーションであった。それで、この プラットフォームの利用は、大きく減少してきた。」
  100. 100.  2004年に、GoogleはGFSとMapReduceにつ いての研究論文を発表した。これが、オープン ソースのHadoopプラットフォームの基礎になっ た。それは、Yahoo, Facebook, Microsoftに よって利用されている。しかし、GoogleはGFSと MapReduceを超えて進もうとしている。  「世界の残りの部分が、我々より遅れていると主 張するつもりはない。我々は、検索を役に立つも のにするビジネスをしている。インフラを売るビジ ネスをしている訳ではない。」
  101. 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. 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. 103. MapReduceで重複を取り除く Reduce Map インデックス・システムは沢山のMapReducesの連鎖 ドキュメント 解析 チェックサ ムでグルー プ化 逆リンク
  104. 104. MapReduceでのインデックスの更新 repository Map refresh • 新しいドキュメントにインデックスつけるべきか? o 新しいドキュメントは、以前にクロールした文書のコ ピーかもしれない。 o 全てのレポジトリーの再マップが要求される。
  105. 105. インデックス・システムの目標 理想的なインデックス・システムに何を望むか?  大量のデータのレポジトリー  インデックスのサイズの上限まで  インデックスのより高い質(沢山のリンクとか)  クロールとインデックスの間の遅延の小ささ 「新鮮さ」 MapReduceのインデックス・システムは、クロール からインデックスまで、数日かかる。
  106. 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. 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. 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. 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. 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. 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. 112. Notifications: tracking work ユーザーは、"observer" をカラムに登録する カラム中の行に書き込みが起きると実行される それぞれのobserverは、新しいトランザクション で走る 書き込みごとに最大で一回実行される:メッセー ジの畳み込み Document • • • RawDocument RawDocumen Loader tLoader Document DocumentPr Processor ocessor DocumentPr Exporter ocessor DocumentPr LinkInverter ocessor アプリケーションは、一連のobserverのつながりと して構造化される
  113. 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. 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. 115. MR v. Percolator: Performance Operating Point Fraction of Repository refreshed / hour
  116. 116. MR v. Percolator: Experience 我々は、MRベースのパイプラインをPercolatorに 変換した。 Pros: 新鮮さ: インデックスの遅延は数日から数分にまで落ちた スケーラビリティ: o 一層のスループット: もっと沢山のCPUを買えばいい o より大きなレポジトリー: ディスクスペースの制限のみ 運用面: 「落ちこぼれ」に耐性がある Cons: 並列性を考える必要がある ドキュメントあたりの処理コストが高価である(~2x) • • • • •
  117. 117. Running 1000 threads on Linux Percolatorは、thread-per-request モデル Pros: アプリケーションの開発者は、ストレートなコードを書ける スタックトレースが重要 デバッグ、プロファイルが容易 メニーコア・マシンに容易にスケールする Cons: カーネルのスケーラビリティ:プロセスがexitする間、1000 個のスレッドが働いている時、カーネルロックが保持される ローカルスレッドのストレージの検出がライブラリーにない キャッシュ等とのロックの競合 • • • • • •
  118. 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. 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. 120. 結論 Percolatorは、“Caffeine” Web検索インデックス・シ ステムを構成している 50% 新鮮な検索結果 3倍大きなレポジトリー • • Webスケールの分散トランザクションの「存在証明」
  121. 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. 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. 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. 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. 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. 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. 127. Transaction in BigTable
  128. 128.  c:data  c:lock データ自身を格納 コミットされていないトランザクションは、 このCellに書き込む。PrimaryLock の場所を含んでいる。  c:write コミットされた現在のデータ。 データのタイムスタンプを格納。  c:notify ヒント: observerが走る必要がある かもしれない  c:ack O Observer “O”が走った。最後に 成功した実行のタイムスタンプを格納。
  129. 129.  初期状態: Joeの口座には2ドル、Bobの口座には、10 ドルが、はいっている。  bal:writeに、データのタイムスタンプが書き込まれること によって初めて、そのデータは外部から見えるようになる。
  130. 130.  送金のトランザクションは、Lockカラムに書き込むことで Bobの口座の残高をロックすることから始まる。このロック は、このトランザクションのprimaryである。  このトランザクションは、また、その開始タイムスタンプ 7 にデータを書き込む。
  131. 131.  トランザクションは、次にJoeの口座をロックして、ふたた び開始タイムスタンプ 7に、Joeの新しい残高を書き込む。  このロックは、このトランザクションのsecondaryである。 primaryロック(”Bob”行の”bal”カラム)への参照を含ん でいる。  クラッシュでこのロックが立ち往生して、トランザクションが ロックを解消したいと思った時、このロックの解消を同期す るためにprimaryの場所が必要になる。
  132. 132.  トランザクションは、コミットのポイントに到達する。  primaryロックを消して、それをコミットタイムスタンプと呼 ばれる新しいタイムスタンプ 8の下で、新しい書き込みレ コードと置き換える。この書き込みレコードは、データが格 納されているタイムスタンプへのポインターを含んでいる。  これ以降、”Bob”行の”bal”カラムを読むものは、値 $3 を見ることになる。
  133. 133.  トランザクションは、secondary セルに書き込みデータを 追加し、ロックを消去することで完了する。  この例の場合には、ただ一つのsecondary Joeがあるだ けである。
  134. 134. Transaction in BigTable 詳細
  135. 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. 136. データの読み込み:bool Get(Row row, Column c, string* value) の働き  row中の、コンカレントなwriteを通知するロック c:lockを、過去からstart_ts_まで、チェックする。  ペンディングされたロックがあれば、クリーンを試 みて待つ。なければ、次に進む。  c:writeをチェックして、過去からstart_ts_まで にコミットされた、書き込みをみつける。なければ、 データはない。  c:writeからコミットされたタイムスタンプを取得。  c:dataから、コミット・タイムスタンプ時点での値 を読み出す。
  137. 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. 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. 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. 140. コミット:bool Commit() の働き  writes_ベクターの先頭がprimary、それ以降を secondariesとする。  primary、secondariesへのPreWriteが失敗 すれば、コミット失敗。  コミット・タイムスタンプを取得する。  まず、primaryをコミット  c:lockのスタート・タイムスタンプ時点での値を読み込 む。なければ、コミット失敗。  コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。
  141. 141. コミット:bool Commit() の働き  コミット・タイムスタンプのc:lockを消す。  コミットする。  続いて、secondariesをコミット。secondaries の各Writeごとに、  コミット・タイムスタンプのc:writeに、 スタートタイムス タンプに書かれたデータへのポインターを書き込む。  コミット・タイムスタンプのc:lockを消す。  コミット成功
  142. 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. 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. 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. 145. Dremel インタラクティブなデータ分析 リアルタイムへの要求は、とまらない。2010 年に論文が公開されたDremelは、 MapReduceの100倍のスピードで、巨大な データを、インタラクティブに解析する。以前か らGoogle内部で利用されていたが、2012年、 BigQueryとして、公開サービス開始。
  146. 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. 147. Dremelのアイデア  第一。分散検索エンジンで利用されている、木構 造のアーキテクチャー。Web検索と同様に、検索 は、木構造をたどって行われ、それを書き換える。 検索結果は、下位の木構造から得られる答えを 集約することで行われる。  第二。Dremelは、SQL-likeな検索言語をサ ポートする。それは、HiveやPigとはことなり、 Map-Reduceには変換されずに、ネーティブに 検索を実行する。
  148. 148. Dremelのアイデア  第三。Dremelは、カラム単位で分割されたデー タ構造を利用する。カラム型のストレージは、読み 込むデータを少なくして、圧縮が簡単に出来るの で、CPUのコストを削減する。カラム型のデータ・ ストアは、リレーショナルなデータの解析には採 用されてきたが、我々の知る限り、ネストしたデー タ構造へのその拡張は、行われてこなかった。
  149. 149. Google Dremel
  150. 150. Dremelが利用されている領域           クロールされたWebドキュメントの解析 Androidマーケットで、インスロールされたアプリの追跡 Google製品のクラッシュ報告 Google BooksのOCRの結果. スパムの解析 Google Mapのmapタイルのデバッグ BigtableインスタンスのTabletマイグレーションの管理 Googleの分散ビルドシステム上での実行テスト結果 数十万のディスクのDisk I/O 統計 Googleデータセンターで実行されているジョブの、リソー ス・モニタリング  Googleのコードベースの、シンボルと従属性
  151. 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. 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. 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. 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. 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. 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. 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. 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. 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. 160. 結論  スキャンベースの検索は、一兆個以上のディスク上の データセットに対して、インタラクティブなスピードで実行出 来る。  数千ノードを含むシステムで、カラムとサーバーの数に関 して、ほとんどリニアーなスケーラビリティーを達成出来る。  DBMSとまったく同様に、MapReduceは、カラム型のス トレージの恩恵を受ける。  レコードの収集とパージングは、コストがかかる。ソフト ウェアの層は(検索実行の層を超えて)、直接カラム指向 のデータを利用出来るようになる必要がある。
  161. 161. Spanner Googleの新しい分散データベース 2012年に論文が公開されたSpannerは、 key-valueをベースにした拡張性と、RDBの ACIDなトランザクション処理能力を併せ持つ 強力な分散データベースである。タイムスタン プ・ベースのトランザクション処理に必要な正 確な時間を得る為に、GPSや原子時計を利用。 その上に、時間の不確実性を組み込んでいる。
  162. 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. 163. Spannerとは何か? 分散マルチバージョンデータベース 汎用のトランザクション(ACID) SQL言語のサポート スキーム化されたテーブル Semi-relationalなデータモデル 既に、製品として稼働している  Googleの広告データのストレージとして  sharded MySQL を置き換えている OSDI 2012 171
  164. 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. 165. Spanner概観  特徴: Lock-freeな、分散readトランザクション  特質: 分散トランザクションの外的整合性保証  グローバルなスケールでは、最初のシステム  実装: Concurrency controlとReplication と2PCの統合  正当性とパフォーマンス  可能にした技術: TrueTime  Interval-basedなグローバル時間 OSDI 2012 173
  166. 166. 読み込みのトランザクション  友達の最近のポストのページを生成する  友達のリストとそのポストの整合的なビュー 何故、整合性が重要なのか? 1. 不審な人物を友達から削除する 2. Post P: “我々の政府は、抑圧的である…” OSDI 2012 174
  167. 167. 単一のマシン マイページの生成 Friend1 post Friend2 post … Friend999 post Friend1000 post OSDI 2012 User posts Friend lists 175
  168. 168. 複数のマシン Friend1 post Friend2 post User posts Friend lists … Friend999 post Friend1000 post OSDI 2012 マイページの生成 User posts Friend lists 177
  169. 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. 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. 171. スナップショットを同期する グローバルな壁時計 == 外的整合性: コミットの順序は、グローバルな壁時計の 順序を尊重する == タイムスタンプの順序は、与えられた グローバルな壁時計の 順序を尊重する タイムスタンプの順序 == コミットの順序 OSDI 2012 182
  172. 172. タイムスタンプとグローバル・クロック  書き込みのトランザクションについては、厳密な two-phase lockingを適用する。  ロックが保持されている間、タイムスタンプを割り当 てる。 Acquired locks Release locks T Pick s = now() OSDI 2012 183
  173. 173. タイムスタンプの不変量 • タイムスタンプの順序 == コミットの順序 T 1 T 2 • タイムスタンプの順序は、グローバルな壁時計 の順序を尊重する T 3 T 4
  174. 174. TrueTime  “グローバルな壁時計の時間” は、ある制限の 範囲だが、不確実性を持つ。 TT.now() earliest time latest 2*ε
  175. 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. 176. コミットのWaitとレプリケーション Achieve consensus Start consensus Notify slaves Acquired locks Release locks T Pick s Commit wait done
  177. 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. 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. 179. 我々がカバー出来たことは何か?  データセンター間の、ロックフリーな、read トラ ンザクション  外的整合性  タイムスタンプの割り当て  TrueTime  時間の不確実性は、待つことでしのぐことが出来る OSDI 2012 190
  180. 180. 我々がカバーしなかったこと  現在の時刻を、どうよむのか。  アトミックなスキーマの変更  大部分は、ノン・ブロッキングである  未来のタイムスタンプでコミットする  過去のノン・ブロッキングな読み込み  レプリカの効率的な更新 OSDI 2012 191
  181. 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. 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. 183. 時計が狂うとどうなるか?  タイムスタンプの割り当てが、外的整合性を破 ることになるだろう。  一年間のデータに基づけば、そういうことはあ りそうにない。  時計が狂うより、CPUがおかしくなる可能性の方 が、6倍以上ありそうである。 OSDI 2012 194
  184. 184. 将来の課題  TrueTimeの改善  Lower ε < 1 ms  データベースの諸特徴をきちんと構築する  基本的な特徴の実装を終える  多様な検索パターンを効果的にサポートする OSDI 2012 195
  185. 185. 結論  時計の不確実性を time APIで具体化する  知らないことを知ることは、知らないことを知らない より、いいことである  不確実性を利用した、アルゴリズムを再考すること  強いセマンティックは達成可能である  大規模なスケール != 弱いセマンティックス OSDI 2012 196
  186. 186. Knowledge Graph Googleの新しい検索技術 2012年の5月、Googleは、「Knowledge Graph」と名付けられた新しい検索サービス をアメリカで開始した。言うまでもなく検索は、 Googleのコア・コンピーテンスである。 Googleは、検索にどのような新しさを持ち込 もうとしているのか?
  187. 187. Google Knowledge Graph 新しい検索の三つの特徴  正しい「もの」を見つける。(Find the right thing)  最良の要約を得る。(Get the best summary)  さらに深く、さらに広く。(Go deeper and broader)
  188. 188. 検索結果のパーソナライズ
  189. 189. Googleの 検索結果の「パーソナライズ」  人々は、コンテキストとパーソナライズを混同して いる。この2つは別のものだ。コンテキストには、 言語、場所、年度等が因子として含まれる。  過去の検索の履歴は、パーソナライズに利用さ れている。もし、「ローマ」を検索して次に「ホテル」 を検索すれば、検索結果のいくつかは、ローマの ホテルのものになるだろう。  履歴上の過去のクリックも、一つの因子となる。も し、検索結果中の一つのサイトに対してクリックし て、明らかな嗜好を示せば、次の検索では、その サイトは上位にランクされるかもしれない。
  190. 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. 191. まとめ
  192. 192. Google
  193. 193. Google
  194. 194. 資料編  Snapshot Isolation “A Critique of ANSI SQL Isolation Levels”  Spanner: Google’s GloballyDistributed Database
  195. 195. Snapshot Isolation “A Critique of ANSI SQL Isolation Levels” http://t.co/2HBae9l5gK
  196. 196. Start-Timestamp  Snapshot Isolationでは、それぞれのトランザ クションは、Start-Timestampと呼ばれる、トラ ンザクションを開始した時刻のデータのスナップ ショット(コミットされた)からデータを読み込む。こ の時刻は、トランザクションの最初の読み込みの 時刻の前の時刻になる。  トランザクションのStart-Timestamp以降にア クティブになった他のトランザクションによる更新 は、このトランザクションからは見えない。
  197. 197. ReadとWrite  Snapshot Isolationの中のトランザクションは、 そのStart-Timestampからのスナップショットの データが維持可能である限り、読み込みがブロッ クされることはない。  トランザクションでの書き込み(updates, inserts, deletes)もまた、このスナップショットに 反映される。もしトランザクションが、このデータに 二度目のアクセス(reads あるいは updates)を するなら、ふたたび、読み出される。
  198. 198. Commit-Timestamp  トランザクションT1が、コミットの準備ができた時、 それはCommit-Timestampを取得するのだが、 それは、既に存在するStart-Timestampあるい は Commit-Timestampより、大きな値を持つ。  トランザクションは、T1の実行間隔 [StartTimestamp, Commit-Timestamp] 内にCommit-Timestampを持つ他のトランザ クションT2が、 T1が書き出したデータと同じデー タを書き出していない場合に限り、コミットに成功 する。
  199. 199. First-Commiter-Wins  そうでない場合、T1はアボートする。この「最初に コミットしたものが勝つ」という特徴が、更新が失 われるのを防止する。  T1がコミットされると、そのStart-Timestamps がT1のCommit-Timestampより大きい、全て のトランザクションに、その変更は見えるようにな る。
  200. 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. 201. Abstract
  202. 202. Abstract  Spannerは、スケーラブルで、マルチ・バージョン、 グローバルに分散し、レプリカの同期を行う、 Googleのデータベースである。  それは、グローバルなスケールでのデータの分散 と外的整合的な分散トランザクションをサポートし た、初めてのシステムである。  この論文は、Spannerがどのような構造を持つ か、その諸特徴、様々なデザインの決定の基礎 にある理論的な根拠、時計の不確実性を明らか にする全く新しい time APIについて述べたもの である。
  203. 203. Abstract  このAPIとその実装は、外的な整合性と、 Spannerの全域にわたる、過去のデータのブ ロックしない呼び出し、ロックのないread-onlyト ランザクション、そしてアトミックなスキーマの変更 といった強力な諸特徴をサポートする上で、 本質 的に重要なものである。
  204. 204. 1 Introduction
  205. 205. 概観  Spannerは、Googleで、デザイン・構築・配備さ れたスケーラブルでグローバルな分散データベー スである。  もっとも高い抽象のレベルでは、 それは、全世界 に広がっているデータセンター内の沢山のPaxos 状態マシン群をまたいで、データを分割したデー タベースである。  Spannerは、数百のデータセンターをまたいだ数 百万のマシンと、数兆行のデータベースにスケー ルアップするように設計されている。
  206. 206. ReplicaとResharding  データの複製は、グローバルな可用性と地理的な局所性 の為に利用されている。クライアントは、レプリカ間で自動 的にフェール・オーバーする。  Spannerは、データの量やサーバーの数が変化するに 応じて、マシン間でデータを再分割する。それは、マシン 間で(データセンター間でさえ)、自動的にデータを移動し て、負荷のバランスを取り、マシンの失敗に対応する。  アプリケーションは、広域の自然災害に直面しても、内部 で、あるいは大陸をまたいでも、データを複製することに よって、高い可用性の為に、Spannerを利用出来る。
  207. 207. ReplicaとAvailability  我々のシステムの最初の利用者は、Googleの広告シス テムのバックエンドを書き換えたF1であった。F1は、アメ リカ全土に広がった5つのレプリカを利用した。  他のアプリの大部分は、相対的には独立な事故のモード を想定してではあるが、一つの地理的な領域内で、3から 5のデータセンターに、データを複製するだろう。というの は、大部分のアプリケーションは、一つか二つのデータセ ンターで事故が起きても、生き残ることが出来る限りは、 高い可用性の上の低い遅延の方を選ぶだろう。  Spannerの主なフォーカスは、データセンターをまたいだ 複製データの管理に置かれている。
  208. 208. SpannerとBigTable  ただ、我々は、この分散システムのインフラの上に、デー タベースの重要な諸特徴を、デザインし実装することにも、 非常に多くの時間をかけてきた。  たとえ、多くのプロジェクトが、BigTableを使ってハッピー だとしても、我々は、ある種のアプリに取っては、 BigTableは使うには難しくなることがあるという不満を、 一貫して受け取ってきた。例えば、複雑でスキーマが変化 する、あるいは、広域に複製があるにしても、強い整合性 が欲しいというようなアプリだ。(同じような要求は、他の 著者からもなされていた。)
  209. 209. SpannerとBigTable  Googleの多くのアプリケーションは、相対的には 貧弱な書き込み性能にもかかわらず、半リレー ショナルなデータモデルと、複製の同期のサポー トの故に、Megastoreを選んできた。  その結果、Spannerは、BigTableのようなバー ジョンづけられたkey-valueストアから、テンポラ ルなマルチバージョン・データベースへと進化して きた。
  210. 210. Spannerのデータ形式  データは、スキーマを持つ半リレーショナルな テーブルに格納される。データはバージョンづけ られ、それぞれのバージョンは、自動的にそのコ ミット・タイムでタイムスタンプが与えられる。古い データのバージョンは、設定可能なガーベージコ レクション・ポリシーの元に置かれる。そうして、ア プリは、古いタイムスタンプのデータを読むことが 出来る。  Spannerは、一般的な目的のトランザクションを サポートし、SQLベースの検索言語を提供する。
  211. 211. グローバルに分散したデータベースとしての Spannerの、興味深い特徴  第一に、データの複製の設定は、アプリによって細かい粒 度でコントロール出来る。アプリは、どのデータセンターが どのデータを持つのか、データはユーザーからどのくらい 離れているか(読み込みの遅延をコントロールする)、レプ リカはお互いにどれくらい離れているか(書き込みの遅延 をコントロールする)、そして、どのくらいの数のレプリカが 維持されているか(耐久性・可用性・読み込みのパフォー マンスをコントロールする)等をコントロールする制約条件 を指定出来る。  データは、また、データセンター間のリソースの利用のバ ランスをとるシステムによって、動的かつ透過的にデータ センター間を移動出来る。
  212. 212. グローバルに分散したデータベースとしての Spannerの、興味深い特徴  第二に、Spannerは、分散データベースでは実 装するのが難しい二つの特徴を持つ。  読み書きについての外的整合性  ある時点での、データベースをまたいだグローバルに 整合的な読み込み  こうした特徴は、グローバルなスケールで、たとえ 実行中のトランザクションがあったとしても、整合 的なバックアップ、整合的なMapReduceの実行、 アトミックなスキーマの更新を、Spannerに可能 とする。
  213. 213. Timestamp  こうした特徴は、たとえトランザクションが分散していたとし ても、Spannerがトランザクションにグローバルに意味の あるコミット・タイムスタンプを割り当てるという事実によっ て可能になった。  このタイムスタンプは、シリアル化された順序を反映して いる。それに加えて、シリアル化された順序は、外的整合 性(あるいは、それと等価だが、線形化可能性)を満たし ている。すなわち、あるトランザクションT1が、別のトラン ザクションT2が始まる前にコミットするなら、T1のコミット・ タイムスタンプは、T2のそれよりも小さい。  Spannerは、グローバルなスケールで、こうした保証を与 えた最初のシステムである。
  214. 214. TrueTime API  こうした性質を可能にした重要なものは、TrueTime API とその実装である。  このAPIは、直接に、時計の不確実さを、あらわに示すも のである。そして、Spannerのタイムスタンプは、実装が 提供する不確実さの範囲にディペンドしている。もし、不確 実さが大きければ、Spannerは、この不確実さを待つ為 に、スピードを落とす。  この実装は、複数の現代的な時計(GPSと原子時計)へ の参照を利用することで、不確実性を小さなもの(一般的 には、10ms以下)にとどめようとする。
  215. 215. 2 Implementation 2.1 Spanserver Software Stack 2.2 Directories and Placement 2.3 Data Model
  216. 216. Implementation  この節では、Spannerの構造とその実装の基礎 にある理論的な根拠を述べる。  その後、複製と局所性を管理するのに利用され、 データ移動の単位である、「ディレクトリー」という 抽象について述べる。  最後に、我々のデータモデルと、なぜSpanner がキー・バリュー・ストアではなくリレーショナル・ データベースのように見えるのか、また、アプリ ケーションは如何にしてデータの局所性をハンド ルすることが出来るのかについて述べる。
  217. 217. UniverseとZone  Spannerの配備は、「ユニバース」と呼ばれる。 Spannerがデータをグローバルに管理している としても、ほんの少数の稼働しているユニバース があるだけだろう。  我々は現在、テスト/プレイグラウンド・ユニバース と、開発/生産・ユニバースと、生産専用・ユニ バースの三つを走らせている。  Spannerは、一群の「ゾーン」で組織されている。 それぞれのゾーンは、大まかにいって、 BigTableのサーバーに相当するものである。
  218. 218. Zone  ゾーンは、管理上の配備の単位である。一群のゾーンは、 また、その上にデータの複製を置くことが出来る、場所群 でもある。  新しいデータセンターがサービスを開始したり、逆に、古 いデータセンターがサービスを停止したりした場合、ゾー ンを稼働中のシステムに追加したり取り除くことが出来る。  ゾーンは、物理的な隔離の単位でもある。データセンター には、一つかそれ以上のゾーンがあるかもしれない。例え ば、異なったアプリのデータが同じデータセンター内の異 なったサーバー群にまたがって分割されなければいけな いような場合である。
  219. 219. ZonemasterとLocationProxy  図1は、Spannerユニバースのサーバーを図示 したものである。  ゾーンは、一つのゾーン・マスターと、百から数千 の間のスパンサーバーを持っている。前者は、ス パンサーバーにデータを割り当てる。後者は、 データをクライアントにサービスする。  ユーザーのデータに割り当てられたスパンサー バーの場所を特定する為に、そのゾーンのロケー ション・プロキシーが利用される。
  220. 220. UniverseMasterとPlacementDriver  ユニバース・マスターとプレスメント・ドライバーは、現在のと ころ、一つしかない。  ユニバース・マスターは、第一義的には、全てのゾーンにつ いてのステイタス情報が表示され、インタラクティブなデバッ グの為に利用される、コンソールである。  プレスメント・ドライバーは、数分の単位のタイムスケールで の、ゾーンをまたいだデータの自動的な移動をハンドルする。 プレスメント・ドライバーは、定期的にスパンサーバーと通信 して、レプリカの更新条件に合致した、あるいは、負荷をバラ ンスさせる為、移動すべきデータを見つける。  スペースの関係で、スパンサーバーについてのみ、詳しく述 べることになろう。
  221. 221. 2.1 Spanserver Software Stack この節では、スパンサーバーの実装にフォー カスして、我々のBigTableをベースにした実 装の上に、どのように、複製と分散トランザク ションが、実現されたかを示す。
  222. 222. Spanserver Software Stack  ソストウェア・スタックは、次の図2に示されている。 スタックの一番下では、スパンサーバーが、100 個から1000個の間のタブレットと呼ばれるデータ 構造のインスタンスに責任を持っている。  タブレットは、BigTableのタブレットという抽象と 同様のもので、その中では、次のようなマッピング のバッグを実装している。 (key:string, timestamp:int64) → string
  223. 223.  Bigtableとは異なって、Spannerは、タイムスタンプを データに割り当てる。ここが、Spannerがキー・バリュー・ ストアよりは、マルチ・バージョン・データベースにずっと似 ている重要なポイントである。  タブレットの状態は、Bツリーに似た一群のファイルと write-aheadログに格納されている。これらは全て Colossusと呼ばれる分散ファイルシステム(Google File Systemの後継である)上にある。  複製をサポートする為に、それぞれのスパンサーバーは、 それぞれのタブレット上に、一つのPaxos状態マシンを実 装している。
  224. 224.  (初期のSpannerの具体化では、タブレットごと に複数のPaxos状態マシンをサポートしていた。 それによって、もっと柔軟な複製の設定が可能と なるのだが、そのデザインの複雑さの為に、我々 は、それを放棄した。)  それぞれの状態マシンは、そのメタデータとログ を対応するタブレットに格納する。  我々のPaxosの実装は、時間ベースのリーダー のリースで、デフォルトの長さが10秒の、長い期 間のリーダーをサポートしている。
  225. 225.  現在のSpannerの実装では、全てのPaxosが二 度ログを書き出している。一つは、タブレットのロ グで、もう一つはPaxosのログである。この選択 は、expendiencyによるもので、最終的には修 正したいと思っている。  我々のPaxosの実装は、WANの遅延があるにも かかわらず、Spannerのスループットを向上させ る為に、パイプライン化されている。しかし、書き 込みは、Paxosによって、順番に実行される。
  226. 226. Paxos  Paxos状態マシンは、マッピングのバッグのレプ リカを整合的に実装するのに利用されている。そ れぞれの複製のキー・バリュー・マッピングの状 態は、対応するタブレットに格納される。  書き出しは、リーダーのPaxosプロトコルから開 始されなければならない。読み出しのアクセスの 状態は、十分更新されたどのレプリカの下にある タブレットからでも直接に取得出来る。一群のレプ リカは、集って、Paxos グループを形成する。
  227. 227.  リーダーである全てのレプリカのスパンサーバー は、コンカレンシーのコントロールを実装する為の ロック・テーブルを実装している。  ロック・テーブルは、ツー・フェーズ・ロッキングの 為の状態を含んでいる。それは、一連のキーを ロック状態にマップする。(ロック・テーブルを効率 的に管理する上で、長い期間、生き続けるリー ダーを持つことは、本質的に重要であることに注 意。)
  228. 228.  BigTableでもSpannerでも、両方とも、我々は。 長いトランザクション(例えば、レポートの生成。こ れ数分単位の時間がかかる)の為のデザインをし てきた。こうした処理は、衝突がある場合には、楽 観的コンカレンシー・コントロールでは、貧弱な性 能しか出ない。  読み込みのトランザクションのような同期を必要と する操作は、ロック・テーブルからロックを取得す る。その他の操作は、ロック・テーブルをバイパス する。
  229. 229.  リーダーである全てのレプリカでは、それぞれの スパンサーバーは、分散トランザクションをサポー トする為にトランザクション・マネージャーも実装し ている。  トランザクション・マネージャーは、参加者のリー ダーを実装する為に利用される。その他のレプリ カは、参加者のスレーブとなる。
  230. 230.  もしトランザクションが、一つのPaxosグループを 含んでいるだけなら(大部分のトランザクションの 場合)、それは、トランザクション・マネージャをバ イパス出来る。というのは、ロック・テーブルと Paxosが一緒になって、トランザクションの保証を 提供するからである。  もしトランザクションが一つ以上のPaxosグルー プを含んでいたら、これらのグループ・リーダーが ツー・フェーズ・コミットの調整役を演ずる。
  231. 231.  参加グループの一つが、調整役に選ばれる。そ のグループの参加者のリーダーは、調整役リー ダーと呼ばれ、グループのスレーブは、調整役ス レーブと呼ばれる。  それぞれのトランザクション・マネージャの状態は。 直下のPaxosグループに格納される。(それ故、 複製される。)
  232. 232. 2.2 Directories and Placement
  233. 233. 2.2 Directories and Placement  キー・バリュー・マッピングのバッグの上で、 Spannerの実装は、「ディレクトリー」と呼ばれる 「バケット化」の抽象をサポートしている。それは、 共通の接頭辞を共有する連続的なキーの集まり である。(ディレクトリーという言葉の選択は、歴史 的な事情によるもので、もっと良い言葉は、「バ ケット」だったかもしれない。)  次のセクション2.3で、この接頭辞の起源を説明 しよう。ディレクトリーのサポートは、キーを注意深 く選ぶことによって、データの局所性をコントロー ルすることを可能にする。
  234. 234.  ディレクトリーは、データの配置の単位である。 ディレクトリー内の全てのデータは、同じ複製設定 を持つ。  データがPaxosグループ間を移動する時、それ は図3が示すように、ディレクトリーからディレクト リーへと移動する。  Spannerは、ディレクトリーを、あるPaxosグルー プから負荷を軽減する為に移動するかもしれない。 よくアクセスされるディレクトリーを同じグループに まとめたり、アクセスする人に近いグループにディ レクトリーを移動したり。
  235. 235.  クライアントの操作が実行中でも、ディレクトリー は移動出来る。50MBのディレクトリーは、数秒で 移動出来ると考えてよい。  Paxosグループが複数のディレクトリーを含みう るという事実は、Spannerのタブレットが BigTableのタブレットとは違っていることを意味し ている。Spannerのタブレットは、単一の連続す るの辞書式順序の行空間の分割ではないのであ る。
  236. 236.  その代わりに、Spannerのタブレットは、複数の 行空間の分割を包み込んだコンテナーなのであ る。しばしば一緒にアクセスされる複数のディレク トリーを、近い場所に置くことが可能であるという ことで、我々は、この決定を行った。  Movedirは、Paxosグループ間でディレクトリー を移動させるバックグラウンドのタスクである。 Movedirはまた、レプリカをPaxosグループに追 加したり削除するのに利用されている。というのも、 SpannerはPaxosの設定を変えるということを、 まだ、サポートしていないからだ。
  237. 237.  Movedirは、大きなかたまりのデータ移動の際に 実行される、読み出し・書き込みのブロックを避け る為に、単一のトランザクションとしては、実装さ れていない。  その代わりに、 movedirは、データ移動が始 まったという事実を登録し、データをバックグラウ ンドで移動する。  名目的なデータの量以外の全てのデータを移動 し終わったら、movedirは、この名目的な量をア トミックに移動する為にトランザクションを利用し、 二つのPaxosグループのメタデータを更新する。
  238. 238.  ディレクトリーは、また、その複製の地理的なプロ パティ(短く、「配置」という)が、アプリによって指 定される最小の単位である。  配置指定の言語は、複製の設定を管理する責任 とは分離されている。  管理者は、二つの次元をコントロールする。レプリ カの数と型、そして、これらのレプリカの地理的な 配置である。管理者は、これらの二つの次元で、 名前でオプションのメニューを作る。(例えば、 North America, replicated 5 ways with 1 witness というような).
  239. 239.  アプリは、それぞれのデータベース、あるいは、 個々のディレクトリーを、これらのオプションの組 み合わせでタグづけて、データがいかに複製され るかをコントロールする。  例えば、あるアプリでは、エンドユーザー各人の データを、次のように、自身のディレクトリーに格 納しているかもしれない。ユーザーAのデータは ヨーロッパに3つのレプリカを持ち、ユーザーBの データは、北米に5つのレプリカを持つ、ということ が可能になる。
  240. 240.  説明を分かりやすくする為に、随分、単純化した のだが、実際には、Spannerはディレクトリーが あまりに大きくなった時には、それを複数のフラグ メントに分割するだろう。  フラグメントは、異なるPaxosグループでサービス を受ける(それ故、異なるサーバーで)かもしれな い。Movedirは、実際には、グループ間でディレ クトリー全体ではなく、フラグメントを移動する。

×