Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[GKE & Spanner 勉強会] Cloud Spanner の技術概要

2,020 views

Published on

2020 年 1 月 21 日開催 GKE & Cloud Spanner 勉強会【基礎編】
セッション:Cloud Spanner の技術概要
講師:サミール ハムディ
   ゲーム ソリューション アーキテクト

Published in: Technology
  • Be the first to comment

[GKE & Spanner 勉強会] Cloud Spanner の技術概要

  1. 1. GKE & Spanner 勉強会 【基礎編】 2020.01.21 #gke_spanner
  2. 2. Cloud Spanner の技術概要 サミール ハムディ ゲーム ソリューション アーキテクト #gke_spanner
  3. 3. NewSQL とは? リレーショナルデー タベース構造 水平方向の スケーラビリティ +
  4. 4. データベース ポートフォリオ Cloud Storage Cloud Memorystore BigQuery Object storage, data lake Managed Redis Cloud Datastore / Cloud Firestore Serverless scalable document store Cloud Bigtable Low latency, scalable wide column store Cloud SQL Managed MySQL & PostgreSQL Cloud Spanner Scalable mission-critical RDBMS Enterprise data warehouse
  5. 5. Cloud Spanner: the best of RDBMS + NoSQL
  6. 6. Cloud Spanner とは? Google のマネージド・スケーラブル・リレーショナルデータベース・サービス 完全マネージドのグローバルスケールで DB サービス1 2 3 4 ゾーン間・リージョン間の自動 synchronous レプリケーション スキーマ、ACID トランザクション、SQL Google内部では、既に7年以上の運用経験 (AdWords, Google Play…)
  7. 7. Cloud Spanner の キーコンセプト
  8. 8. リージョナル&マルチリージョン構成 Asia Pacific Americas Europe, Middle East, & Africa Tokyo Taiwan Mumbai Singapore Current regions Netherlands Finland Belgium Los Angeles Iowa N. Virginia S. Carolina MontrealOregon
  9. 9. シングルリージョン Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2 ● 1ノードごとに 3 つのレプリカ
  10. 10. マルチリージョン Zone A RW - Replica US region 1 (Default Leader) Zone B RW - Replica Zone A RW - Replica US region 2 Zone B RW - Replica Zone A Witness US region 3 (Witness) Write Quorum (US) Asia Region Europe Region Zone A RO - Replica Europe region 1 Zone B RO - Replica Zone A RO - Replica Asia region 1 Zone B RO - Replica ● 例えばこの 3 大陸の構成では 9 つのレプリカ ※ us-central2 はプライベート GCP リージョンです
  11. 11. SLA シングルリージョン (SR) 99.99% マルチリージョン (MR) 99.999%
  12. 12. Cloud Spanner の時刻同期(TrueTime API) US Datacenter EU Datacenter Time MastersTime Masters 時刻同期 時刻同期 原子時計 原子時計 GPS受信機 GPS受信機 Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Time Masters Armageddon Masters GPS Masters
  13. 13. 同期レプリケーションと強整合性 Data is synchronously replicated using Paxos consensus. Update Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2
  14. 14. Split はデータが格納される単位 ゾーン 1 Node1 Node2 Node3 Split Split Split Split Split Split ゾーン 2 Node1 Node2 Node3 Split Split Split Split Split Split ゾーン 3 Node1 Node2 Node3 Split Split Split Split Split Split
  15. 15. Split とは? ● テーブルは主キーでソートされる ● テーブルはキー範囲で分割される ● Split は負荷とサイズに応じて 分割される
  16. 16. Split のレプリケーション ゾーン 1 Node1 Node2 Split ( a ~ f ) Split ( g ~ k) Split ( l ~ s) Split ( t ~ z ) ゾーン 2 Node1 Node2 ゾーン 3 Node1 Node2 Split ( a ~ f ) Split ( g ~ k) Split ( a ~ f ) Split ( g ~ k) Split ( l ~ s) Split ( t ~ z ) Split ( l ~ s) Split ( t ~ z ) Paxos グループ
  17. 17. Cloud Spanner のスキーマ & データモデル プライマリキー(PK) ○ 各テーブルに PK が必須 ○ PK は 1 つか複数のカラムでもOK ○ ルートテーブル以外の子テーブルはその親を 含む祖先テーブルのPK を必ず持つ ○ 子テーブルの PK は、親テーブルの PK と同 じ順を持つ CREATE TABLE Users ( UserId STRING(36) NOT NULL, LastAccess TIMESTAMP, Point INT64, StartDate DATE, UserName STRING(100), ) PRIMARY KEY (UserId) TIPS:Auto-increment は HOTSPOT になるので、PK には UUIDv4 にしよう!
  18. 18. Hotspot とは?
  19. 19. Cloud Spanner のスキーマ & データモデル インターリーブ ( 親子関係 ) ○ データベースには複数のテーブルを 定義できる ○ データを物理的にコロケーションした い場合 ○ 最大で 7 階層まで CREATE TABLE UserItems ( UserId STRING(36) NOT NULL, ItemId STRING(36) NOT NULL, Num INT64 NOT NULL, ) PRIMARY KEY (UserId, ItemId), INTERLEAVE IN PARENT Users ON DELETE CASCADE
  20. 20. インターリーブした場合のデータのロケーション インターリーブした場合インターリーブしない場合
  21. 21. セカンダリインデックス ○ インデックスに保持される値 ■ 定義した値 ■ 元テーブルの主キー ■ STORING に定義した値。 ○ インターリーブが可能。 ○ STORING 句を使うことで、定義したデータをイ ンデックスに含めることが可能。 CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId,), INTERLEAVE IN Albums Cloud Spanner のスキーマ & データモデル TIPS:Cloud Spanenr でインデックスもテーブルなので、 HOTSPOT が発生する可能性があるので注意!
  22. 22. Cloud Spanner の トランザクション
  23. 23. Cloud Spanner のトランザクションと処理の方法 ● 読み書きトランザクション 1 つ以上の読み取り結果に応じて書き込みを 行う必要がある場合、読み書きトランザクショ ンの中で読み書きを実行する必要がありま す。 ● 読み取り専用トランザクション データの一貫したビューを取得するために、 複数の読み取り呼び出しを行う場合、読み取 り専用トランザクションの中で読み取りを実行 する必要があります。 Read A Write A commit Read A Read B
  24. 24. Cloud Spanner におけるデータの書き込みとロック ● 事前にデータの読み取りせずに、書き込みを行う場合 ○ ライター共有的ロックと呼ばれる共有的ロックを用いる。 ○ コミットタイムスタンプの順に順序が決定される。 ● 読み書きトランザクション ○ 読み書きトランザクションを利用する場合、データを読み取るタイミングでは共 有ロックが行われる。実際に書き込みを行う際に、排他的ロックを取得し書き 込みを行う。
  25. 25. トランザクションを必要としない読み取り ● Strong Read ○ 現在のタイムスタンプでの読み取りであり、この読み取り処理の開始時までに commit されたすべてのデータを確実に確認できます。Cloud Spanner のデフォルト では、Strong Read を使用して読み取りリクエストが処理されます。 ● Steal Read ○ 過去のタイムスタンプによる読み取りです。レイテンシの影響を受けやすいものの古 いデータは許容できるアプリケーションの場合、Steal Read を使用するとパフォーマ ンスが向上することがあります。
  26. 26. Cloud Spanner のトランザクション t RW-Txn1 RW-Txn2 Read A Write A commit Read B Read A Write A commit C1 C2 RW-Txn2 の Read A のタイミングでは、既にRW-Txn1 のコミットが行われているため、Read A では RW-Txn1 で書き込まれたデータを読み取ることができる。
  27. 27. Cloud Spanner のトランザクション t RW-Txn1 RW-Txn2 Read A Write A commit Read A Write A commit C1 C2 トランザクションが競合する場合、後から開始されたトランザクション(RW-Txn2)で Abort され る。 Abort の発生
  28. 28. Cloud Spanner のトランザクション t RW-Txn1 RO-Txn2 Read A Write A commit Read A Read A C1 R2R1 RO-Txn2 はロックを取らず、過去のコミット履歴のプレフィックスを監視し、Read A が発生し たタイミングと同じデータを読み続ける。そのため、RO-Txn2 は RW-Txn1 の Write A の影響 を受けない。
  29. 29. データの書き込みの方法 ● DML トランザクション内で処理を実行します。 ● Mutation API トランザクションを利用した書き込み、Blind write の両方が利用可能。 Insert_or_update などの Mutation にしかない存在しないAPI があります。 ● 注意事項 同一のトランザクション内でDML と Mutation API を同時に指定しない。 処理が実行されるタイミングが異なっており、DML が先に実行されます。
  30. 30. データ更新後のデータの読み取りについて Mutation を利用する場合 トランザクションの開始 1.データ A の検索 2.データ A を B に変更 3.データ B の検索 トランザクションの完了 ● 「3.データ B の検索」を実行したタイミングで は、更新後のデータを検索することができな い。 ● トランザクションの完了後( Commit が完了 した後 ) で再度検索を行う必要がある。 ● Cloud Spanner クライアントが変更の 状態を内部に保存し、Commit の タイミングで Mutation をサーバに 送信する。
  31. 31. DML を利用する場合 トランザクションの開始 データ A の検索 データ A を B に変更 データ B の検索 トランザクションの完了 ● 「3.データ B の検索」を実行したタイミングで は、更新後のデータを検索することが可能。 ● DML の場合には、サーバサイドで変更状態 をバッファリングするため、コミットする前の データを同一トランザクション内で参照するこ とが可能。 データ更新後のデータの読み取りについて
  32. 32. トランザクション処理と利用ケース ● トランザクションを必要としない読み取り ○ 単一のデータ読み取り ○ 複数回データを読み取る際に、一貫性を必要としない場合 ● トランザクションを必要としない書き込み ○ 単一行の書き込み ● パーティション化DML ○ データの一括更新、削除など、トランザクションの制限を超えて処理を実行したい場合 ● 読み書きトランザクション ○ データの読み込みの結果に応じて書き込みを実行する場合 ● 読み取り専用トランザクション ○ 複数のデータの読み取りで一貫したビューが必要となる場合
  33. 33. Cloud Spanner の利用方法 ● Google Cloud Console ● gcloud CLI ● gRPC API ○ Cloud Spanner Client Library for Go ○ Cloud Spanner Client Library for Java ○ Cloud Spanner Client Library for Node.js ○ Cloud Spanner Client Library for Python ○ Cloud Spanner Client Library for PHP ○ Cloud Spanner Client Library for Ruby ○ Cloud Spanner Client Library for C# ○ Cloud Spanner Client Library for C++ (Beta) ● REST API ● JDBC driver (Google + 3rd party)
  34. 34. Cloud Spanner のデモ

×