- 概要
- AutoML Vision
- Apache Hadoop
- BigTable
- BigQuery
- Cloud Pub/Sub
- Cloud Spanner
- Cloud Storage
- Cloud SQL
- Compute Engine インスタンス
- DataProc
- Dialogflow
- Datastore
- Data Loss Prevention API (DLP)
- Dataflow
- Kafka
- Logging
- Monitoring
- Natural Language API
- Video Intelligence API
- 機械学習
- その他DB
- その他ツール
- DB一般
- DBサービス
- PDEワークショップ
- CloudSpanner
- Cloud SQL
- GCPにおける「ストレージ」という呼称
- Cloud Spannerのセカンダリインデックス
- Bigtableにおける行キーの設計
- BigQueryのワイルドカードテーブル
概要
UdemyのGCP PDE模擬試験について、覚えておくべき重要なところをサービス別にメモしておく。
AutoML Vision
- AutoML Vision を使用すると、ラベル付きデータからパターンを認識する「教師あり学習」を実行できる
- 例えば、運送会社が扱う荷物は人の顔などとは異なり、一般的な学習済みモデルを使用することができないので、教師あり学習が必要になる
- AutoML Vision のトレーニングでは、カテゴリ / ラベルごとに最低でも 100 枚の画像が必要
Apache Hadoop
BigTable
何百万台ものコンピュータのCPUとメモリの使用量を時系列で保存したい
- BigTableにナロー・テーブルを作成し、Computer Engineのコンピュータ識別子と各秒のサンプル時間を組み合わせた行キーを設定する
BigTableのクラスタサイズを増やすタイミングが知りたい
- 書き込み操作のレイテンシーが持続的に増加
- ストレージの使用率が最大容量のxx%を超えた
パフォーマンスのボトルネックがある場合
- Bigtable 用 Key Visualizer ツールは、クラスタ内の各テーブルを毎日スキャンし、その使用パターンを表示する
- ホットスポットになっている行や CPU の過剰使用を確認できる
- 読み取り、書き込みがテーブル全体に均等に分散されているときに最高のパフォーマンスになる
- 特定の行に読み取りと書き込みが集中している場合、スキーマを再設計する
Bigtable インスタンスを作成した後にストレージを変更したい
行キーのベストプラクティス
- 「タイムスタンプのみ」は推奨していない
- sensorId + timeStampという行キーを推奨
バッチ分析ワークロードを他のアプリケーションから分離する
- 単一のクラスタ上で、多数の大規模読み取りを実行するバッチ分析ジョブを、読み取りや書き込みを実行するアプリケーションと並行して実行すると、アプリケーションの処理が遅くなる可能性がある
- アプリプロファイルにより、リクエストを異なるクラスタにルーティングする
BigQuery
バックアップ
- 破損の検出が 7 日以内の場合、過去の時点のテーブルに対してクエリを行い、スナップショット デコレータを利用して、破損する前のテーブルを復元します。
- BigQuery からデータをエクスポートし、エクスポートしたデータを含む（ただし破損したデータは含まない）新しいテーブルを作成します。
- 特定の期間ごとに、データを異なるテーブルに格納します。この方法では、データセット全体ではなく、データの一部のみを新しいテーブルに復元するだけで済みます。
- 例えば、データを月ごとに別々のテーブルに整理し、データをエクスポートして圧縮し、Cloud Storageに保存する。 これにより、データセット丸ごと復元する必要がない。
- 特定の期間にデータセットのコピーを作成します。データ破損のイベントが、ポイントインタイム クエリでキャプチャできる期間（7 日以上前など）を超えた場合に、そのコピーを使用できます。また、データセットをあるリージョンから別のリージョンへコピーして、リージョンのエラーの際にデータの可用性を確保することもできます。
- 元のデータを Cloud Storage に保存します。これにより、新しいテーブルを作成して、破損していないデータを再読み込みできます。そこから、新しいテーブルを指すようにアプリケーションを調整できます。
パフォーマンス
- クエリ実行はストリーミングインサートの後、レイテンシーを考慮してそれよりも長い時間待った後に行う必要があります。ストリーミングインサート後のデータ可用性の平均レイテンシーを推定し、常に2倍の時間を待ってからクエリを実行する
- パーティショニング・クラスタ化により、WHERE句を用いたクエリのパフォーマンスを向上させることができる
- 大量のデータを日々更新する場合は、BigQuery UPDATEよりもAPPENDの方がパフォーマンスに優れています
BigQueryのレガシーSQL
TABLE_DATE_RANGE関数
timestamp1 と timestamp2 の間の時間範囲と重なる日次テーブルに対してクエリを実行します。 テーブル名のサフィックスに日付（YYYYMMDD形式）がついている必要があります。
TABLE_DATE_RANGE([myproject-1234:mydata.table_prefix_], TIMESTAMP('2014-03-25'), TIMESTAMP('2014-03-27'))
非正規化
非正規化により、クエリの速度が向上し、クエリがシンプルになる
リージョン/マルチリージョン
BigQuery は次の 2 種類のロケーションを使用します。
- リージョンは、ロンドンなどの特定の地理的な場所となります。
- マルチリージョンは、米国などの、2 つ以上の地理的な場所を含む広い地理的なエリアとなります。
CSV読み込み時の注意
CSV ファイルを BigQuery に読み込む場合は、次の点に注意してください。
CSV ファイルはネストされたデータや繰り返しデータに対応していません。
バイト オーダー マーク（BOM）文字を削除する。予期しない問題が発生する可能性があります。
gzip 圧縮を使用した場合、BigQuery はデータを並列で読み取ることができません。圧縮された CSV データを BigQuery に読み込む場合は、圧縮されていないデータを読み込むよりも時間がかかります。圧縮データと非圧縮データを読み込むをご覧ください。
同じ読み込みジョブに圧縮ファイルと非圧縮ファイルの両方を含めることはできません。
gzip ファイルの最大サイズは 4 GB です。
JSON または CSV データを読み込む場合、TIMESTAMP 列のタイムスタンプ値の日付部分の区切りにはダッシュ（-）を使用し、日付は YYYY-MM-DD（年-月-日）の形式にする必要があります。タイムスタンプの時間部分 hh:mm:ss（時-分-秒）には、区切りとしてコロン（:）を使用する。
クォータを超過することなく大規模なレコードの更新する
https://cloud.google.com/blog/products/bigquery/performing-large-scale-mutations-in-bigquery
- クォータとは、クラウドプロジェクトが使用できる特定の共有 Google Cloud リソースの量を制限するもので、ハードウェア、ソフトウェア、ネットワークコンポーネントなどが含まれます。
- 今回のケースでは、UPDATE文によってこの問題が発生しているため、その他の方法を用いてこの上限に到達しないようにデータをインポートする必要があります。
- Google Cloudが推奨するBigQueryへのインポートの方法は、次のBigQueryのMERGEステートメントを使用して、別のテーブル（新着情報が保管されている）の内容に基づいて既存テーブルのバッチ更新を実行する方法です。
MERGE dataset.Inventory T USING dataset.NewArrivals S ON T.ProductID = S.ProductID WHEN MATCHED THEN UPDATE SET quantity = T.quantity + S.quantity -- 既にプロダクトが存在する場合は、在庫を追加 WHEN NOT MATCHED THEN INSERT (ProductID, quantity) VALUES (ProductID, quantity) -- プロダクトが存在しない場合は、新プロダクトを挿入
メトリクス
- slots/allocated_for_project
- プロジェクト内のクエリジョブに現在割り当てられているBigQueryスロットの数を確認することができます。
BigQuery Reservationsによる優先度付け
- 定額制(BigQuery Reservations)は、複数の事業部門があり、優先順位や予算が異なるワークロードを抱える大企業に特に適しています。
- 一定数のスロットがお客様のプロジェクトに割り当てられ、プロジェクト間で階層的な優先順位モデルを確立することができます
→ たぶん“予約”のことだと思われる。
Cloud Pub/Sub
- Cloud Pub/Subのプッシュに対して、確認応答期限内にメッセージを確認しないと、Pub/Sub によってメッセージが再送信され、その結果重複するメッセージが送信される
- 確認応答メッセージオペレーション指標のresponse_codeラベルで、expiredとなっているのが確認応答期限切れのメッセージ
Cloud Spanner
セカンダリインデックス
Cloud Spanner により、テーブルの主キーごとに自動的にインデックスが作成されます。たとえば、Singersテーブルの主キーである SingerId は自動的にインデックスに登録されるため、操作は必要はありません。
Cloud Spannerは、他の列をセカンダリ インデックスにすることもできます。
セカンダリ インデックスは、ルックアップを使用することで得られるメリットに加えて、Cloud Spanner でより効率的にスキャンを実行し、全テーブル スキャンではなくインデックス スキャンを行うこともできます。
セカンダリ インデックスを列に追加すると、その列のデータをより効率的に検索できるようになります。
たとえば、特定の範囲の LastName 値に対して SingerId のセットをすばやく検索する必要がある場合は、Cloud Spanner でテーブル全体をスキャンしなくてもいいように、LastName にセカンダリ インデックスを作成します。
CREATE INDEX SingersByLastName ON Singers(LastName)
https://cloud.google.com/spanner/docs/secondary-indexes
- ホットスポットの回避
Cloud Storage
大量に細かいファイルがある場合のアップロード
- 複数のファイルをTARファイルにまとめる
- または、
gsutil -mで並行して複数のファイルをGCSに転送する
ただし、一部のファイルのダウンロードが失敗していても、gsutil ではどのファイルが正常にダウンロードされたかを追跡しない
Cloud SQL
HA構成
あるゾーンにCloud SQLインスタンスを作成し、同じリージョン内の別のゾーンにフェイルオーバーレプリカを作成する https://cloud.google.com/sql/docs/mysql/high-availability#normal
Compute Engine インスタンス
https://cloud.google.com/tpu/docs/tpus#when_to_use_tpus
CPU
- 最大限の柔軟性を必要とする迅速なプロトタイピング
- トレーニングに時間がかからない単純なモデル
- 実際のバッチサイズが小さい小規模なモデル
- C++ で記述されたカスタム TensorFlow 演算が多くを占めるモデル
- ホストシステムの使用可能な I/O またはネットワーク帯域幅によって制限が課せられるモデル
- ソースが存在しないモデルまたはソースを変更するのが煩雑すぎるモデル
- CPU 上で少なくとも部分的に実行しなければならない多数のカスタム TensorFlow 演算を使用するモデル
- Cloud TPU で利用できない TensorFlow 演算を使用するモデル（利用可能な TensorFlow 演算のリストをご覧ください）
- 実際のバッチサイズが大きい中～大規模なモデル
TPU
- 行列計算が多くを占めるモデル
- メインのトレーニング ループ内にカスタム TensorFlow 演算がないモデル
- トレーニングに数週間または数か月かかるモデル
- 実際のバッチサイズが非常に大きい非常に大規模なモデル
DataProc
- MySQLのダンプファイルをCloud Storageに保存することで、Cloud SQL にマウントしてDataprocにインポートをすることが可能（たぶん、Dataproc内のCloud SQLにマウントするという意味だと思われる💦）
- HDFSではなくGCSに保存しておくと、クラスタを削除した後もデータが維持される
- 永続ディスクとして、HDFSの代わりにGCSを使用するのがコスト最適
- 永続ストレージとして、ソリッド ステート ドライブ（SSD）とハードディスク ドライブ（HDD）のどちらにするかを指定します。SSD ストレージは、ほとんどのユースケースで最も効率的でコスト効果の高い選択肢です。HDD ストレージは、非常に大きいデータセット（10 TB 超）で、レイテンシがあまり重要でない場合やアクセス頻度が低い場合に適切であることがあります。
- Dataprocの起動時に初期化アクションが行われ、依存関係が追加される。セキュリティポリシー上、インターネットにアクセスできない場合には、GitHub リポジトリやCloud Storage に依存関係をコピーしておく
- SparkジョブでParquetファイルを使用する場合、ファイルサイズの目安は1GBと言われています。Parquetサイズが200~400MBだと小さいです。最小1GBになるようにします。
Dialogflow
Datastore
- 結果が「すべて成功」と「何も起こらない」のどちらかになるオペレーションが実行できる
- Datastore は、大規模な構造化データに対して可用性の高いアクセスを必要とするアプリケーションに最適です。Datastore は、次のようなタイプのすべてのデータを保存、クエリする目的で使用できます。
- 小売店向けにリアルタイムな在庫と商品の詳細を提供する商品カタログ
- ユーザーの過去の行動と好みに応じてカスタマイズされたエクスペリエンスを提供するユーザープロフィール
- ある銀行口座から別の口座への送金など、ACID プロパティに基づくトランザクション
https://cloud.google.com/datastore/docs/concepts/overview#what_its_good_for
Data Loss Prevention API (DLP)
ユースケース：
Pub/Subトピックを読み取ってCloud Data Loss Prevention APIに渡すようCloud Functionを構築する。DLPによるタグ付けと信頼度を使用して、Cloud Functionがバケットにデータを渡すか、隔離するかを判定する。
Dataflow
Apache Beam
サイドインプット
- Apache Beamでは、データ分析のためのエンリッチメントを行う際には、サイドインプットパターンが推奨されています。https://beam.apache.org/documentation/patterns/side-inputs/
Apache Beam入門
- Apache Beamでは、データ分析のためのエンリッチメントを行う際には、サイドインプットパターンが推奨されています。https://beam.apache.org/documentation/patterns/side-inputs/
監視
ユースケース：
Cloud Pub/SubからDataflowでCloud Storageに集約する場合に以下のメトリクスを監視する
- 送信元のSubscription/num_undelivered_messagesの増加
- 送信先の使用済みストレージのの増加率の減少
ウィンドウ
- タイムスタンプに従って、Pcollectionを分割することをウィンドウ化と呼ぶ。GroupByKeyといった複数のエレメントを集約する変換は暗黙的にウィンドウベースで行われる。
- ストリーミングデータのように新しいエレメントが定常的に追加され続けるデータセット、つまりUnbounded PCollectionの場合に、ウィンドウは役立つ。
- Apache Beamのデフォルトでは、PCollectionの全エレメントに対して１つのウィンドウのみが割り当てられる。これをグローバルウィンドウと呼ぶ。たとえ、ストリーミングデータの場合でも、グローバルウィンドウは後から入ってきたデータを無視する。ストリーミングデータのようにUnbounded PCollectionの場合には、非グローバルウィンドウ関数を設定する必要がある。もし、非グローバルウィンドウ関数の設定なしでUnbounded PCollectionにGroupByKeyを適用する場合、IllegalStateExceptionエラーを出す。
- たとえば、5分間ウィンドウ（または30秒ごとの4分間スライディングウィンドウ）をPCollectionのすべてのエレメントに適用していく。これが非グローバルウィンドウ。
https://beam.apache.org/documentation/programming-guide/#windowing
ウィンドウの種類
- タンブリング ウィンドウ（Apache Beam では固定ウィンドウ）
- ホッピング ウィンドウ（Apache Beam ではスライディング ウィンドウ）
- セッション ウィンドウ
パイプラインの更新
Dataflowジョブは２つの方法で停止することができる。 ストリーミング パイプラインの停止時にデータの消失を防ぐには、ジョブのドレインが最適な方法。
キャンセル
ストリーミング パイプラインとバッチ パイプラインの両方に適用可能。
ジョブをキャンセルすると、Dataflow サービスはバッファデータなどのデータの処理を停止。ドレイン
ストリーミング パイプラインにのみ適用可能。
ジョブをドレインすると、Dataflow サービスはバッファ内のデータの処理を完了すると同時に、新しいデータの取り込みを中止できる
https://cloud.google.com/dataflow/docs/guides/stopping-a-pipeline#drain
GUIDによる重複排除
- 送信側で、各データエントリにGUIDを割り当てる
- 受信側で、既知のGUIDだった場合には受信したエントリを破棄する
- これにより、複数回同じレコードが送信されたとしても重複排除できる
InsertIDによる重複排除
挿入された行に対して insertId を指定した場合、BigQuery はこの ID を使用して、ベスト エフォート型の重複排除を最大 1 分間サポートします。つまり、その期間内に同じ insertId の同じ行を同じテーブルに複数回ストリーミングしようとすると、BigQuery はその行の複数のオカレンスを重複排除して、それらのオカレンスの一つだけを保持する可能性があります。
このシステムでは、同じ insertId が指定された行も同一のものであると想定されます。2 つの行が同じ insertId を持つ場合、どちらの行を BigQuery が保持するかは非決定的になります。
ストリーミングの実行後に重複行が残らないようにするには、次の手動プロセスを使用する。
- テーブル スキーマ内の列として
insertIdを追加し、各行のデータにinsertId値を含める - ストリーミングが停止した後に、クエリを実行して重複をチェックする
#standardSQL SELECT * EXCEPT(row_number) FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY ID_COLUMN) row_number FROM `TABLE_NAME` ) WHERE row_number = 1
SQL解説
- ROW_NUMBER() OVER (PARTITION BY ID_COLUMN) row_number
同じInsertIdをもつレコードのグループ（パーティション）に対して、行ごとに連番を振っている。参考
- 同じID_COLUMN値を持つパーティション内で、行番号が1のものを取り出す。これで重複が削除された
- SELECT * EXCEPT(row_number)
最後にrow_number列を宛先テーブルから除外する。
例外処理
- Dataflowでは、パイプラインコードのDoFnに try … catchブロックを追加することで例外をキャッチできる
- 例外がキャッチされた際は、詳細なエラー分析が必要になるため、sideOutputを用いてPCollectionを作成することが有効。PCollectionに保存した後は、Pub/Subに改めて保存することも可能なため、失敗データの再処理できる
- 失敗した要素を追跡することもできる
- 失敗した要素をログに記録し、Cloud Logging を使用して出力をチェックできます
- ログの表示の手順に沿って、Dataflow ワーカーログとワーカー起動ログで警告やエラーを確認できます
- 失敗した要素を ParDo で追加出力に書き込み、後で調査できます
コード例
BigQueryIO.read.from()は、BigQueryからテーブル全体を直接読み取ります。
BigQueryIO.read.fromQuery() は、クエリを実行し、クエリ実行後に受け取った結果を読み込みます。
間違ったフォーマットや破損している行の処理
Google Cloudが推奨するより良い方法としては、デッドレター キュー（またはデッドレター ファイル）と呼ばれるパターンを使用することです。
DoFn.ProcessElement メソッドで例外をキャッチして、エラーを通常どおりにロギングする。
ただし、失敗した要素をドロップする代わりに、分岐出力を使用して、失敗した要素を個別の PCollection オブジェクトに書き込みます。
その後、これらの要素はデータシンクに書き込まれ、別の変換を使用して、後で検査や処理を行うことができます。
Kafka
Google Cloud上でKafkaクラスタを展開する際は、VMインスタンスの使用が最適。
Logging
- ログフィルターを使用して、特定のBigQueryテーブルに関連するログのみをフィルタリングし、ログルーティングシンクをCloud Pub/Subに設定できる。これにより、INSERTにより特定のテーブルにデータが追加されたときに、通知を送信できる
ログルーティングについて - 監査ログを有効にすると、セキュリティ、監査、コンプライアンス エンティティが Google Cloud のデータとシステムをモニタリングして、脆弱性や外部データの不正使用（ポリシー違反）の可能性を確認できる
- データアクセスログの保護
Monitoring
- VMインスタンスにMariaDBのSQLデータベースを導入した場合
- Cloud Monitoringでは、ネットワーク接続、ディスクID、レプリケーションの状態などのカスタムメトリクスはデフォルトで収集することができない
- その場合、OpenCensusを使ったカスタムメトリクスの収集が推奨される
- 無料のオープンソース プロジェクト
- メトリクスおよびトレースデータをさまざまな言語で収集するための、ベンダーに依存しないサポートを提供できます。
- 収集したデータを、Cloud Monitoring を含むさまざまなバックエンド アプリケーションにエクスポートできます。
Natural Language API
- エンティティ分析を使用し、ドキュメントに題名ラベルを付ける
- センチメント分析により、ドキュメントに感情ラベルをつける
Video Intelligence API
- LABEL_DETECTION 機能を使用して動画映像に表示されるエンティティを識別し、それらのエンティティにラベル（タグ）でアノテーションを付けることができます。
- この機能は、物体、場所、活動、動物の種類、商品などを識別できます。
- オブジェクト トラッキングとは異なり、ラベル検出ではフレーム全体（境界ボックスなし）にラベルを付けます。
- たとえば、踏切を通過する列車の動画では、「train」、「transportation」、「railroad crossing」などのラベルが返されます。
- 各ラベルには時間セグメントがあり、エンティティが検出された時点を、動画の先頭からの時間オフセット（タイムスタンプ）として示す
機械学習
ファッション
サブサンプル
サブサンプリングとは主に不均衡データに対して用いられるデータ処理手法で、特定のクラスのデータから新しいサブセットを生成する処理です。これによって、特定のクラスのデータセットが減少し、学習パフォーマンスが向上する。
その他DB
数百TB規模のNoSQLデータベースだったらこいつら
- HBase
- MongoDB
- Cassandra
HBase
- Googleのビッグテーブルに似たNoSQLデータベース
- 膨大な量の構造化データへの迅速なランダムアクセスを実現するために設計された
MongoDB Atlas
- Google のグローバルにスケーラブルで信頼性の高いインフラストラクチャ上で、フルマネージド サービスを提供
- Atlas を使用すると、UI を数回クリックするか API 呼び出しを実行するだけでデータベースを簡単に管理できる
- 移行は簡単で、グローバル クラスタなどの高度な機能を備え、世界中のどこにいても低レイテンシの読み取りおよび書き込みアクセスが可能
- オープンソースのNoSQL分散型データベースで、パフォーマンスを損なうことなく拡張性と高可用性を実現できる
- コモディティ・ハードウェアやクラウド・インフラ上で直線的なスケーラビリティと実証済みのフォールトトレランスを実現し、ミッションクリティカルなデータに最適なプラットフォーム
その他ツール
Pig / Pig Latin
Pigは大規模なデータセットを分析するためのプラットフォームです。
Hadoop上に構築されており、プログラミングの容易さ、最適化の機会、拡張性を提供する。
Pig Latinはリレーショナルデータフロー言語であり、Pigのコアなコンポーネントの1つです。
データパイプラインの構築の際には、いくつかの理由からSQLよりもPig Latinの方がより優れた選択になります。
Pig Latinでは、パイプラインの開発者が、パイプラインのどこにデータをチェックポイントするか決めることができます。
Pig Latinはパイプラインの分割をサポートする。
Pig Latinでは、開発者がデータパイプラインのほとんどどこにでも独自のコードを挿入することができます。
DB一般
自己結合ｓ
自己結合とは同じテーブル同士の結合のことをいいます。 結合は 2つ以上のテーブルに対して行われますが、それらが別のテーブルである必要はありません。 自己結合は 2つのまったく同じテーブルの結合として実行されます。
DBサービス
- 常に生成されて書き込まれる時系列データ → Cloud Bigtable
PDEワークショップ
Dataproc 分析とデータ処理でDataprocクラスタを個別に作成するのがベストプラクティス エフェメラルクラスタを作成することで、ジョブ終了時に削除 GCSへの接続はGCSコネクタを利用する
Bigtable ワイドカラムNo SQL（ワイドカラムストア型： キーバリュー型のバリュー部分が、さらに任意の数のキーバリューの集合（列名と値）になったような構造） HBase互換性 Bigtable cbtツールで外れ値を見つける IoTの時系列データが得意
DataprocとBigQueryの連携 BigQuerコネクタを使用することで読み書きアクセス可能
CloudSpanner トラヒックの急増→ストレージ使用量ではなく、CPUリソースが枯渇するので、CPU使用率をモニタリングする 手動スケール：コンソール上で設定 自動スケール：コーディングが必要
Cloud SQLは水平方向にスケールしない
GCPだとDBのことをストレージと呼んだりする。
Cloud Spannerではデフォルトだとプライマリキー以外で検索すると、全件検索するため時間がかかる 検索したいカラムに対して、セカンダリインデックスを作成し、索引を作ることで検索を早くすることができる。 Dataproc 分析とデータ処理でDataprocクラスタを個別に作成するのがベストプラクティス エフェメラルクラスタを作成することで、ジョブ終了時に削除 GCSへの接続はGCSコネクタを利用する
Bigtable ワイドカラムNo SQL（ワイドカラムストア型： キーバリュー型のバリュー部分が、さらに任意の数のキーバリューの集合（列名と値）になったような構造） HBase互換性 Bigtable cbtツールで外れ値を見つける IoTの時系列データが得意
DataprocとBigQueryの連携 BigQuerコネクタを使用することで読み書きアクセス可能
CloudSpanner
スケールアップではなく、スケールアウトできる
トラヒックの急増→ストレージ使用量ではなく、CPUリソースが枯渇するので、CPU使用率をモニタリングする
- 手動スケールアウト：コンソール上で設定
- 自動スケールアウト：コーディングが必要
Cloud SQL
Cloud SQLは水平方向にスケールしない あくまで縦方向のスケールのみ（スケールアップのみ） スケールアップ時にはサービスが停止する
GCPにおける「ストレージ」という呼称
GCPだとDBのことをストレージと呼んだりする。
Cloud Spannerのセカンダリインデックス
Cloud Spannerではデフォルトだとプライマリキー以外で検索すると、全件検索するため時間がかかる 検索したいカラムに対して、セカンダリインデックスを作成し、索引を作ることで検索を早くすることができる。
Bigtableにおける行キーの設計
BigQueryのワイルドカードテーブル
テーブル名にワイルドカードを使用する（テーブル名プレフィックス+アスタリスク）ことで、複数のテーブルに対してクエリを実行できる
<project名>.<Dataset名>.<テーブル名プレフィックス>*
