Bigtableについて調べてみました。
他のDBと比較
活用用途と金額を他のGCPプロダクトのDBと比較してみます。
大規模データを扱う場合、価格は以下となります。
Cloud Spanner > Bigtable > BigQuery
Cloud Spanner では高価で10 万 QPS の対応に、Bigtable では 10 ノードで十分ですが、Cloud Spanner では最大 150 ノードが必要です。Cloud Spannerのメリットとしてはトランザクションをサポートしている点です。
BigtableやBigqueryはトランザクションをサポートしていません。トランザクション処理が必要かつ大規模データを扱う場合はCloud Spannerも有益だと思います。CloudSQLはGCPのフルマネージドなMySQLやPostgreSQLです。数百GB程度のデータに対して適切なDBとなります。
cloud.google.com
Bigtableのアーキテクチャ
Bigtableはノード間で処理を分散し高速化を実現します。データはcolossusと呼ばれるストレージで管理され、ノードはこのcolossusのポインタを元に検索処理します。このアーキテクチャのメリットとしてはデータをノードに保存していないのでノードに問題が発生しても他のノードで対応することができることです。GCPプロダクトのDataprocでもHDFSにデータ保存するのではなくGCSにデータを保存して実行することが推奨されています。
基本的な考え方としてサーバとストレージは分けるのが主な考え方のようです。
スキーマ設計
Bigtableのスキーマ設計には人工夫必要です。Bittableのスキーマ設計としてKEYの作り方とカラムファイリーについて調べてみました。
KEYの作り方
Bigtableが大規模データを高速に処理できるのはノードによる分散処理をしているためです。
BigtableはKEYに応じてノードを分け分散処理します。
なのでノードが分散されないようなKEYの設計は避ける必要があります。
悪い例：
ユーザIDをKEYとする
=> 新規のユーザーや特定のユーザのみアクセスが集中する
良い例：
ユーザIDとタイムスタンプの組み合わせをKEYとする
=> KEYが異なるためノードが分散される。
上記は一例ですが実際にはサービスのアクセスパターンやサービスの性質を理解し適切なKEYを作る必要があります。
カラムファミリー
類似するカラムをグルーピングすることが可能です。
グルーピングすることで以下のようなメリットがあります。
・処理を最低限にできる
・通信量を抑えることが可能
