Google Cloud Spanner FAQ

Google Cloud Spannerをまだあまり知らない人向けに、FAQを軸にして概要とTipsを発表しました。
https://docs.google.com/presentation/d/1baCbSRJupSOrXgkOXgxODPzu3FyKotyQLnLRHLfyDmc/edit#slide=id.p

Transcript

1. Cloud Spanner FAQ @pchatsu 1
2. What’s Cloud Spanner ? • Google Cloud PlatformのRDB製品 ◦ SQL ◦ 強整合性 ◦ 高可用性 ◦ スケーラブル ◦ フルマネージド 2
3. Goal • 今日のGoal ◦ 技術選定の際にCloud Spannerを選択肢として検討できる 3
4. Contents • アーキテクチャ • 得意なこと • 現在地とロードマップ 4 FAQを通して、これらのトピックを理解していきましょう
5. Cloud SpannerはRDBですか？ 5
6. Cloud SpannerはRDBですか？ 6 RDBの顔 • SQL • トランザクション • 強整合性 KVSの顔 • アーキテクチャ • 水平スケールが容易 • 外部キー制約が使えない RDBの皮をかぶったKVS
7. Cloud SpannerはRDBですか？ 7 RDBの顔 • SQL • トランザクション • 強整合性 KVSの顔 • アーキテクチャ • 水平スケールが容易 • 外部キー制約が使えない RDBの皮をかぶったKVS
8. Cloud SpannerはRDBですか？ Entry Point Node 8 Node Node コンピューティング層 ストレージ層 Split Split Split Split Split Split Split Split Split 1 - 100 101 - 200 201 - 250 ※Colossus 分散ファイルシステム上にある 251 - 300 301 - 400 401 - 500 501 - 600 601 - 700 701 - 800
9. Cloud SpannerはRDBですか？ Entry Point Node 9 Node Node コンピューティング層 ストレージ層 Split Split Split Split Split Split Split Split Split 1 - 100 101 - 200 201 - 250 ※Colossus 分散ファイルシステム上にある 251 - 300 301 - 400 401 - 500 501 - 600 601 - 700 701 - 800 • レコードをsplit単位で管理している • 読み書き処理の実行を行う • スケールアウトの単位になっている
10. Cloud SpannerはRDBですか？ Entry Point Node 10 Node Node コンピューティング層 ストレージ層 Split Split Split Split Split Split Split Split Split 1 - 100 101 - 200 201 - 250 ※Colossus 分散ファイルシステム上にある 251 - 300 301 - 400 401 - 500 501 - 600 601 - 700 701 - 800 • テーブルのレコードが分割されて格納されている • PKのレンジで分割される • 分割は自動的で行われる • 負荷状況に対応して再分割される • １つのNodeに紐づく
11. Cloud SpannerはRDBですか？ • Splitの具体例 11 company_id (PK) name tel 1 hoge 001-0000 2 fuga 002-0000 3 piyo 003-0000 ... 101 foo 101-0000 102 bar 102-0000 103 baz 103-0000 ... company_id: 1 ~ 100 のSplit company_id: 101 ~ 200 のSplit
12. Cloud SpannerはRDBですか？ Entry Point Node 12 Node Node コンピューティング層 ストレージ層 Split Split Split Split Split Split Split Split Split 1 - 100 101 - 200 201 - 250 251 - 300 301 - 400 401 - 500 501 - 600 601 - 700 701 - 800 Split Split Split 1 - 50 51 - 100 101 - 200 テーブルごとに分割の範囲は異なる
13. Cloud SpannerはRDBですか？ • Tips ◦ なぜそういうアーキテクチャになっているのかについては、Googleのデータ ベース製品の歴史をたどると理解しやすい ◦ GCP Databaseの世代交代 by @sinmetalさん 13
14. https://gcpug.jp 14 GCP Databaseの系譜 (sinmetalの主観) Bigtable Datastore Spanner Realtime DB Firestore 2006年 論文公開 2011年 リリース 2013年 論文公開 2017年 リリース 引用
15. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ 15
16. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • 基本的には使えます！ • 抑えておきたい独自仕様 ◦ インターリーブ ◦ DML(INSERT, UPDATE, DELETE)は使えない ◦ シーケンシャルなPKは避ける ◦ セカンダリインデックスもテーブル 16
17. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • インターリーブ ◦ テーブルに親子関係を定義できる 17
18. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ 18 company_id (PK) name tel employee_id (PK) name 1 hoge 001-0000 1 1 Taro 1 2 Jiro 2 fuga 002-0000 2 3 Saburo 3 piyo 003-0000 ... company_id (PK) employee_id (PK) name 1 1 Taro 1 2 Jiro 2 3 Saburo company_id (PK) name tel 1 hoge 001-0000 2 fuga 002-0000 3 piyo 003-0000 Companyテーブル Employeeテーブル Splitでの物理的な配置 親子関係にあるレコードが同じSplitにあることが保証される その結果、JOIN処理が安定して速くなる
19. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • DML（INSERT, UPDATE, DELETE）は現時点では使えない ◦ 更新系はクライアントSDKを使って実装 19
20. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • Google Cloud Next ‘18でのロードマップで年内リリースが発表！ ◦ DMLサポート ◦ JDBCサポート 20
21. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • シーケンシャルなPKは使えない ◦ ホットスポットが発生してしまう 21 Entry Point Node Node Node コンピューティング層 ストレージ層 Split Split Split Split Split Split Split Split Split 1 - 100 101 - 200 201 - 250 251 - 300 301 - 400 401 - 500 501 - 600 601 - 700 701 - 800 (1, “hoge”, “001-0000”) (2, “fuga”, “002-0000”) (3, piyo, “002-0000”) … とシーケンシャルなPKが連続で挿入された このNodeだけに集中して負荷がかかる = ホットスポット
22. https://gcpug.jp 22 • PKにしたい値から、分散する値を生成する ◦ ハッシュ ▪ Hash(1) -> Xjead = Xjead@1 ◦ 逆順 ▪ ID + 小分類 + 中分類 + 大分類 ◦ Shard ▪ crc32c(2018/06/10 18:36:37 …) % 10 = Modulo @2018/06/10 18:36:37 … PKの戦略 引用
23. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • セカンダリインデックスもテーブル 23 company_id (PK) name tel 1 hoge 001-0000 2 fuga 002-0000 3 piyo 003-0000 key PK fuga 2 hoge 1 piyo 3 ベーステーブル nameカラムに貼ったセカンダリインデックス インデックスを使った参照 1. keyから対象レコードのPKを特定 2. PKを使ってベーステーブルのレコードを参照
24. 既存のDDL/SQLやテーブル設計のノウハウは使えますか？ • とあるSQLをチューニングしていきましょう ◦ デモ 24
25. Productionで使うDBの選択肢としてどうですか？ 25
26. Productionで使うDBの選択肢としてどうですか？ • 観点を分けると ◦ どういうサービスに向いていますか？ ◦ 運用面のサポートはどうなっていますか？ ◦ 新規/既存サービスでの選択肢としてどうですか？ 26
27. どういうサービスに向いてますか？ 27
28. どういうサービスに向いていますか？ • 大量データが蓄積されるサービス • 特定のJOIN処理を大量にさばく必要があるサービス • 全世界に展開し、強整合性を担保しないといけないサービス 28
29. どういうサービスに向いていますか？ • 大量データが蓄積されているサービス ◦ テラバイトサイズ ◦ サービス要求としてデータのパージできない ◦ 新しいデータにも古いデータにもアクセスが来る 29
30. どういうサービスに向いていますか？ • 特定のJOIN処理を大量にさばく必要があるサービス ◦ 例えば音楽データを扱うサービス ◦ アーティストを軸にアルバム、曲などの情報を頻繁にJOINする処理が発生 30
31. どういうサービスに向いていますか？ • 全世界に展開し、強整合性を担保しないといけないサービス ◦ 例えばゲーム 31
32. ランニングコストは高いの？ 32
33. ランニングコストは高いの？ • ベースの費用は高いがスケールアウトに対してはリーズナブル ◦ プロダクションでの最低ノードは3つ ◦ 30万円~/月 ◦ https://cloud.google.com/spanner/pricing 33
34. 運用面のサポートはどうなっていますか？ 34
35. 運用面のサポートはどうなっていますか？ • マネージできる項目 ◦ ノード数のみ ◦ ノードを増やすと、計算リソース、ストレージがともに増える 35
36. 運用面のサポートはどうなっていますか？ • 監視項目 ◦ CPU使用率 ◦ クエリのスループット 36
37. 運用面のサポートはどうなっていますか？ • Google Cloud Next ‘18でのロードマップで年内リリースが発表！ ◦ クエリスタッツ ◦ スロークエリの検知 37
38. 新規/既存サービスでの選択肢としてアリですか？ 38
39. 新規/既存サービスでの選択肢としてどうですか？ • Cloud Spannerが得意なことが課題である、または課題になりそうな 場合はアリ • 参考: 得意なこと ◦ 大量データを扱える ◦ 特定のJOIN処理を大量にさばける ◦ マルチリージョンで強整合性を担保できる 39
40. 新規/既存サービスでの選択肢としてどうですか？ • ユースケースは変わり得るためテーブル設計は慎重に ◦ インターリーブは不可逆です！ 40 company_id (PK) name tel employee_id (PK) name 1 hoge 001-0000 1 1 Taro 1 2 Jiro 2 fuga 002-0000 2 3 Saburo 3 piyo 003-0000 ... 再掲）Splitでの物理的な配置 インターリーブを使った場合、 子レコードだけのレンジスキャンは遅い
41. 新規/既存サービスでの選択肢としてどうですか？ • 開発コストはそれなりにかかる ◦ 必須項目 i. 全てのユースケースを洗い出してSpanner用のテーブル再設計 ii. 取得系のSQLをSpanner用クエリに書き換え iii. 更新系のSQLをSDKでの記述に書き換え 41
42. 新規/既存サービスでの選択肢としてどうですか？ • 既存データの移行について ◦ Google Cloud Dataflow ◦ Cloud Next ‘18のセッション 42
43. まとめ • アーキテクチャ ◦ RDB on KVS • 得意なこと ◦ 大量データを扱える ◦ 特定のJOIN処理を大量にさばける ◦ マルチリージョンで強整合性を担保できる • 現在地とロードマップ ◦ 現状、開発周りは発展途上の段階 ◦ Productionで要求される機能を揃えつつある 43