Loading article…
Bigtableは、 Google Cloudポートフォリオの一部として提供される、大規模な分析および運用ワークロード向けの、フルマネージド型のワイドカラムおよびキーバリュー型NoSQLデータベースサービスです。
Bigtable の開発は 2004 年に始まりました。[ 1 ]現在では、Google Analytics [ 2 ]、ウェブインデックス作成[ 3 ] 、Bigtable に保存されているデータの生成や変更によく使用されるMapReduce [ 4 ] 、 Google マップ[ 5 ] 、Google ブックス検索、「マイ検索履歴」、Google Earth、Blogger.com、Google Codeホスティング、YouTube [ 6 ]、Gmail [ 7 ]など、多くの Google アプリケーションで使用されています。Googleが独自のデータベースを開発した理由には、スケーラビリティとパフォーマンス特性のより良い制御が含まれます。[ 8 ]
Apache HBaseとCassandraは、Bigtableをモデルにした最も有名なオープンソースプロジェクトのいくつかです。Bigtableは、HBaseとCassandraと互換性のあるAPIを提供しています。
2015年5月6日、BigtableのパブリックバージョンがCloud Bigtableという名称でGoogle Cloudの一部として提供開始されました。 [ 2 ]
2024年4月現在、Bigtableは10エクサバイトを超えるデータを管理し、毎秒70億件以上のリクエストを処理しています。[ 9 ]リリース以来、GoogleはSQLサポート、増分マテリアライズドビュー、グローバルセカンダリインデックス、自動スケーラビリティなど、Bigtableの多くのアップデートを発表しました。 [ 10 ]
Bigtable は、ワイド カラム ストアのプロトタイプ例の 1 つです。任意の 2 つの文字列値 (行キーと列キー) とタイムスタンプ (したがって 3 次元マッピング) を関連付けられた任意のバイト配列にマッピングします。リレーショナル データベースではなく、疎で分散された多次元ソート マップとして定義する方が適切です。[ 3 ] : 1これは、Colossus ( Google ファイルシステム)、Chubby Lock Service 、SSTable ( LevelDBのようなログ構造ストレージ)、およびその他のいくつかのGoogleテクノロジーに基づいて構築されています。Bigtable は、「数百または数千のマシン」にわたってペタバイトの範囲に拡張し、システムにマシンを簡単に追加して、再構成なしで自動的にそれらのリソースを利用できるようにするように設計されています。[ 11 ]たとえば、行キーがドメインを反転した URLであり、列が Web ページのさまざまなプロパティを記述し、特定の列にページ自体を保持する Bigtable に、Google の Web のコピーを保存できます。ページ列には、取得日時がタイムスタンプされた複数のタイムスタンプ付きバージョンを含めることができます。これは、Webページの異なるコピーを記述するものです。ビッグテーブルの各セルには、タイムスタンプ付きバージョンのデータが0個以上含まれている可能性があります。タイムスタンプのもう1つの機能は、バージョン管理と期限切れデータのガベージコレクションを可能にすることです。
テーブルは複数のタブレットに分割されます。テーブルのセグメントは特定の行キーで分割され、各タブレットのサイズは数百メガバイトまたは数ギガバイトになります。ビッグテーブルは、数千から数十万のタブレット シャードが数百から数千のビッグテーブル サーバーによって提供されるという点で、マップリデュース ワーカー プールにいくらか似ています。テーブル サイズが指定された制限を超える恐れがある場合、タブレットは BMDiff [ 12 ] [ 13 ]アルゴリズムと Zippy 圧縮アルゴリズム[ 14 ]を使用して圧縮されます。Zippyは一般にSnappy [ 15 ]として知られ、オープンソース化されています。これはLZ77のスペース最適化の度合いは低いものの、計算時間の効率は高いバリエーションです。タブレットの GFS 内の位置は、複数の特別なタブレットのデータベース エントリとして記録され、これらは「META1」タブレットと呼ばれます。 META1タブレットは、単一の「META0」タブレットに問い合わせることで見つかります。META0タブレットは通常、専用のサーバー上に存在します。これは、クライアントが「META1」タブレットの場所を問い合わせることが多く、META1タブレット自体が実際のデータの場所に関する回答を持っているためです。GFSのマスターサーバーと同様に、META0サーバーは一般的にボトルネックにはなりません。META1の場所を検出して送信するために必要なプロセッサ時間と帯域幅は最小限であり、クライアントはクエリを最小限に抑えるために積極的に場所をキャッシュするからです。
まず概要を説明します。Bigtable は 2004 年初頭から開発が進められ、約 8 か月 (2005 年 2 月頃) から実際に使用されています。
現在、印刷、検索履歴、マップ、Orkut などのサービス用に約 100 個のセルがあります。
サムネイルの新しいソリューションは、GoogleのBigtableを使用することです。これは、多数の行に対して高いパフォーマンス、耐障害性、キャッシュなどを提供します。これは、買収における実際の相乗効果の素晴らしい（そして珍しい？）例です。