GCP Cloud Spanner メモ

GCP

はじめに

GCPのACEの模擬試験問題を確認していると、Spannerの細かな部分まで問われる印象を感じた。
少なくとも、ドキュメントのコンセプトと入門ガイドは抑える必要があるように感じた。

https://cloud.google.com/spanner/docs/concepts?hl=ja
https://cloud.google.com/spanner/docs/how-to?hl=ja

勉強都度に追記するページなので、未完成。

コンセプト

レプリケーション

レプリケーション  |  Cloud Spanner  |  Google Cloud

レプリケーションの利点

  • データの可用性
  • 地理的な局所性
  • 単一のデータベースエクスペリエンス
  • アプリケーション開発の省力化

といったキーワードをおさえておく。

レプリカには以下の3種類があり、それぞれの特徴を押さえておく必要がある。

項目内容
読み書きレプリカ読み書きレプリカは、読み取りと書き込みの両方をサポートします
読み取り専用レプリカ読み取り専用レプリカは読み取りをサポートします(書き込みはサポートしません)
ウィットネスレプリカ読み取りをサポートしませんが、書き込みの commit を決める投票に参加します。

ウィットネスの投票については分散トランザクションについて理解が必要。
分散トランザクションでは複数のDBに対して分散してコミット処理を行う。
その際に、全体としての一貫性を確認するため、各DBにあらかじめcommitが問題ないかを確認する必要がある。
各データベースに対してコミットが問題ないかを確認する処理を投票と呼ぶ。

ウィットネスはcommit時の投票のみをサポートするレプリカ。


インスタンス

インスタンス  |  Cloud Spanner  |  Google Cloud

Spannerは複数のノードから構成される。
ノードは単一リージョンか、マルチリージョンかで構成が異なる。

以下は単一リージョンとマルチリージョンを比較した際の図。

項目内容
インスタンスSpannerの全体。
インスタンスはリージョン毎に設置されたレプリカから構成される。
単一リージョン構成の場合、単一リージョン内の複数ゾーンにレプリカが作成される。
マルチリージョンの場合、レプリカが別リージョンに設置される。
ノードSpannerのクエリをさばく計算部分。
1台のコンピュートと考えればよい。
ノード数が増えれば、インスタンスとして利用可能なCPU、RAMが増える。
ノード数はレプリカあたりのノード数を意味する。
そのため、ノード数を1増やすと、全体としてはレプリカ数*1増える。
(デフォルトだと単一リージョンは3レプリカなので、3ノード増える)
レプリカデータベースとしての1個のまとまり。
指定したノード数で構成される。
データベースとしての1個のまとまりが、複数のゾーンもしくはリージョンに分散され、
冗長構成を保つ構成となっている。
Spanner 構成要素

どのリージョン構成についても、Cloud Spanner によって 3 つの読み取り / 書き込みレプリカが維持されます。それぞれのレプリカは、そのリージョン内の異なる Google Cloud ゾーンに維持されます。各レプリカには本番環境のデータベースの完全なコピーが含まれ、読み取り / 書き込みリクエストと読み取り専用リクエストを実行できます。Cloud Spanner は、異なるゾーンのレプリカを使用し、1 つのゾーンで障害が発生しても、データベースの可用性を維持します。

https://cloud.google.com/spanner/docs/instances?hl=ja

マルチリージョンインスタンスの利点

  • 99.999% の可用性
  • データの分散
  • 外部整合性

マルチリージョン構成の概要
マルチリージョンの構成は基本的には決まっている。
asia1の構成を選択すると、東京大阪の構成になるし、nam6を選択すると、
us-central1,us-east1,us-west1,-us-west2の構成になる。

なんで好きなリージョンを選ばせてくれないのか。
→分散処理を実施するにあたり距離的な制約が処理スピードにかかわるので、
 標準で距離が近いリージョンで構成が組まれる。

7

マルチリージョン構成では最小ではasia1のような構成となる。
各マルチリージョン構成には 2 つの読み取り / 書き込みリージョンが存在し、それぞれのリージョンに 2 つの読み取り / 書き込みレプリカが含まれます。
これらの読み取り / 書き込みリージョンの 1 つがデフォルトのリーダー リージョンになります。

基本的にはリーダーリージョン内のレプリカのどちらかがリーダーレプリカとなる。
リーダーリージョンの全レプリカが死んだ場合、2つめのリージョンが選択される場合もある。


スキーマとデータモデル

スキーマとデータモデル  |  Cloud Spanner  |  Google Cloud

これを理解するにはデータベースの知識もないといけないと思われる。(しんどい)
なので、勉強に参考したサイトを記載しておく。

初心者向けにもすごいわかりやすかった

親子テーブル関係

超初心者向け・SQLでの親テーブル・子テーブルの考え方 - Qiita
前提 Qiita初投稿です! ここでは 「親テーブルと子テーブル、どっちがどっちか分からん…」 「SQL文書いてて訳分かんなくなった!」 という人向けに、その考え方を超簡単に説明します。 今回はmacOSのterminalを使っ...
【SQL入門】外部キーとは?主キーとの関係や作成方法について解説 | 侍エンジニアブログ
こんにちは!システムエンジニアのオオイシです。 SQLの外部キー(FOREIGN KEY)をご存知ですか。外部キーの使いかたを覚えると、関連するテーブル間の整合性をデータベースに保証させることが可能です。 この記事では、 外部キーとは? 外部キーの役割について理解しよう 外部キーを作成してみよう といった、基本的な解説...

インターリーブ

Cloud Spanner でインターリーブテーブルを高速に取得する
本記事ではインターリーブテーブルを使いこなす、ちょっとしたテクニックを紹介します。

Spannerのスキーマの制約についてはこちらのサイトがわかりやすかった。

Cloud Spannerの概要と設計上の要点など - Qiita
Advent Calendarへの参加は、というかQiitaへの投稿自体が初めてなので緊張します。 本記事ではCloud Spannerについての概説と設計上の要点などをまとめてみました。技術的な解説というよりは実設計レベルの話を中心...

スキーマ設計のベストプラクティス

基本的に、書き込みが特定のノードに偏らないように主キーを設計する必要がある。

NGな設計

書き込みレートが高いテーブルで、値が単調に増加または減少する列をキーの最初の部分として選択しないでください。

OKな設計

  • キーの順序を入れ替える
  • 一意キーのハッシュを作成して、論理シャード間に書き込みを分散する
  • Universally Unique Identifier(UUID)を使用する

入門ガイド

テスト

コメント

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