GCP Bigtable メモ

GCP

はじめに

GCPの資格を取得するにあたり、Bigtableの細かな部分まで聞かれそうなのでメモ。
あくまでも勉強したものの備忘録。

オープンソースのHBaseはBigtableが基になっているということで関連する点も多い。
用語やナレッジとしてHBaseの文献が参考になることもある。

Cloud Bigtable のドキュメント  |  Cloud Bigtable ドキュメント  |  Google Cloud
大容量データの解析や操作のための高性能な NoSQL データベース サービス。低レイテンシで高スループットを実現します。

スキーマの設計

スキーマの設計  |  Cloud Bigtable ドキュメント  |  Google Cloud

一般的なコンセプト

Cloud Bigtableでスキーマ設計をする際に考えるべきコンセプト

  • 各テーブルのインデックス(行キー)は 1 つのみです。二次インデックスはありません。
  • 行は、行キーの(最小バイト文字列から最大バイト文字列まで)辞書順に並べ替えられます。
  • 列は、列ファミリー別にグループ化され、列ファミリー内で辞書順に並べ替えられます。
  • すべての操作は行レベルでアトミックに実行されます。
  • 読み取りと書き込みは(テーブルの行スペース全体に)均等に分散されるのが理想的です。
  • 関連するエンティティは隣接する行に格納するようにします。
  • Cloud Bigtable テーブルはスパースです。
  • 多数の小さなテーブルよりも、少数の大きなテーブルを使用することをおすすめします。

参考サイト

DBのインデックスと複合インデックス - Qiita
Q:インデックスとは? データの並び順序のこと 初期状態では主キーに対してインデックスが割り当てられている。 Q:インデックスをつける意味は? データ件数が多いテーブルの検索を早くすることができる。 例えば下記の社員テー...
HBaseのアーキテクチャを理解しよう
 前回はHBaseの概要について説明し、実際にHBaseを動かしてみました。今回はHBaseのアーキテクチャについて解説していきたいと思います。
いまさら聞けないKVSの常識をHbaseで身につける (2/3)
Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク/ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載

時系列データ用のスキーマ設計

時系列データ用のスキーマ設計  |  Cloud Bigtable ドキュメント  |  Google Cloud

通常のRDSとは違い、行キーをかなり柔軟に設計できる印象。
そのため、ホットスポットを避けるために列データを無理やり行キーに詰め込んだりもするそうな。

行キー列データ(人)列データ(スコア)
2021#1223#1000Aさん100
2021#1223#1001Bさん50
2021#1223#1002Aさん80

上記の例だと、時系列データが単純増加で生成されるので、ホットスポットが発生する。
そのため、下の例では人の名前を行キーにいれることで、ホットスポットを避けている。

行キー列データ(スコア)
Aさん#2021#1223#1000100
Bさん#2021#1223#100150
Aさん#2021#1223#100280

行キーには最も頻繁に、かつ重要なクエリの情報を詰め込むなどの設計や、ホットスポットを避けるための設計が重要になる。

以下はホットスポットを避けるための工夫

方法内容
フィールドプロモーション上述のように、列データを行キーにうつす
ソルティング行キーにハッシュ値を埋め込み、単純増加を防ぐ。

パフォーマンスについて

Cloud Bigtable のパフォーマンスについて  |  Cloud Bigtable ドキュメント  |  Google Cloud

データのインポートとエクスポート

データのインポートとエクスポート  |  Cloud Bigtable ドキュメント  |  Google Cloud

以下の形式でエクスポート/インポートすることができる。

  • Avroファイル
  • Parquestファイル
  • SequenceFiles

別のデータベースからインポート(移行)することもできる。

  • HBase
  • CSV

レプリケーション

インスタンスにクラスタを追加すると自動的にレプリケーションが行われ同期される。
各クラスタは異なるゾーンに設置する必要がある。

同一リージョン、異なるゾーン:OK
異なるリージョン=異なるゾーン:OK

地理的な冗長構成をとるなら異なるリージョンのほうが良いが、値段が高くなる。

コメント

タイトルとURLをコピーしました