> [!abstract] 概要 > Bigtable は、先駆的で影響力の大きい非リレーショナルデータベースシステムである。元の Bigtable 論文 [17] は広く引用され、HBase や Cassandra など多くの他システムに着想と影響を与えた。それ以来、Bigtable は成長を続け、Google 内部で最大級のデータベースシステムの一つになった。本論文では、過去 20 年間に Google 内部で Bigtable がたどった道のりを述べる。Bigtable に追加された新機能と改善を提示し、このストレージシステムを大規模に運用し、ユーザーの増え続ける要求に対応するためにあらゆる側面を継続的に改善してきた経験を共有する。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | Twenty Years of Bigtable | | 著者 | [[Fabio Baltieri]] ほか、[[Google]] | | 会議 | SIGMOD Companion 2026（Bengaluru, India） | | 出版日 | 2026-05-31 | | DOI | 10.1145/3788853.3803095 | | ページ数 | 13 | | PDF | `[[.raw/papers/1-3788853.3803095.pdf]]` | ## 概要 本論文は、2006 年の Bigtable 論文以降、[[Bigtable]] が 20 年間にどのように拡張・運用されてきたかを報告する経験論文である。Bigtable は当初の多次元疎ソート済みマップ、タブレット、SSTable/メムテーブル、単一行トランザクションという基本構造を保ちながら、Google 内部および Cloud Bigtable の要求に応じて、グローバルレプリケーション、SQL、CDC、カウンタ/CRDT、マテリアライズドビュー、スケーラビリティ・性能・信頼性・資源効率の改善を積み上げた。 本論文の最大の価値は、新規アルゴリズム単体ではなく「長寿命の大規模データベースシステムを 20 年運用し続けると、どの設計原則が残り、どの周辺機構が追加されるか」を一次資料として示す点にある。 ## 問題設定 Bigtable は 2004 年頃に Google で構築された非リレーショナルデータベースである。2006 年の OSDI 論文時点では、ペタバイト級データを数千台のサーバで扱う分散ストレージとして報告された。本論文時点では、Google 内部のほぼ全プロダクト領域で数千チーム・ユーザーが利用し、10 EB のデータ、ピーク 70 億 QPS、単一テーブル 1.6 千兆行超、単一テーブル 1 EB 超、単一クラスタ 2.5 億 QPS 超を扱う規模に達している。 問題は、当初の単純なアーキテクチャを保ちながら、次の要求増大に応えることである。 - **可用性と地理的分散**: グローバルアクセス、フェイルオーバー、バックアップ用途のためのレプリケーション。 - **分析処理の内蔵**: 外部 MapReduce/Flume/Dataflow だけに頼らず、SQL、CDC、集計型、マテリアライズドビューをデータベース側で支える。 - **スケール拡大**: タブレット数、メタデータ、位置特定、ファイルガベージコレクション、リバランスの管理コスト増大。 - **読み取り性能と資源効率**: LSM 型ストレージの読み取りコスト、キャッシュ、ブルームフィルタ、優先度制御、オートサイジング。 - **長期運用**: 個別ユーザー運用から SRE チームによるサービス運用への移行、監視、設定標準化、バックアップ既定化。 ## 提案手法 ### レプリケーション Bigtable レプリケーションは、カラムファミリを同一クラスタまたはデータセンター間でミラーする機構である。複数のレプリカが書き込みを受け付ける複数プライマリ構成を取れるが、レプリカ間で書き込み受理を協調しないため、コストとレイテンシを抑え、高可用性を得る。 整合性モデルは結果整合性である。各レプリカは、行範囲とソースごとのレプリケーション進行をレプリケーションウォーターマークとして保持する。同一ソース・同一行の変異は論理時計に基づくレプリケーション時点で単調に並び、同一行の競合は最終書き込み勝ちで解決される。一方で、行をまたぐ整合性やレプリカ間の ACID は保証しない。 新規レプリカ追加では、既存 SSTable を一括コピーしつつ新しい変異も処理する BEAR（Bigtable Efficient Add Replica）を使う。コピーされた SSTable には人工的に低いシーケンサを割り当てるため、同じ行に対する飛行中の新しい変異が後から到着しても、より高いシーケンサで勝つ。 レプリケーションはプル型で実装される。宛先レプリカがソースレプリカからリモート変異を引き、各タブレットが自分のレプリケーション位置を保持する。レプリケーションログは隠しローカリティグループに保存され、全レプリカが取り込んだ後に discard compaction で削除される。非冪等な集計型にも対応するため、プルプロトコルは exactly once delivery を保証する。 ### データベース内処理 Bigtable は従来、大規模処理を MapReduce、Flume、Beam、Hadoop、Spark など外部エンジンへオフロードしていた。本論文では、処理をデータベースエンジンへ押し込む方向の進化が示される。 - **SQL**: GoogleSQL を拡張し、コレクション型、時間フィルタ、ピボット、unnest、Protobuf ディスクリプタ、行キーのスキーマを扱う。Bigtable の柔軟なデータモデルを保ちながら、ネスト構造や複合行キーを高水準に問い合わせる。 - **CDC**: タブレット境界でシャードされた変更ストリームを提供し、行・レプリカ・論理時間の 3 次元で継続位置を追跡する。Dataflow 向けアダプタは制御プレーンとデータプレーンを分け、各変更の少なくとも 1 回実行を保証する。 - **カウンタ/CRDT**: 非同期レプリケーション下でインクリメントと削除を両立するため、LSM ツリー各層に subtotal と未解決操作を持つ changelog を保存する。コンパクション時に changelog をマージ・トリミングし、削除前にシーケンスされた操作を落とす。 - **マテリアライズドビュー**: GoogleSQL クエリで変換を定義し、更新が入るたびにタブレットサーバ上のコプロセッサで MapReduce 型パイプラインを動かす。隠しシャッフルテーブル、マッパ、リデューサ、ファイナライザで出力テーブルを継続更新する。 ### スケーラビリティ改善 タブレット数が増えると、タブレットサーバの管理オーバーヘッド、クライアントの位置キャッシュ、メタデータ負荷、マスタ、リバランサが律速になる。Bigtable は、冷たいタブレットを大きく、熱いタブレットを小さく保つ方針を取り、サイズだけでなく分割・リバランス速度を高めた。 垂直スケーリングでは、大型サーバへの移行に合わせてコミットログをシャーディングし、単一ファイルスループットの限界を避ける。コンパクションでは、ファイル構築をタブレットサーバ外のジョブに外部化し、ユーザーリクエスト処理と高価なファイル構築を分離する。マスタでは細粒度ロックとスキーマ更新の並列化を導入する。ファイルガベージコレクションは、マスタ単独の直列処理からタブレットサーバ協調の並列処理へ移した。 タブレット位置特定では、旧位置を知るタブレットサーバが location hint を返し、さらに location cache proxy へオフロードする。リバランサは CPU、RAM、RPC キュー長などから過負荷サーバを検出し、負荷を段階的に移す。熱いタブレットを動かすとクライアントの位置検索が急増するため、時には熱いタブレットを残し、より冷たい候補を退避させる。 ### 性能・信頼性・資源効率 性能面では、SSTable ブロックキャッシュに加えて行粒度の行キャッシュを導入し、ポイント読み取りの CPU 使用量を最大 25% 削減する。ブルームフィルタは全体を DRAM に置く方式から、キー範囲ごとのシャード化と既存ブロックキャッシュ機構への統合へ移った。カラムファミリのみでフィルタするワークロードでも使えるハイブリッドブルームフィルタにより、利用率は 4 倍になった。リクエスト優先度は、HTAP ワークロードでトランザクション系と分析系を分離する。 信頼性面では、スナップショットとバックアップ、エンドツーエンドチェックサム、継続的検査が中心である。SSTable は構築後・導入前に読み戻し、復号・伸長・各エントリ解析・チェックサム検証を行う。この高価な検査により、SSTable 不整合は数年観測されていないと報告する。 資源効率は、ヘッドルーム削減、使用量削減、資源階層化の 3 テーマで整理される。オートサイジングはサブ分単位で CPU/RAM・タブレット可用性を監視し、スラックサブパーティションからサーバを出し入れする。Google 全体のオートスケーリングと組み合わせ、速い反応と長期の資源効率を両立する。キャッシュサイズは TCO モデルで動的に調整する。バッチ処理向けには、SSTable を直接読む offline access、Cloud Bigtable Data Boost、SSTable を直接構築する bulk import により、低レイテンシ提供資源を避ける。 ### 運用モデル Bigtable は当初、ユーザーまたはユーザーグループが運用する想定だった。しかし、チームごとの運用は知識の断片化とその場しのぎの解決を招いたため、2006 年半ば以降、Bigtable SRE チームが所有する全社サービスとして運用されるようになった。 監視では、メタデータとユーザーパーティションの可用性・レイテンシを複数のプローバで測る。メタデータプローバはメタデータ行を列挙し、各行を定期的に読み取る。ブラックボックスレイテンシプローバは、各パーティションの専用テーブルに固定ワークロードを発行し、読み書きレイテンシ SLI を構築する。 設定面では、提供クラスタを serve cluster と mixed cluster に分け、メタデータ専用パーティション、ユーザー別パーティション、サブパーティションで分離を進めた。タブレットサーバの RAM/CPU 形状は任意指定から固定形状へ標準化され、オンラインリシェイピングも提供された。各テーブルには既定で日次バックアップを付与し、24 時間保持する。 ## 新規性 - **20 年運用経験の一次資料**: 非リレーショナルデータベースが 10 EB・70 億 QPS 規模まで進化した過程を、設計変更と運用モデルの両面から報告する。 - **単純な中核と周辺機構の分離**: 多次元マップ・タブレット・LSM 型永続化・単一行 ACID は維持し、レプリケーション、SQL、CDC、CRDT、ビュー、資源管理を周辺機構として追加する。 - **データベース内処理への移行**: 外部データ処理基盤で補っていた分析・派生データ生成を、Bigtable 自身の SQL・CDC・マテリアライズドビューへ取り込む。 - **運用のサービス化**: 個別チーム運用から専門 SRE チーム運用へ移行し、クラスタ形状、バックアップ、プローバ、パーティション分離を標準化した経験を示す。 ## 実験設定 本論文はベンチマーク論文ではなく経験論文である。定量情報は主に本番規模・機能効果・運用観察として提示される。 - 対象: Google 内部の Bigtable と Cloud Bigtable の同一バックエンド。 - 規模: 10 EB データ、ピーク 70 億 QPS、単一テーブル 1.6 千兆行超、単一テーブル 1 EB 超、単一クラスタ 2.5 億 QPS 超。 - レプリケーション: 最大ユーザーは 200 超のレプリカを持つ。 - 監視: メタデータプローバ、ブラックボックスレイテンシプローバ、SLI/SLO ベースのページング。 - 運用: Bigtable SRE チームによるサービス運用、serve/mixed クラスタ、メタデータパーティション、サブパーティション、固定サーバ形状。 ## 実験結果 - 行キャッシュによりポイント読み取り操作の CPU 使用量を最大 25% 削減した。 - ハイブリッドブルームフィルタによりブルームフィルタ利用率は 4 倍になった。ディスクフットプリント増加はデータ量に比べてごく小さい。 - 1 回のファイルガベージコレクションパスは、クラスタ規模に応じて数分から数十分で完了する。 - レプリケーション遅延は実運用で大半のデータが 1 分未満である。ただし既定では最優先度が低く、ユーザーは要求に応じて優先度とスロットリングを調整する。 - SSTable の導入前検証により、SSTable 不整合は数年観測されていない。 - Cloud Bigtable のオートスケーリングは CPU とストレージ利用率に基づきノード数を調整し、ストレージ上限による書き込み拒否を避ける。 ## 考察 Bigtable の 20 年史は、分散データベースの設計で「中核を単純に保つ」ことと「運用要求に応じて周辺機構を追加する」ことが両立しうることを示す。単一行トランザクション、結果整合性、タブレット分割という制約は残るが、それらを前提にしたスキーマ設計、レプリケーション、SQL、CDC、マテリアライズドビューが用途の幅を広げている。 一方で、機能追加はシステム内に複雑性を蓄積する。CRDT の changelog、マテリアライズドビューの内部 MapReduce、CDC の三次元継続トークン、レプリケーションウォーターマークは、いずれも Bigtable の単純なデータモデルの上に整合性と操作性を足すための補助構造である。運用面でも、専門 SRE チーム、標準化されたサーバ形状、パーティション分離、プローバ、バックアップ既定化が不可欠になっている。 非リレーショナルデータベースの議論に対して、本論文は「SQL や ACID がないから劣る」という単純な対立ではなく、規模・性能・資源効率を得る代わりに、アプリケーションスキーマ、単一行境界、運用標準化で制約を管理するという立場を示す。Cloud Bigtable と Cassandra が高水準クエリ言語を追加した事実は、NoSQL 系システムも時間とともにユーザー操作性を取り込むことを示している。 ## 強み / 弱点・課題 **強み** - 20 年の本番運用を通じ、当初のアーキテクチャが 10 EB・70 億 QPS 規模まで持続したことを示す。 - レプリケーション、SQL、CDC、CRDT、マテリアライズドビュー、オートサイジングなど、機能追加の動機と実装上の要点が広く整理されている。 - 性能だけでなく、信頼性、資源効率、運用モデル、設定標準化まで含む経験論文である。 - SSTable 導入前検証、メタデータプローバ、ブラックボックスプローバなど、運用品質を支える実務的機構が具体的である。 **弱点・課題** - 紙幅制約のため、各機構の実装詳細や定量評価は深くない。多くの改善は概要と代表数値にとどまる。 - Google 内部の固有インフラストラクチャ（Colossus、Chubby、GoogleSQL、Dataflow、全社オートスケーリング）に依存するため、一般環境への移植可能性は直接示されない。 - 結果整合性・単一行 ACID の制約は残り、行をまたぐ強整合性が必要な用途はスキーマ設計や別システムで回避する必要がある。 - レプリケーションやマテリアライズドビューなどの新機能は、低コスト・高可用性と引き換えに、ウォーターマークやシーケンサなどのメタデータ管理を複雑化する。