本日（ていうか日付変わっていたので昨日）Cloud Spannerの設計について解説セッションがありました。

酒とゲームとインフラとGCP 第6回　〜早く暑気払いしないと死ぬぞ〜@デジタルハリウッド@御茶ノ水！ 

分散リレーショナルデータベースを使う上での設計のポイントが話された。

Cloud Spanner概要

　MySQLのスケールアウトが手間がかかるが、Spannerはノード追加削除でスケールアウトが自由自在

　リージョンなものの提供

　今後マルチリージョンを提供

　MySQLでないので意識するとよいパフォーマンスがでる

　低ワークロードではパフォーマンスが出ない

PKの使い方によってはデータが分散しない（データが偏る）

　オートインクリメントだと１ノードで入る（データが分散しない）可能性あるのでサポートしていない

　サポートしないのも１理由

　UUIDを使う　※128bitのを使うといい

　PKの選択でノードの偏りがある場合あり

　　日付だと偏るケースがある

インターリーブ

　　インターリーブ＝親子関係

　　関連したデータのロカリテティを管理できる

　　関連したデータはあっちこっちにいくことがなくなる

　　PKはインデックスいらない

　　どこかのSpannerサーバに格納される場合あり

　　セカンダリインデックスは、不要な場合は作成しない、できるだけ使わない

gRPC

　　ｇRPCコネクション　デフォルト4、最大256

       デフォルトの4で十分とのこと

　　負荷試験でもそう変わらない

　　try-errorを繰り返す

   セッション

　　トランザクションを実行できるコンテキスト

　　並列で行われるトランザクションは各自セッションを利用する必要あり

　　セッション数＝スレッド数

　　MAX10,000

    Developer consoleのエラーレート

　　abortしたトランザクションは自動リトライしてくれる

　　例外がでていなければエラーレートは無視していい

　　ノードは分散ストレージのデータを管理している

　　ノードを削除すると管理していたスプリットのオーナが変わる

　　障害時も同

　　（ドキュメントに記載されていないことだが、）２GB per parent record

テーブル分割

    Size-based splits データの容量でテーブル分割

　Load-base splits　負荷によりテーブル分割

  シーケンシャルINSERTだと分割されない

　負荷試験は20-30分j実施

　5分だとノードが十分に活用されていない

　負荷試験はデータベースをドロップしないと、正確な負荷試験ができない場合も

　LSM Treeを使っているとレコード削除だけでは削除されない

　テーブルのクリーンアップは一週間かかる

　TPS

ノード削除できない場合がある。データの容量が多すぎる。5TB Writeして1ノードにしても3ノード必要できないので削除できない

75%CPU超えたら、functionsでノード追加などできる

75%を１ノードの負荷目安

Dailyで取っているのでサポートに問い合わせて別のインスタンスに戻せる

Query Plan cache

  IDを変えると３つのキャッシュが作られるのでParameter Binding

 （ JDBCのPrepareStatementと同じ？）

ノード追加すると若干レイテンシーが落ちるが、しばらくすると回復する

リアルユースケース、実データで負荷試験

ロードツール

年内にもロードツールがでる？Dataflow IO？

現状公式にはDML（ていうかWrite系SQL）にはサポートされていないが、SQLを書くと、Spannerコードにしてくれるツールを開発されたが、後々OSS化もあるとのこと

Spanner用のWirte系SQLをサポートした（制限有りの）JDBCドライバもあるが