Slide 1

Slide 1 text

Bigtable 2021.06.25@a2ito

Slide 2

Slide 2 text

Publication Bigtable: A Distributed Storage System for Structured Data Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI) 2006

Slide 3

Slide 3 text

Bigtable 概要 ● 分散KVS(NoSQL) ● 高スケーラビリティ ○ ペタバイト級 ● 多くのプロジェクトで利用されている ○ web indexing, Google Earth, Google Finance, etc

Slide 4

Slide 4 text

Apache HBase ● Apache HBase は Bigtable インスパイア ○ GFSの代わりにHDFSを利用

Slide 5

Slide 5 text

Data Model (row:string, column:string, time:int64) -> string ● row とcolumn(+時間)で一つのデータに対応 ○ 一つの行には、column family があり、column family の中に column がある ● 数値やバイナリは、事前にエンコードしておく

Slide 6

Slide 6 text

Data Model イメージ図例 Cloud On Air の資料より抜粋

Slide 7

Slide 7 text

Data Model - example ● Webサイトから取得したHTMLをBigtableに保存する例 ● Row key:WebサイトのURL ● Column family ○ contents:columnなし、value は HTML ○ anchor:column は「このURLに対してリンクを貼っている他の Webサイト」で、valueはリンク部 分の文字列

Slide 8

Slide 8 text

制約や特徴 ● 複数の行にまたがった検索はできない ○ 例)value が特定の条件にマッチしている行を取得 ● カラムは後から動的に追加できる ● 読み込み・書き込み共に Row Key をうまくつかってリクエストをバラけさせること が基本戦略

Slide 9

Slide 9 text

ユースケース ● On Air 資料より

Slide 10

Slide 10 text

Bigtableのアーキテクチャ ● Bigtableのテーブルは複数の Tabletに分割 ● Tablet上のデータは、 memtable/GFSに配置される ○ 2021年時点ではGFSではなく Colossus に配置 ● Chubby で分散ロック(Tablet自 体の構成の一貫性を担保) https://www.school.ctc-g.co.jp/columns/nakai2/nakai205.html

Slide 11

Slide 11 text

API - 書き込み ● www.cnn.com に anchor を追加、不要な anchor を削除 ● Apply でアトミックな処理を実行 // Open the table Table *T = OpenOrDie("/bigtable/web/webtable"); // Write a new anchor and delete an old anchor RowMutation r1(T, "com.cnn.www"); r1.Set("anchor:www.c-span.org", "CNN"); r1.Delete("anchor:www.abc.com"); Operation op; Apply(&op, &r1);

Slide 12

Slide 12 text

API - 読み込み ● 特定行(“com.cnn.www”)の全anchor を取得 ● 条件にマッチするscanも可能 ○ anchor:*.cnn.com ○ 10日以内のもの Scanner scanner(T); ScanStream *stream; stream = scanner.FetchColumnFamily("anchor"); stream->SetReturnAllVersions(); scanner.Lookup("com.cnn.www"); for (; !stream->Done(); stream->Next()) { printf("%s %s %lld %s\n", scanner.RowName(), stream->ColumnName(), stream->MicroTimestamp(), stream->Value()); }

Slide 13

Slide 13 text

● 前提:Row Key でソートされている ● Tablet はツリー構造になって管理さ れる ● クライアントは Chubby からRoot tablet の情報を取得 ● Root tablet⇒METADATA tablets と tablet情報を探し、データを管理して いるTabletを見つけることができる Tablet Location

Slide 14

Slide 14 text

Tabletの管理 ● マスタサーバは Chubby を用いて Tablet を管理 ○ 新規テーブル作成時や障害発生時、 Tabletをサーバに割り当てる ○ Chubby に登録された情報から、 Tablet サーバの存在を把握する ● マスタに障害が発生しても、クライアントはテーブルにアクセスすることができる ● Tablet サーバは、自身が保有する Tablet のロックを Chubby に登録する ○ Tablet サーバがロックを失っている orそもそもレスポンスがない場合は、障害が発生したとみな して、マスタは新しい Tablet サーバに Tablet を割り当てる

Slide 15

Slide 15 text

Tablet Serving ● 書き込み ○ GFS上の「Tabletログ」に変更内容が追記さ れた後、同じ内容がmemtableにも追加され る ● 読み込み ○ SSTable + memtable で確認 ○ SSTable は memtable の断面データで、読 み込み専用ファイル ● ファイル書き込みをTabletログに対する 追記処理に限定 ○ ファイル書き込み処理のオーバーヘッドを最 小化

Slide 16

Slide 16 text

Compaction ● ログ肥大化を防ぐ ● minor compaction ○ memtable を SSTable に書き出してクリアする ● major compaction ○ SSTable をマージ

Slide 17

Slide 17 text

Refinements ● Logically groups ● Compression ● Caching for read performance ● Bloom filters ● Commit-log implementation ● Speeding up tablet recovery ● Exploiting immutability

Slide 18

Slide 18 text

Refinements - Logically groups ● カラムファミリーを作成する際のオプション指定により、複数のカラムファミリーの データを同一のSSTableに保存 ● 同時に参照されることが多いカラムファミリーへのアクセス性能を向上 ○ 例 Webtable の場合、language や checksums などのページメタ情報

Slide 19

Slide 19 text

Refinements - Compression ● SSTableを圧縮するかどうかを選択可能 ● 圧縮する場合、アルゴリズムをユーザーが指定できる ○ SSTableの各ブロック毎(controllable)に適用される ○ 領域は無駄が生じるが、並列に読み込みができる

Slide 20

Slide 20 text

Refinements - Caching for read performance ● Tabletサーバーのキャッシュ戦略 ○ SSTableから読み込んだデータを個別にメモリ上にキャッシュする ⇒頻繁にアクセスされるデータの読み込みを高速化 ○ SSTableを構成するファイルをブロック単位でキャッシュする ⇒シーケンシャルやランダムアクセスされるデータの読み込みを高速化する

Slide 21

Slide 21 text

Refinements - Bloom filters ● 読み込み処理では、全SSTableを読まなければいけない ○ Bloom filter * によってディスクアクセス量を劇的に改善 ■ ビット列とハッシュ関数によって要素が集合に含まれているか判断 ● 特定の row/columns ペアが含まれているかどうかの判定に利用 ○ 「含まれていない行」の判定にも利用 * BLOOM, B. H. Space/time trade-offs in hash coding with allowable errors. CACM 13, 7 (1970), 422–426.

Slide 22

Slide 22 text

Refinements - Commit-log implementation ● コミットログがtablet毎に違うと、GFSへ書き込むファイル数が膨大になる ○ tablet server で一つのコミットログとした ● リカバリが複雑になるが、コミットログを予めソートしておくことでseekを最小化 ○

Slide 23

Slide 23 text

Refinements - Speeding up tablet recovery ● マスタが tablet server からある tablet を移動する際、ソース tablet server は minor compaction を行う ○ compaction されていないログの量が減る ○ その後、minor compaction 中に到着した差分ログを minor compaction する

Slide 24

Slide 24 text

Refinements - Exploiting immutability ● SSTable は immutable であり、memtable だけが mutable ○ concurrency control が極めて効率的 ● 恒久的なデータ削除=不要な SSTable のガベージコレクション ○ METADATAに登録されており、mark-and-sweep 方式でマスタが削除する

Slide 25

Slide 25 text

Performance Evaluation ● N tablet servers ○ two dual-core Opteron 2GHz ○ 1 GB RAM ● GFS cell ○ 1,786 machines ○ two 400GB IDE HDD each

Slide 26

Slide 26 text

Performance Evaluation ● 表:タブレットサーバ毎の秒間オペレーション数 ● グラフ:秒間オペレーション数(表の合計値) ● scan は sequential reads と似ているが、Bigtable API を利用(RPCコール回数 が減る)

Slide 27

Slide 27 text

Real Applications ● クラスタあたりの tablet server 数 ● とあるクラスタでは、incoming 741 MB/s, outgoing 16 GB/s

Slide 28

Slide 28 text

Real Applications ● Google Earth ○ 下段:画像含む前処理データ。既に圧縮済みの画像なので、 compression は無効化 ○ 上段:index 情報で大量のクエリを low latency でさばく必要がある ■ テーブルのサイズは小さいが、数百の tablet server で host している