Bigtable

Transcript

1. Bigtable 2021.06.25@a2ito
2. 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
3. Bigtable 概要 • 分散KVS（NoSQL） • 高スケーラビリティ ◦ ペタバイト級 • 多くのプロジェクトで利用されている ◦ web indexing, Google Earth, Google Finance, etc
4. Apache HBase • Apache HBase は Bigtable インスパイア ◦ GFSの代わりにHDFSを利用
5. Data Model (row:string, column:string, time:int64) -> string • row とcolumn（＋時間）で一つのデータに対応 ◦ 一つの行には、column family があり、column family の中に column がある • 数値やバイナリは、事前にエンコードしておく
6. Data Model イメージ図例 Cloud On Air の資料より抜粋
7. Data Model - example • Webサイトから取得したHTMLをBigtableに保存する例 • Row key：WebサイトのURL • Column family ◦ contents：columnなし、value は HTML ◦ anchor：column は「このURLに対してリンクを貼っている他の Webサイト」で、valueはリンク部 分の文字列
8. 制約や特徴 • 複数の行にまたがった検索はできない ◦ 例）value が特定の条件にマッチしている行を取得 • カラムは後から動的に追加できる • 読み込み・書き込み共に Row Key をうまくつかってリクエストをバラけさせること が基本戦略
9. ユースケース • On Air 資料より
10. Bigtableのアーキテクチャ • Bigtableのテーブルは複数の Tabletに分割 • Tablet上のデータは、 memtable/GFSに配置される ◦ 2021年時点ではGFSではなく Colossus に配置 • Chubby で分散ロック（Tablet自 体の構成の一貫性を担保） https://www.school.ctc-g.co.jp/columns/nakai2/nakai205.html
11. 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);
12. 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()); }
13. • 前提：Row Key でソートされている • Tablet はツリー構造になって管理さ れる • クライアントは Chubby からRoot tablet の情報を取得 • Root tablet⇒METADATA tablets と tablet情報を探し、データを管理して いるTabletを見つけることができる Tablet Location
14. Tabletの管理 • マスタサーバは Chubby を用いて Tablet を管理 ◦ 新規テーブル作成時や障害発生時、 Tabletをサーバに割り当てる ◦ Chubby に登録された情報から、 Tablet サーバの存在を把握する • マスタに障害が発生しても、クライアントはテーブルにアクセスすることができる • Tablet サーバは、自身が保有する Tablet のロックを Chubby に登録する ◦ Tablet サーバがロックを失っている orそもそもレスポンスがない場合は、障害が発生したとみな して、マスタは新しい Tablet サーバに Tablet を割り当てる
15. Tablet Serving • 書き込み ◦ GFS上の「Tabletログ」に変更内容が追記さ れた後、同じ内容がmemtableにも追加され る • 読み込み ◦ SSTable + memtable で確認 ◦ SSTable は memtable の断面データで、読 み込み専用ファイル • ファイル書き込みをTabletログに対する 追記処理に限定 ◦ ファイル書き込み処理のオーバーヘッドを最 小化
16. Compaction • ログ肥大化を防ぐ • minor compaction ◦ memtable を SSTable に書き出してクリアする • major compaction ◦ SSTable をマージ
17. Refinements • Logically groups • Compression • Caching for read performance • Bloom filters • Commit-log implementation • Speeding up tablet recovery • Exploiting immutability
18. Refinements - Logically groups • カラムファミリーを作成する際のオプション指定により、複数のカラムファミリーの データを同一のSSTableに保存 • 同時に参照されることが多いカラムファミリーへのアクセス性能を向上 ◦ 例　Webtable の場合、language や checksums などのページメタ情報
19. Refinements - Compression • SSTableを圧縮するかどうかを選択可能 • 圧縮する場合、アルゴリズムをユーザーが指定できる ◦ SSTableの各ブロック毎(controllable)に適用される ◦ 領域は無駄が生じるが、並列に読み込みができる
20. Refinements - Caching for read performance • Tabletサーバーのキャッシュ戦略 ◦ SSTableから読み込んだデータを個別にメモリ上にキャッシュする ⇒頻繁にアクセスされるデータの読み込みを高速化 ◦ SSTableを構成するファイルをブロック単位でキャッシュする ⇒シーケンシャルやランダムアクセスされるデータの読み込みを高速化する
21. 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.
22. Refinements - Commit-log implementation • コミットログがtablet毎に違うと、GFSへ書き込むファイル数が膨大になる ◦ tablet server で一つのコミットログとした • リカバリが複雑になるが、コミットログを予めソートしておくことでseekを最小化 ◦ <table, row name, log sequence number>
23. Refinements - Speeding up tablet recovery • マスタが tablet server からある tablet を移動する際、ソース tablet server は minor compaction を行う ◦ compaction されていないログの量が減る ◦ その後、minor compaction 中に到着した差分ログを minor compaction する
24. Refinements - Exploiting immutability • SSTable は immutable であり、memtable だけが mutable ◦ concurrency control が極めて効率的 • 恒久的なデータ削除＝不要な SSTable のガベージコレクション ◦ METADATAに登録されており、mark-and-sweep 方式でマスタが削除する
25. Performance Evaluation • N tablet servers ◦ two dual-core Opteron 2GHz ◦ 1 GB RAM • GFS cell ◦ 1,786 machines ◦ two 400GB IDE HDD each
26. Performance Evaluation • 表：タブレットサーバ毎の秒間オペレーション数 • グラフ：秒間オペレーション数（表の合計値） • scan は sequential reads と似ているが、Bigtable API を利用（RPCコール回数 が減る）
27. Real Applications • クラスタあたりの tablet server 数 • とあるクラスタでは、incoming 741 MB/s, outgoing 16 GB/s
28. Real Applications • Google Earth ◦ 下段：画像含む前処理データ。既に圧縮済みの画像なので、 compression は無効化 ◦ 上段：index 情報で大量のクエリを low latency でさばく必要がある ▪ テーブルのサイズは小さいが、数百の tablet server で host している