Coud Bigtableとは
Cloud Bigtable は、NoSQLのワイドカラム型データベースであり、次のような用途に最適化されています：
-
単一キーによる高速な読み書き（例：RowKey によるアクセス。RDBのような「primary key」という概念はありません）
-
大規模な時系列データやIoTデータ、センサーデータ、分析ログなど
-
低レイテンシかつスケーラブルな読み書きが必要な場面
ストレージとコンピュートを分離してスケールする設計になっています。
Hadoop との連携（HBase API 互換）が可能で、Hadoop + Hive のワークロードを Google Cloud 上で実行することができます。
推奨される最小データ量
最低でも 1TB 以上のデータを保持するユースケースが推奨されています。
推奨最大スループット
Cloud Bigtable の 1 ノードあたり推奨最大スループットは 約5 GB/秒（読み書き合計）です。
ノード数の最小構成
Cloud Bigtable の最小構成は 3ノード です。これは可用性と負荷分散のための最小要件です。
HBase Shell
管理タスク（テーブルの作成や削除など）を行うコマンドラインツール。
Key Visualizer
Key Visualizer は Bigtable に特化したツールで、以下のような分析が可能：
-
ホットスポットの可視化（特定のキー範囲にアクセスが集中しているなど）
-
読み取り／書き込みの傾向把握
-
レイテンシ、スループットなどの異常箇所の特定
Key Visualizer の Write Pressure Index が 100 を超えると、書き込み負荷が高すぎることを示しています。これはスケーリングのサインの一つです。
クラスタ構成
-
マルチクラスタ構成でトラフィック分散が可能。本番トラフィックと分析トラフィックを別クラスタに分けて処理できます。
-
継続的に書き込みレイテンシが高い場合、ノード数が足りない可能性があるため、クラスタサイズの増加が有効です。
パフォーマンスが悪化する原因
- ノード数が多すぎることはパフォーマンス悪化の要因にはなりません。
- 行キーの先頭バイトでシャーディングするため、時系列データのように連続するキー（例：タイムスタンプ）を使うと、同じノードに書き込みが集中してしまい「ホットスポット」が発生します。ランダムまたはプレフィックス的に異なる文字列を行キーの先頭に付けることで、データの分布を分散させられます。(Salting（ソルト付加))
レイテンシ対策
Cloud Bigtable はレイテンシに非常に敏感なサービスであり、最良のパフォーマンスを得るためには Compute Engine などのクライアントと Cloud Bigtable を同一ゾーンに配置することが推奨されます。
ストレージオプション
Cloud Bigtable では、SSD と HDD はインスタンス作成時に選択するストレージオプションであり、作成後に変更することはできません。そのため、ストレージタイプを変更したい場合は、次の手順が推奨されます：
1.既存のインスタンスからデータを exportする
2.新しいインスタンスを 希望するストレージタイプ（SSDまたはHDD） で作成する
3.データを新インスタンスに importする
権限付与
Bigtable Editor ロールはプロジェクトまたはインスタンスレベルでしか付与できず、テーブル単位での権限付与はできません。
課金体系
Cloud Bigtable の課金は大きく分けて 3つの要素 で決まります。BigQueryのような「クエリ課金」はありません。
ストレージ料金
-
データの保存量に応じて課金
-
SSD と HDD で単価が異なる（SSD の方が高いが性能が高い）
-
単位は GB/月
-
複数リージョン・レプリケーションを使う場合は、その分も課金される
ノード（処理能力）料金
-
Bigtable は ノード単位でプロビジョニングされ、1ノードは固定のCPU・メモリ・ストレージI/O性能を持つ
-
課金単位は ノード数 × 時間単価
-
読み書きスループットはこのノード数に比例して増える
-
使わなくても確保している限り課金される（常時稼働）
ネットワーク料金
-
リージョン外へのデータ送信（Egress）は別途課金
-
同一リージョン内のアクセスは無料
-
他のGCPサービスやクライアントからのアクセスでリージョンを跨ぐとコスト発生