case-kの備忘録

日々の備忘録です。最近はGCPやデータ分析系のことを呟きます

Bigtableの特性とスキーマ設計について

Bigtableについて調べてみました。

Bigtableとは

GCPプロダクトのNoSQLデータベースで大規模データをミリセックレベルの低レイテンシーで処理したい場合適切です。

他のDBと比較

活用用途と金額を他のGCPプロダクトのDBと比較してみます。
f:id:casekblog:20190916162520p:plain:w500

大規模データを扱う場合、価格は以下となります。
Cloud Spanner > Bigtable > BigQuery
f:id:casekblog:20190916163509p:plain:w500
Cloud Spanner では高価で10 万 QPS の対応に、Bigtable では 10 ノードで十分ですが、Cloud Spanner では最大 150 ノードが必要です。Cloud Spannerのメリットとしてはトランザクションをサポートしている点です。
BigtableやBigqueryはトランザクションをサポートしていません。トランザクション処理が必要かつ大規模データを扱う場合はCloud Spannerも有益だと思います。CloudSQLはGCPのフルマネージドなMySQLPostgreSQLです。数百GB程度のデータに対して適切なDBとなります。
cloud.google.com

Bigtableアーキテクチャ

Bigtableはノード間で処理を分散し高速化を実現します。データはcolossusと呼ばれるストレージで管理され、ノードはこのcolossusのポインタを元に検索処理します。このアーキテクチャのメリットとしてはデータをノードに保存していないのでノードに問題が発生しても他のノードで対応することができることです。GCPプロダクトのDataprocでもHDFSにデータ保存するのではなくGCSにデータを保存して実行することが推奨されています。
基本的な考え方としてサーバとストレージは分けるのが主な考え方のようです。
f:id:casekblog:20190916160954p:plain:w500

スキーマ設計

Bigtableスキーマ設計には人工夫必要です。Bittableのスキーマ設計としてKEYの作り方とカラムファイリーについて調べてみました。

KEYの作り方

Bigtableが大規模データを高速に処理できるのはノードによる分散処理をしているためです。

BigtableはKEYに応じてノードを分け分散処理します。

f:id:casekblog:20190916160507p:plain:w500

なのでノードが分散されないようなKEYの設計は避ける必要があります。

悪い例: 
ユーザIDをKEYとする
=> 新規のユーザーや特定のユーザのみアクセスが集中する

良い例: 
ユーザIDとタイムスタンプの組み合わせをKEYとする
=> KEYが異なるためノードが分散される。

上記は一例ですが実際にはサービスのアクセスパターンやサービスの性質を理解し適切なKEYを作る必要があります。

カラムファミリー

類似するカラムをグルーピングすることが可能です。
f:id:casekblog:20190916160723p:plain:w500

グルーピングすることで以下のようなメリットがあります。
・処理を最低限にできる
・通信量を抑えることが可能

所感

Bigtableは低レイテンシーが求められるサービスには有益だと思いました。コストがかかるので、ミリセックレベルの低レイテンシーが求められていないのならBigqueryで十分かと思いました。

cloudonair.withgoogle.com

cloud.google.com