Cloud Bigtable の概要

Cloud Bigtable はスパース(低密度)に格納されるテーブルであり、数十億行、数千列の規模にスケール可能です。これにより、数テラバイト、あるいは数ペタバイトのデータを格納できます。各行の単一の値がインデックスに登録され、この値が行キーとなります。Cloud Bigtable は、極めて低いレイテンシで単一キーの超大容量データを格納するのに理想的です。 低レイテンシで高い読み取り / 書き込みスループットを実現できるため、MapReduce オペレーションに理想的なデータソースです。

Cloud Bigtable は、Java 用 Apache HBase ライブラリに対するサポートされた拡張機能など、複数のクライアント ライブラリ経由でアプリケーションに公開されます。このため、オープンソースのビッグデータ ソフトウェアを形成する既存の Apache エコシステムと統合可能です。

Cloud Bigtable の強力なバックエンド サーバーには、セルフマネージド HBase インストール環境と比較して、次のような利点があります。

  • 卓越したスケーラビリティ。 Cloud Bigtable はクラスタ内のマシン台数に正比例してスケールします。セルフマネージド HBase インストール環境には設計上のボトルネックがあるため、QPS があるレベルに達するとパフォーマンスが制限されます。Cloud Bigtable にはこのようなボトルネックはないため、クラスタの規模をスケールして、さらに多くのクエリを処理できます。
  • 管理の簡素化。 Cloud Bigtable はアップグレードを実行し、透過的に再起動されます。また、高いデータ耐久性を自動的に維持します。データを複製する場合、インスタンスを 2 番目のクラスタに追加するだけで、複製が自動的に開始されます。マスターやリージョンを管理する必要はなくなりました。テーブル スキーマさえ設計すれば、他の作業は Cloud Bigtable によって処理されます。
  • ダウンタイムなしでクラスタをサイズ変更可能。 Cloud Bigtable クラスタのサイズを数時間だけ増やして大規模な負荷を処理し、その後クラスタのサイズを元に戻すことができます。ダウンタイムは一切発生しません。クラスタのサイズを変更すると、クラスタ内の全ノードで均等なパフォーマンスが得られるようになるまで、負荷がかかった状態でも通常は数分しかかかりません。

最適な用途

Cloud Bigtable は非構造化 Key-Value データ(それぞれの値のサイズが 10 MB 以下)を扱う、非常に高いスループットとスケーラビリティを必要とするアプリケーションに最適です。また、MapReduce の一括オペレーション、ストリーム処理と分析、機械学習アプリケーションといった用途におけるストレージ エンジンとしても優れています。

Cloud Bigtable を使用すると、以下のすべてのタイプのデータを格納してクエリできます。

  • 時系列データ。複数のサーバーにおける時間の経過に伴う CPU とメモリの使用状況など。
  • マーケティング データ。購入履歴やお客様の好みなど。
  • 金融データ。取引履歴、株価、外国為替相場など。
  • IoT(モノのインターネット)データ。電力量計と家庭電化製品からの使用状況レポートなど。
  • グラフデータ。ユーザー間の接続状況に関する情報など。

Cloud Bigtable ストレージ モデル

Cloud Bigtable では、大規模にスケーリング可能なテーブル(並べ替えられた Key-Value のマッピング)にデータが格納されます。テーブルは、(通常は、各行が単一のエンティティを表す)と(各行の個々の値が格納される)で構成されます。各行は単一の行キーでインデックスに登録されており、相互に関連する列は通常、列ファミリーとしてグループ化されます。各列は列ファミリーと列修飾子(特定の列ファミリー内で一意の名前)の組み合わせによって識別されます。

各行と列の交差点には、異なるタイムスタンプで複数のセルを格納できます。これにより、格納済みのデータの時間の経過に伴う変更履歴が残されます。Cloud Bigtable テーブルはスパースです。つまり、データが格納されていないセルが領域を消費することはありません。

たとえば、アメリカ合衆国の大統領たちのソーシャル ネットワークを構築するとします。このソーシャル ネットワークを仮に Prezzy と呼ぶことにしましょう。各大統領は、他の大統領による投稿をフォローできます。下図は、各大統領が Prezzy 上でフォローしている相手を追跡する Cloud Bigtable テーブルを示しています。

各ユーザー名について 1 行が対応している Cloud Bigtable テーブル。

この図で注目すべき点を以下に示します。

  • このテーブルの列ファミリーは 1 つだけですfollows ファミリー)。このファミリーには複数の列修飾子が格納されています。
  • 列修飾子がデータとして使用されています。 この設計は、Cloud Bigtable テーブルのスパース性、新しい列修飾子を動的に追加できる事実を活かしたものです。
  • ユーザー名が行キーとして使用されています。 ユーザー名がアルファベット全体に均等に分散しているものと仮定すると、データアクセスはテーブル全体に渡ってある程度均一に分散されます。Cloud Bigtable が不均一な負荷に対処する方法については、負荷分散をご覧ください。また、行キーの選択に関する高度なヒントについては行キーの選択をご覧ください。

Cloud Bigtable のアーキテクチャ

以下に、Cloud Bigtable 全体のアーキテクチャの概略図を示します。

Cloud Bigtable のアーキテクチャ概要。

図のとおり、すべてのクライアント リクエストはフロントエンド サーバーを経由して Cloud Bigtable ノードに送信されます(Bigtable の初期のホワイト ペーパーでは、これらのノードを「タブレット サーバー」と呼んでいます)。これらのノードは Cloud Bigtable クラスタとして編成されます。Cloud Bigtable クラスタは、クラスタのコンテナである Cloud Bigtable インスタンスに属しています。

クラスタ内の各ノードは、クラスタに対するリクエストの一部を処理します。クラスタにノードを追加することで、クラスタが同時に処理できるリクエストの数や、クラスタ全体の最大スループットを増やすことができます。2 つ目のクラスタを追加してレプリケーションを有効にすると、クラスタごとに異なる種類のトラフィックを送信できます。また、一方のクラスタが使用できなくなった場合に、もう一方のクラスタにフェイルオーバーできます。

Cloud Bigtable テーブルは連続する行ブロック(「タブレット」)として共有され、クエリの負荷分散を実現します(タブレットは HBase リージョンに相当します)。タブレットは、Google のファイル システムである Colossus に SSTable 形式で格納されます。SSTable は、永続的な順序付きの、キーから値への不変マップとなっています。ここで、キーと値はどちらも任意のバイト文字列です。各タブレットは個々の Cloud Bigtable ノードに関連付けられます。すべての書き込みは、SSTable ファイルに格納されるだけでなく、Cloud Bigtable に認識されると直ちに Colossus の共有ログにも格納されます。これにより、耐久性が向上します。

重要なことは、データは Cloud Bigtable ノード自体に格納されるのではないという点です。各ノードはタブレットのセット(Colossus に格納されている)に対するポインタを保持しています。これにより、以下が実現されます。

  • ノード間のタブレット移動(再調整)が極めて高速になります。これは実データがコピーされないためです。Cloud Bigtable は、各ノードのポインタを更新するだけです。
  • Cloud Bigtable ノードの障害復旧が極めて高速に実行されます。これは、置換先の新しいノードにメタデータのみを移動すれば済むためです。
  • Cloud Bigtable ノードで障害が発生してもデータが失われることはありません。

これらの基本的な構成要素の処理の方法については、インスタンス、クラスタ、ノードをご覧ください。

負荷分散

各 Cloud Bigtable ゾーンはマスター プロセスによって管理されます。マスター プロセスはクラスタ内の負荷とデータ量の均衡を図ります。マスターは、アクセス数の多い大容量のタブレットを半分に分割し、アクセス数の少ない小さなタブレットを結合して、それらのタブレットを必要に応じてノード間で再配置します。特定のタブレットのトラフィックが突出している場合、マスターはそのタブレットを 2 分割し、その一方を別のノードに移動します。Cloud Bigtable は、分割、結合、再配置のすべての処理を自動的に行うため、タブレットの管理をユーザーが手動で行う必要はありません。以上のプロセスについては、Cloud Bigtable のパフォーマンスについてで詳しく説明しています。

Cloud Bigtable で最高の書き込みパフォーマンスを実現するには、書き込み操作をできる限り均等にノード間に分散することが重要です。この目標を達成する方法として、予測可能な順番に従わない行キーを使用する方法があります。たとえば、ユーザー名はアルファベット順でほぼ均等に分散する傾向があるため、ユーザー名を行キーの先頭で使用すると、書き込みの分散が均等になりやすくなります。

また、関連する行をグループ化して、近くにまとまるようにすると便利です。これにより、複数の行を同時に読み取る処理が効率的になります。たとえば、時間の経過に伴いさまざまな種類の天気情報データを格納する場合、データを収集した場所とタイムスタンプを連結したものを行キーとして使用できます(例: WashingtonDC#201803061617)。このような行キーを使用すると、1 つの場所から得られたすべてのデータが、行の連続した範囲としてグループ化されます。他の場所については、行が異なる識別子で始まります。多数の場所で同じ速度でデータが収集されるため、書き込みはタブレット間で均等に分散されます。

データの行キーを正しく選択する方法については、行キーの選択をご覧ください。

サポートされるデータタイプ

Cloud Bigtable では、ほとんどの場合、すべてのデータを RAW バイト文字列として扱います。インクリメント演算の場合のみ、Cloud Bigtable は型の特定を試行します。インクリメント演算では、ターゲットは、8 バイトのビッグエンディアン値としてエンコードされた 64 ビットの整数である必要があります。

メモリとディスクの使用状況

以下の各セクションでは、Cloud Bigtable のいくつかのコンポーネントが、インスタンスでのメモリとディスクの使用状況にどのような影響を与えるのかについて説明します。

空セル

Cloud Bigtable テーブル内の空セルは領域を消費しません。各行は基本的に Key-Value エントリの集合です。キーとは、列ファミリー、列修飾子、タイムスタンプを連結したものです。行に特定のキーの値が含まれていない場合、その Key-Value エントリは存在しないものとみなされます。

列修飾子

列修飾子は行内で領域を消費します。というのは、行で使用される各列修飾子はその行に格納されるからです。そのため、列修飾子をデータとして使用すると効率的なことがよくあります。上記の Prezzy の例では、follows ファミリーの列修飾子がフォローされているユーザーのユーザー名になっており、それらの列の Key-Value エントリは単なるプレースホルダ値になっています。

コンパクション

Cloud Bigtable は定期的にテーブルをリライトして削除されたエントリを除去し、読み取りと書き込みの処理効率が向上するようにデータを再編成します。このプロセスは「コンパクション」と呼ばれます。コンパクションの構成設定はなく、Cloud Bigtable がデータを自動的に圧縮します。

mutation と削除

行に対する mutation、すなわち変更を行うと、ストレージ領域が余分に消費されます。これは、Cloud Bigtable では mutation は順次格納され、圧縮は定期的にしか行われないためです。Cloud Bigtable がテーブルを圧縮すると、不要になった値が削除されます。セルの値を更新すると、元の値と新規の値の両方がディスク上に保管され、一定期間が経過するとデータが圧縮されます。

削除した場合も、少なくとも短期間は余分な領域が消費されます。削除は実際には特殊なタイプの mutation だからです。テーブルが圧縮されるまで、この余分な領域は解放されず、消費されたままになります。

データ圧縮

Cloud Bigtable は、インテリジェントなアルゴリズムを使用してデータを自動的に圧縮します。テーブルの圧縮設定を変更することはできません。ただし、効率的に圧縮されるようにデータを格納する方法を知っておくことは有益です。

  • ランダムデータはパターン化されたデータよりも圧縮効率が低くなります。パターン化されたデータの例としてテキスト(たとえば、今、皆さんがご覧になっているこのページ)があります。
  • 圧縮は、同じ値が互いに近接した場所にある場合に、動作効率が最も高くなります。近接した場所とは、同一行または隣接する行のことです。同じデータチャンクが格納された行が互いに隣接するように行キーを調整すれば、データを効率的に圧縮できます。

データの耐久性

Cloud Bigtable を使用すると、データが Colossus 上に格納されます。Colossus は、Google 内部の高い耐久性を持つファイル システムで、Google データセンター内のストレージ デバイスを使用して構築されています。Cloud Bigtable を使用するために、HDFS クラスタ、またはその他のファイル システムを稼働する必要はありません。インスタンスがレプリケーションを使用する場合、Cloud Bigtable は Colossus にデータのコピーを 2 つ保持します。コピーはそれぞれ異なるゾーンに配置されるため、耐久性が向上します。

背後で、Google が独自のストレージ方式を使用して、標準の HDFS 3方向レプリケーションによって提供されている以上のデータの耐久性を実現しています。また、大惨事からの保護や災害復旧を可能にするため、データのバックアップも作成されます。

セキュリティ

Cloud Bigtable テーブルへのアクセスは、Google Cloud Platform プロジェクトと、ユーザーに割り当てた Identity and Access Management(IAM)役割によって制御されます。たとえば、個々のユーザーがテーブルからの読み取り、テーブルへの書き込み、新しいインスタンスの作成を実行できないように、Cloud IAM 役割を割り当てることができます。プロジェクトに対するアクセス権を持たないユーザーや、Cloud Bigtable にアクセスするための適切な権限が設定された Cloud Bigtable IAM 役割のないユーザーは、どのテーブルにもアクセスできません。

セキュリティの管理は、プロジェクト レベルとインスタンス レベルで行うことができます。Cloud Bigtable では、テーブルレベル、行レベル、列レベル、セルレベルでのセキュリティ制限をサポートしていません。

Cloud Bigtable とその他のストレージ オプション

Cloud Bigtable はリレーショナル データベースではありません。したがって、SQL クエリや結合、複数行トランザクションはサポートされていません。また、格納するデータが 1 TB 未満の場合に適切なソリューションではありません。

  • オンライン トランザクション処理(OLTP)システム用の完全な SQL サポートが必要な場合は、Cloud Spanner または Cloud SQL を検討してください。
  • オンライン分析処理(OLAP)システムでのインタラクティブなクエリが必要な場合は、BigQuery を検討してください。
  • 大容量の画像やムービーなど、10 MB を超える大規模な不変 blob を格納する必要がある場合は、Cloud Storage を検討してください。
  • 高度に構造化されたオブジェクトを格納する必要があり、さらに ACID トランザクションや SQL ライクなクエリのサポートが必要な場合は、Cloud Datastore を検討してください。

その他のストレージ オプションについて詳しくは、ストレージ オプションの選択ガイドをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Bigtable ドキュメント