これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に続いて、2026年に公開された論文「Twenty years of Bigtable」に基づいて、2006に論文で公開されたBigtableの機能やアーキテクチャーが、その後の20年間にどのように進化してきたかを紹介します。今回は、前回説明したレプリケーション以外の機能追加をまとめて紹介します。
ユーザー視点での機能追加としては、GoogleSQLへの対応が挙げられます。現在のBigtableは、従来のクライアントSDKに加えて、GoogleSQLを用いた検索処理に対応しています。Bigtableに保存するデータはカラムファミリーとカラムで構造化されており、1つのカラムファミリーに大量のカラムを用意するなど、複雑なデータを柔軟に保存できます。GoogleSQLは、Google独自のSQL拡張ですが、マップ型やセット型などの「コレクション型」が用意されており、JSONやプロトコルバッファなど、Bigtableに保存された複雑なデータ構造から、必要なデータを効率的に取り出すことができます。
また、前回の記事で触れたように、Bigtableにはタイプスタンプでバージョニングされたデータが保存されます。これに応じて、「2026年5月1日時点のデータ取得（point-in-time query）」のような特定時点のクエリや、「このセルに過去どんな値が書き込まれてきたか」という変更履歴に対するクエリもGoogleSQLで記述できます。その他には、セル内のコレクションや時系列データを独立した行に展開する「アンネスト」や縦に並んだ履歴データを横方向の列に組み替える「ピボット」などもサポートされています。
GoogleSQLによるクエリに対応する以前は、Bigtableのデータからの分析・集計を行う際は、MapReduceやApace Beamなどのバッチ／ストリーム処理エンジンを併用する必要がありました。GoogleSQLを利用すれば、外部の処理エンジンに依存せずに、使い慣れたSQLでBigtable上のデータの分析・集計ができるようになります。
また、GoogleSQLを利用して、マテリアライズド・ビューを定義することもできます。これにより、最新のデータに対する集計結果をリアルタイムに確認できます。マテリアライズド・ビューを生成する際は、図1のように、中間テーブルを利用したmap-reduce処理のパイプラインが実行されますが、この機能はtabletサーバー自身に組み込まれており、外部の処理エンジンを利用する必要はありません。
図1 マテリアライズド・ビューを生成する流れ（論文より抜粋）
Bigtableは検索エンジンのバックエンドとして求められる高いスケーラビリティを意識したアーキテクチャーを持ちますが、Google社内での利用が広がり、データ規模がさらに大きくなる中、アーキテクチャーの細部にさまざまな改良が加えられてきました。その一つが、負荷の高いコンパクションの処理をtabletサーバーから引き離す「外部コンパクション」の導入です。第6回の記事にあるように、Bigtableのデータは、SSTableと呼ばれる構造のファイルに保存されますが、メモリ上のデータをSStableに書き出したり（マイナーコンパクション）、増えすぎたSSTableをマージする処理（マージコンパクション）や、すべてのデータを完全に統合するメジャーコンパクションなどの処理が不定期に発生します。この中でも、特に負荷の高いマージコンパクションとメジャーコンパクションの処理を外部の専用ジョブへと分離しました。これにより、コンパクションの負荷による突発的な処理の遅延が解消されました。
また、データの信頼性の面では、クライアントからストレージ（Colossus）へのデータ転送、そして、ストレージからクラアントへのデータ転送の全体にまたがる、エンドツーエンドでのチェックサムの検証が実装されています。さらには、コンパクションを実行する際にも、SSTableを読み戻して、すべてのエントリーの整合性を再検証する仕組みが導入されています。このような厳格なチェック機構により、ここ数年はSSTableの不整合が実質的にゼロに抑えられているということです。
また、Bigtableはさまざまなアプリケーションのバックエンドとして利用されるため、トラフィックの変動パターンに規則性がなく、さまざまなトラフィックの変化に対して、リソースコストとパフォーマンスを最適化するための自動化が必要になります。現在のBigtableでは、突発的な負荷に対応する「Autosizer」と長期的な最適化を実現する「Autoscaling」を組み合わせたアーキテクチャーが採用されています。まず、Bigtableのクラスタ内で稼働するAutosizerは、CPUやメモリの負荷、さらには、tabletの可用性といった独自のヘルスチェックメトリックを1分未満（数十秒ごと）の頻度で監視し、必要に応じてアイドル状態のサーバープールからリソースを追加します。そして、サーバープールが枯渇しそうな場合は、データセンター全体のリソースを管理するAutoscalingシステムにリクエストを送り、複数サービスの共有プールから追加のリソースを割り当てます。共有プールのサーバーから新たにBigtable用のサービスを起動する際は数分のタイムラグが発生しますが、アイドル状態のサーバープールからは即座にリソースを追加できるので、突発的なトラフィックのスパイクにも高速に対応できます。
2026年に公開された論文「Twenty years of Bigtable」に基づいて、2006年の論文公開から現在までの20年間に、Googleの分散データベースBigtableが歩んできた進化を振り返りました。開発当初のシンプルなアーキテクチャーと徹底したスケーラビリティという特徴を受け継ぎながら、グローバルなマルチマスター・レプリケーションやGoogleSQLによるクエリー実行、そして自律的なリソース最適化など、さまざまなユーザーからの要求に応えるための機能拡張を続けてきたことが分かります。
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
