1.GCPのDBサービスの住み分け

DBサービスは簡単にいうとデータを保管する場所になります。
ここでは、各種サービスについての住み分けをお伝えできればと思います。

参考：https://www.youtube.com/watch?v=FCHMVzkVPos&t=1305s

構造化データかそうでないかで分ける

Cloud Strage以外のデータは基本的に構造化されたデータを格納する場所になっております。
音声データや、画像データなど、構造化されていないデータは非構造化データと言われております。

また、データ解析で用いるのか否かについて分けます。

データ解析で用いられているとされているのが、
Bigquery
Big queryの利点として、複雑なクエリに対処できるという点が一番大きいです。
他の利点等は後に説明します。

2.Cloud Strage

Cloud Strageを使う利点として、非構造化データを扱うものとして適しているとお話ししました。

このCLoud Sterageには4つのストレージクラスが存在します

Standard Storage

こちらはアクセス頻度の高いホットデータに適しています
短期間だけ保存されるデータにも適しています。

Nealine Storage

このクラスが適しているのは、アクセス頻度が低く、読み取りや変更が平均して
月に一回程度しか行われないデータです。
データのバックアップなどに使われます。

データのバックアップについては、Bigqueryと関係してくる場面が出てくるので後ほど説明します。

Coldline Storage

Neaelineと同様の使い方をするが、読み取りが90日に１回程度しか読み取りや変更が行われないデータむけになっています。

Archive Storage

アクセス頻度が年に１回未満のデータに最適なオプションとなっています。
最低保存期間が365日という最小保存期間があります。

3.Big table

Big tableは、大規模でスケーラブルなアプリケーションをサポートすることを目的として設計された
NoSQLデータベースです。
1秒あたりの読み取りと書き込みに関して大規模なスケーリングの必要があるアプリケーションを作成する場合は
BigTableを使用します。

アーキテクチャの説明

アーキテクチャは以下の通りになっています。

先に参考にさせていただいたURLを載せます。：https://laboratory.kiyono-co.jp/493/gcp/

クラスタ

クラスタはノードがまとまって構成されています。いわば作業場のような場所になっています

ノード

ノードは、作業する人を指します

タブレット

タブレットは、SSTableと書かれている場所になります
ここからデータを書き込んだり、読み込んだりします

Bigtableは1つのテーブルにデータを集約して使用します。
その集約したテーブルがタブレットとして分割されて各ノードと紐づいています。

使用する場面

例えば、ioTデバイスや、金融取引
ログ分析、時系列データの保存などの用途に適しています。

データの持ち方

一意の行キーを持っており、それに対して、列データが保存されています。
いわゆるキーバリューストアとなっています。

この行キーを使用して、データを探索することになります。
どのように行キーをスキーマ設計するのかについては、とても重要な説明になります。

Big tableは行指向

データをスキャンする際は、行単位でスキャンされます。
その構造から、基本的には横長にすることにより、スキャン効率が良くなります。

ですが、横長にすればよいという話でもないです。

したの図のように設計するとどうなるでしょうか。

時系列データだと、膨大な横データになってしまいますね。

抑えておくべきポイントとして、1行のデータ容量は100MB以下にすることがパフォーマンスの観点から大切です

このようにすることによって、1行データの容量は100MB以下にすることが可能になるかもしれません。

スキーマ設計で注意するべきポイント

・連続した行に書き込みを行わない
・１つの行を頻繁に更新しない

先ほど、１つのテーブルに対して、タブレットが存在していると説明しました。
タブレットは各ノードに紐づいています。

そのため、連続した行で書き込みを行なってしまうと、あるノードだけ爆発してしまう問題が起きてしまいます。
また、１つの行を頻繁に更新することも同様で、１つのノードのみ爆発してしまう問題が生じてしまいます。

スキーマ設定で試しておきたいのが、以下の２つです。

Key Visualizer → 処理が集中している行がどこなのかを特定できる
Cloud Monitoring → Bigtableでは、どこのノードのCPU使用率などを確認できる

これらを使用することで、Big tableのパフォーマンスを確認することが可能になります

既存のビックデータツールと簡単に統合が可能

HadoopやDataflowなどのApacheエコシステムとの簡単に統合が可能なので、そこで前処理を行なったりすることが可能です。

4.Bigquery

DBの中でも分析ツールとしての位置付けとされているBig queryです。
PB(ペタバイト)規模の分析を行うことを可能としています。
Excelやスプレットシートなどでの分析はGB程度なら可能ですが、PB規模になるとアプリケーションが終了してしまいます。

監査が可能

部署などで複数人がBigqueryを使用している際は、誰がどのようなデータにアクセスしたかを確認することができます。

Bigqueryのアーキテクチャ

Big queryはコンピューティングリソースとストレージが切り離されています。
そのため、柔軟なスケーラビリティを持っています。

他のDWHの構造は違うのか？

AWSのサービスであるRedshiftは、コンピューティングリソースとストレージが一体となっているので
ストレージを大きくしたいとなったら、必然的にコンピューティングリソースも大きくしなくてはいけないのです。

また、RDBについては、行指向のデータベースなのに対し、Bigqueryは列指向のストレージを持っております。
これはRedshiftも同様です。

列指向ストレージのメリット

例えば、4列目のデータをスキャンしたい場合、行指向の場合、すべてのデータをスキャンしなくてはいけません。
実際の企業の生データのカラムは数百もしかしたら数千などもありうるため、DWHが行指向だと、データスキャンがかなり大きくなってしまいます。

圧縮率の向上にもつながる

同じ列のデータは、持つデータの型が類似していることから、圧縮率が高くなります。

そのため、データマートの構築について気を付ける点としては、
必要最低限のカラム数にすることが大切です。

また、bigqueryはデータマートであるGCSのファイルを読み込んでクエリを返すことも可能です。
その際に、是非使っていただきたいフォーマットとして、
parquetがあります。

フォーマットには様々な種類があります。

・テキストフォーマット（CSV、Jsonなど）
・行指向フォーマット（AVROなど）
・列指向（カラムナ）フォーマット（Parquet、ORCなど）

列指向のフォーマットなので、BigqueryなどのDWHでの読み込みがとても早いです。

圧縮率などを検証しているサイトがあるので、是非見てみてください

データの復元

スナップショットデコレーター：

7日以内のデータの破損であれば、その機能を用いて、データを復元することが可能。

ただし、７日を超えるようであれば、Cloud strageに保存し、アーカイブを取っておく必要がある。

少しコアな話

BigqueryにETL処理した結果をテーブルに保存しているとして、
Transformの処理のサービスを変えたとします。

ただし、出力の結果を変えていない場合、
変更前の結果と変更後の結果が同一と確認したい場合は、どうすればよいのか？

その際は、
ハッシュ値というものを使います。
ハッシュ値というのは各レコードごとに決まっており、もし、要素の値がすべて同じであれば
ハッシュ値は同じになります。

そのため、テストとして出力結果が同じこと確認したい場合はそれを使いましょう。

5.Cloud SQLとCloud Spanner

Cloud Spanner

フルマネージドなRDB

グローバル水平スケーリングが求められる⇨Spanner

（処理負荷に応じてインスタンス数を変更する機能）

大量データを扱う⇨Spanner

それ以外⇨Cloud SQL

CloudSQL

フルマネージドサービスのRDBのため、可用性も自動的に行なってくれるため
アプリケーション開発に集中することが可能。

HA構成は「クラスタ」とも呼ばれ、データの冗長性を確保します。HA向けに構成されたCloudSQLインスタンスは「リージョンインスタンス」とも呼ばれている。

構成されたリージョン内のプライマリゾーンとセカンダリゾーンに配置される

各ゾーンの永続ディスクへの動機レプリケーションにより、トランザクションがcommitされた場合、プライマリインスタンスへの書き込みの全てが両方のゾーンのディスクに複製される。

障害発生時には、スタンバイインスタンスに切り替わるので、ダウンタイムが発生しない。（フェイルオーバーと呼ばれている）