Googleは製品ごとにデータベースを用意する代わりに、60以上の製品を1つのBigtable上で運用していた

2004年までに、Googleの各製品は同じ問題に直面していた。ウェブクロールから衛星画像、金融フィードに至るまで、大量の構造化データを保存する必要があった。製品ごとに専用のストレージシステムを構築するのは高コストであり、既製のデータベースでは必要な規模に到達できなかったため、同社は1つの共有システムを設計した。

Bigtableはシンプルなモデルを提示する。行、列、タイムスタンプをキーとする疎でソート済みのマップであり、値は解釈されないバイト列として保存される。アプリケーションは自らのレイアウトを決め、データの局所性を制御し、さらにはデータをメモリから提供するかディスクから提供するかまで選択できる一方、プラットフォーム側が数千台のコモディティサーバ上でのパーティショニング、レプリケーション、フェイルオーバーを処理する。

2006年の論文の時点で、Google Analytics、Google Finance、Personalized Search、Google Earthを含む60以上のGoogle製品がBigtableを使用していた。クラスタは数台から数千台のサーバに及び、それぞれ最大数百テラバイトを保存していた。

1つの共有ストア。各製品が独自のスキーマを調整する

1つのプラットフォームがエンジニアリングと運用のコストを多数の製品に分散させる

アプリケーションがレイアウトを制御するため、用途が異なってもモデルはシンプルなまま保たれる

コモディティサーバと自動パーティショニングによりペタバイト規模まで拡張できる

共有システムであれば、1つのチームが全員のために堅牢化できる

製品をスケールさせる前に、共有の基盤を一度構築すること。多くのチームが調整できるシステムは、誰も一緒に改善できない多数の特注システムに勝る。

BigtableはGoogle自身のサービスの基盤であり続け、後にGoogle Cloudの提供製品「NoSQLのパイオニア」となった。レイテンシに敏感なパーソナライゼーション、クリックストリーム、IoTワークロード向けのマネージドなキーバリューおよびワイドカラムストアであり、HBaseやCassandraと互換性のあるAPIを備える。そのアイデアはHBaseなどのオープンソースのクローンにも影響を与えた。