コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第226回　Bigtableの20年の進化を振り返る（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes

第226回　Bigtableの20年の進化を振り返る（パート1） (中井悦司) 2026年7月21日公開

はじめに

　今回からは、2026年に公開された論文「Twenty years of Bigtable」に基づいて、ちょうど20年前の2006年に論文で公開されたBigtableの機能やアーキテクチャーが、その後の20年間にどのように進化してきたかを紹介します。今回は、Bigtableの基本構成を振り返った上で、レプリケーション機能の実装を紹介します。

Bigtableの基本構成

　Bigtableは、Googleのデータベース技術の中で最も歴史が長く、2006年に公開された論文「Bigtable: A Distributed Storage System for Structured Data」では、検索エンジンのバックエンドデータベースとして開発されたことが説明されています。この2006年の論文は、「[第5回大規模構造化データに最適化された分散キーバリューストアBigtable（パート1）%%https://www.school.ctc-g.co.jp/columns/nakai2/nakai205.html]」からの一連の記事で紹介しているので、そちらも参考にしてください。ここではまず、Bigtableの基本的な仕組みを簡単にまとめておきます。
　Bigtableは、分散型のキーバリューストアで、行単位でデータを読み書きします。1つの行の中には、複数の「カラムファミリー」があり、それぞれのカラムファミリーの中には、複数の「カラム」があります。したがって、行を特定する「Row Key」に加えて、カラムファミリー名、および、カラム名を指定すると、1つのデータにたどり着きます。Row Key、カラムファミリー名、カラム名は文字列で指定して、保存するデータそのものはバイナリー形式で与えます。また、それぞれのデータにはタイムスタンプが付随しており、タイムスタンプの異なる複数バージョンのデータが保存できます（図1）。

fig01

図1 Bigtableのデータ構造（2006年の論文より抜粋）

　Bigtableは、複数の行にまたがったトランザクション機能を持たないので、行単位の分散処理が容易に実現できます。テーブル全体をRow Keyでソートされた一定の区画からなる複数の「tablet」に分割して、tabletごとにデータの読み書きを行うtabletサーバーを割り当てます。tabletサーバーが読み書きするデータの実体は、分散ファイルシステム（Colossus）に「SSTable」と呼ばれるデータ形式で保存されます。tabletサーバーのローカルディスクにデータが保存されるわけではないので、tabletの分割方法やそれぞれのtabletを担当するサーバーは自由に変更可能で、それぞれのtabletサーバーの負荷に応じて、動的に割り当てが変更されます。
　なお、2006年の論文では、tabletサーバーの割り当てなどのメタデータは、分散ロックサービス（Chubby）に保存されると説明されていましたが、現在の実装では、このようなメタデータもBigtableに保存されるように変更されています。ただし、最初に起動する必要がある、メタデータ保存用のBigtableは、従来通り、Chubbyに保存されたメタデータを用いて起動する仕組みになっています。

Bigtableの機能進化とレプリケーション機能の追加

　Bigtableは、現在に至るまでGoogleのさまざまなサービスのバックエンドとして利用されています。冒頭の論文によると、現在、Google全体で10エクサバイトのデータを保存しており、ピーク時のアクセスは、単一のクラスターでは2億5000万QPS以上、Google全体では70億QPSに達するということです。また、2015年にGoogle Cloudのマネージドサービス「Cloud Bigtable」として、Google社外のユーザーにも提供が開始されて、社外のユーザーからの機能追加要望にも対応してきました。冒頭の論文では、そのような機能追加の例として、レプリケーション機能の実装が挙げられています。ここでは、レプリケーションの仕組みを簡単に紹介します。
　まず、Bigtableのレプリケーションは、マルチマスター構成が可能で、複数のレプリカに対して、同時にデータの読み書きができます。ただし、書き込まれたデータは即座にレプリケーションされるわけではなく、いわゆる結果整合性（Eventual Consistency）による一貫性の担保が行われます。同じ行に同時に書き込みが行われた場合は、最終的にタイムスタンプの大きい方のデータで上書きされる形になります。レプリケーションの処理は、各レプリカのtabletサーバーが、他のレプリカから新しいデータを取得する「Pull方式」で行われます。この際、tabletごとにどの時刻のデータまでコピーされたかを示す「watermark」が記録されており、書き込み順序に従ってレプリケーションが実行されることが保証されます。図2のように、一般にはレプリカごとにtabletの分割が異なりますが、それぞれのレプリカにおけるtabletごとにwatermarkが記録されます。

fig02

図2 レプリカごとにtabletの分割が異なる様子（論文より抜粋）

　また、レプリケーションに関連する機能として、「カウンター」あるいは「conflict-free replicated data types（CRDT）」の実装についても触れられています。たとえば、値を±1で変化させるカウンター値をBigtableの行に保存する場合を考えます。レプリカ1とレプリカ2に「x=3」が保存されている状態で、レプリカ1とレプリカ2のそれぞれで「+1」を実行した場合、最終的に「x=5」になることが期待されます。しかしながら、レプリカ1の実行結果（x=4）がレプリカ2に伝わる前にレプリカ2で「+1」が実行されると最終結果は「x=4」になってしまいます。この問題を避けるには、「+1」した結果を伝えるのではなく、「1を足す」あるいは「1を引く」というオペレーションそのものを伝播する特別な行を定義する方法があります。この場合、「1を足す」および「1を引く」というそれぞれのオペレーションの実行回数が同一であれば、伝播するタイミングによらず、最終的には正しい結果がすべてのレプリカで実現されます。
　ただしこれは、「±1」のように、最終結果が実行順序に依存しないオペレーションに限定されます。たとえば、「値を削除する（0にする）」というオペレーション（delete）が含まれる場合、図3のように、伝搬のタイミングによってレプリカ間で矛盾する結果が記録されます。Bigtableはこの問題を克服し、delete操作も正しく扱える設計になっています。

fig03

図3 実行順序に依存するオペレーションが含まれる場合の例（論文より抜粋）

　図4のように、各レプリカでこれまでに実行されたオペレーションの情報を保持しておき、実行順序に依存するオペレーションを正しく反映する仕組みが実装されており、これにより、レプリカ間で整合性を持ったデータ変更が可能なconflict-free replicated data types（CRDT）を実現しています。

fig04