Percolator 2021/11/12@a2ito

Publication Large-scale Incremental Processing Using Distributed Transactions and Notifications Daniel Peng and Frank Dabek Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation, USENIX (2010) 被引用数: 616

参考 ● Bigtable(2006) ○ 被引用数: 7,472 ● Chubby(2006) ○ 被引用数: 1,492 ● Megastore(2011) ○ 被引用数: 981 ● Dynamo(2007) ○ 被引用数: 5,873 ● Bitcoin(2008) ○ 被引用数: 17,326

Overview ● Googleのインデックス作成システムは、数十ペタバイトのデータを保存し、数千 台のマシンで1日あたり数十億の更新を処理 ● ドキュメントのクロール時にWebのインデックスを更新するには、既存のドキュメ ントの大規模なリポジトリを継続的に変換する必要があ ○ MapReduceやその他のバッチ処理システムは、小さな更新を個別に処理できない ● 大規模なデータセットの更新を段階的に処理するシステムであるPercolatorを 構築 ○ ドキュメントの平均経過時間を 50％削減しつつ1日あたり同じ数のドキュメントを処理

Introduction

What is Percolator ● コーヒーを煎れるためのレガシーな器具 ● 水を沸騰させ、水蒸気になったお湯を循環させ ることでコーヒーを煎れる

Caffeine ● Percolator-based indexing system https://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html

Introduction ● 検索クエリに回答するため、Webのインデックスを作成する

Introduction ● 元々はインデックス作成タスクに MapReduce が使われていた ● インデックス更新において、新しいページだけに MapReduce を実行するのは 不十分 ○ 既存ページと相互にリンクがあるため ○ リポジトリ全体への処理のため、サイズに比例して遅くなる

参考 MapReduce https://www.guru99.com/introduction-to-mapreduce.html

Introduction ● Percolator は Incremental processing（逐次処理）専用に構築されている ○ 多くのデータ処理タスクで既存のソリューションに代替を意図していない ● 小さな更新に分解できない計算（ファイルの並べ替えなど）は、MapReduce の 方がよい ● 一貫性が必要なければ Bigtable で十分 ● MapReduce や Bigtable に適さない小さな計算は、従来のDBMSでOK

Introduction ● Percolator を利用するアプリケーションは、ライブWeb検索インデックスに含め るためのWebページを準備するもの ● インデックスシステムを Incremental processing に変換することで、Webクロー ル時に個々のドキュメントを処理できる ○ ドキュメントの平均処理待ち時間が 100分の1に短縮され、検索結果に表示されるドキュメントの 平均経過時間は50％近く減少

Design

Design ● a Percolator worker ● a Bigtable tablet server ● a GFS chunkserver ● timestamp oracle ● Chubby lock service https://blog.yugabyte.com/implementing-distributed-transactions-the-google-way-percolator-vs-spanner/

Design ● Percolator への要求 ○ 大規模に実行される ○ 非常に低いレイテンシーの要求がない ● ロックのクリーンアップに lazy なアプローチを選択 ○ 実装が簡単 ○ トランザクションのコミットが数十秒遅くなるかもしれない ○ OLTPを実行しているDBMSでは許容できないが、インデックスを構築するバッチシステムでは 許容できる ● グローバルデッドロック検出をしない ○ 競合するトランザクションの待ち時間が長くなるが、数千台にスケール可能

参考 Snapshot Isolation ● トランザクションは一貫性のあるデータベースのスナップショット(トランザクション 開始時に存在していた最後にコミットされた値)を読む。 ● トランザクションの更新がスナップショット以降に他のトランザクションがコミットし た更新と競合しない場合に限りトランザクションが成功する。

Transactions ● t2 は t1 の書き込みを参照することはない ● t3 は t1/t2 両方の書き込みを参照する ● t1 と t2 が同じセルに書き込もうとした場合、どちらかが abort する

Percolator column ● Bigtable 上の Percolator column ○ c:lock ■ An uncommitted transaction is writing this cell; contains the location of primary lock ○ c:write ■ Commited data present; stores the Bigtable timestamp of the data ○ c:data ■ Stores the data itself ○ c:notify ■ Hint: observers may need to run ○ c:ack_O ■ Observer “O” has run; stores start timestamp of successful last run

Percolator transaction 1/5 ● Joe のアカウントに $2、Bob のアカウントに $10 ● Bob から Joe に $7 送金する

Percolator transaction 2/5 ● 送金トランザクションを実行 ○ lockカラムを更新 ○ timestamp 7

Percolator transaction 3/5 ● Joe のアカウント側への更新処理 ○ Joe側でも lock する

Percolator transaction 4/5 ● コミット 1/2 ○ write レコードを timestamp 8 で更新

Percolator transaction 5/5 ● コミット 2/2 ○ Joe の write レコードを timestamp 8 で更新

liveness ● 通常の動きではロックはきちんと clean up されるが、ダウンしたワーカによって ロックが保持され続ける場合がある ● シンプルな liveness の仕組みを使用 ○ ワーカはトークンを Chubby に書き込む（プロセスが終わったらトークンは削除） ○ 他のワーカは、当該ワーカが生きていることを知る ○ ロックは wall time があり、期限が切れたら clean up される

Timestamps ● RPCオーバヘッドの削減のため、pending RPCを一つ保持し、バッチ処理を行う ● タイムスタンプの範囲を定期的に割り当てる ● Get() は全コミット済み書き込み返却を保証 ○ Tw < Tr であるすべての W を R が参照

参考 Practice in TiKV ● We use batching and preallocating techniques to increase the timestamp oracle’s throughput, and also we use a Raft group to tolerate node failure, but there are still some disadvantages to allocating timestamps from a single node. ● One disadvantage is that the timestamp oracle can’t be scaled to multiple nodes. ● There are some potential solutions for this final case, such as Google Spanner’s TrueTime mechanism and HLCs (Hybrid Logical Clocks). https://tikv.org/deep-dive/distributed-transaction/timestamp-oracle/ より抜粋

Notifications ● トランザクションをトリガ経由で実行する方法も必要 ○ ユーザはトリガによって実行されるタスクを登録しておく ○ Percolator は notify 列が書き込まれたら次のタスクを実行する ● 一連のトランザクションではない ● オブザーバはランダム分散スキャンを実行 ○ notify列保存用に別のBigtableローカリティグループを利用 ○ Chubby を利用して重複しないようにしている

Evaluation

Document clustering delay ● crawl rate（時間あたりのリポジトリ更新割 合）における MapReduce と Percolator の 比較 ○ 240台のマシン ● 1000倍程度の差がある ● テストクラスタでは、40%近辺で性能限界を 迎えた

The overhead of Percolator operations ● Bigtable と Percolator の r/w 回数を比較 ○ PercolatorによるACIDトランザクションのオーバヘッドがどのくらいなのか？ ● Percolator introduces overhead relative to Bigtable, a factor of four overhead on writes due to 4 round trips: ○ Percolator -> Timestamp Server -> Percolator -> Tentative Write -> Percolator -> Timestamp Server -> Percolator -> Commit -> Percolator

Transaction rate ● TPC-E改良版* を使用して測定 ○ TPC-E: RDBMSベンチマーク仕様 ○ インタフェースや定期実行処理の仕様を Percolator用にカスタマイズ ● CPUコア数に対するスループット ○ ほぼリニアにスケール *TPC benchmark E standard specification version 1.9.0.Tech. rep., Transaction Processing Performance Council, September 2009

Recovery of tps ● 17:19頃 tablet サーバを kill した際の パフォーマンス(tps)影響 ● 障害後、他の tablet が即時に立ち上 がりパフォーマンスは元のレベルまで 戻っている

Conclusion

まとめ ● Percolatorを開発し、2010年4月よりWeb検索のインデックス生成として実際に 稼働している ● 目標は、リソース使用量を許容できる範囲で増やして、単一のドキュメントのイン デックス作成の待ち時間を短縮することでした。

Thank you!