Bigtable
についてまとめます。
AWSのDynamoDB同様、有名なNoSQLデータベースですね。
Overview
https://cloud.google.com/bigtable/docs/overview
- Key Value Store
- 低レイテンシー
- 高いRead/Writeスループット
- 行が多いデータに向いている
- HBase1 をはじめとするアプリケーションと連携できる
- 1行は10MBいかないくらい
- 時系列、マーケティング、財務、IoT、グラフデータに向いている
- row/columns > column family > column qualifier
- Tabletという隣接する列ごとにシャードされる
- TabletsはColossusというGoogleのファイルシステムに格納される
- row keyがノードで分散するようにするのがコツ
- 関連する行は近くに置く,
WashingtonDC#201803061617 - データ圧縮は自動で行われる、ただし1MBを超えるものはしない、
Instances, clusters and nodes
https://cloud.google.com/bigtable/docs/instances-clusters-nodes
- 1インスタンスは最大4クラスターもてる
- 各クラスターはユニークなゾーンに配置される
- クラスターを増やしてフェイルオーバーに備えることができる
- ノードはコンピュータリソース
- cpu usageやstorage utilizationをモニターできる
How to guides
https://cloud.google.com/bigtable/docs/how-to
schema
- 1インデックス、セカンダリーはない
- 行レベルでアトミック、行ごとに成否が決まる
- 空の列が多いスパースなテーブルでもよい
- テーブルはたくさん作らない
- セルは10MBまで、行は100MBまでを目安に
- row key
- リバースドメイン名, com.googleみたいな
- string identifier
- timestamp, アクセスの仕方によるが, 何かの名前の後のほうがいい
- aaa#bbb, みたいな複数の値を格納したもの
- ニューメリックなユーザーidは避ける
- columns
- 不必要にqualifierを分けない
- データがまとまっているときはprotocol bufferを使う
Backups
- データをバックアップして復旧できる
- ゾーンレベルの障害にはレプリケーションで対応するべき
- 自動削除できる
- クラスターレベルでテーブルがバックアップされる
Manage data
- Avro, Parquet, Sequenceファイルが可能
- HBaseやcsvからBigtableにインポートできる
- cbtというcliが便利
- client libraryで4種のwriteができる
- simple write: ある行を変更する
- incremental and append: 行を追加したり、値を増やしたりする
- conditional write: 条件に合う行を変更する
- batch write: 複数の行を変更する
- read
- single row
- scan
- filtered
Gabage collection
https://cloud.google.com/bigtable/docs/garbage-collection
不要になったデータ (行?) を、時間やバージョン数に応じて削除する
Performance
https://cloud.google.com/bigtable/docs/performance
ざっと眺めましょう。チューニングはたぶん試験に出ます。
おおまかなポイントは以下です。
- SSD or HDD
- スループットかレイテンシーか
- 高リードか高ライトか
- トラフィックがグローバルかどうか
App profiles
https://cloud.google.com/bigtable/docs/app-profiles
- single cluster routing: リクエストを一つのクラスターに割り振る
- Multi cluster routing: リクエストを近いクラスターに割り振る
...
以上でした。
このほかにもドキュメントはあるのですが、さすがに多くてまとめきれません。
-
Hadoop上のNoSQLデータベース、https://hbase.apache.org/ ↩
