Closed sinmetal closed 5 years ago
たまたま、クエリ投げただけだから、特に何も考えてなかったね。
gcloud spanner
では staleness queryは投げられないか・・・?
ちょっと適当にコード書いて試してみようか。
なるほど Go の中から叩いているのかと思ったけど gcloud とか Web UI からじゃ無理ですね。面倒。
WRITEはGoから投げてたんだけど、これは今Table何件あるんだろう?と思って、Consoleからぽいっとクエリをなんとなく投げたって時のもの。
適当にクエリを投げるもの作ってみた https://github.com/sinmetal/screwdriver
ExactStalenessQueryで15secを指定してみたけど、strongと同じように、がくっとWRITEの性能が下がってるね。
なるほど、 read-only tx がそれぞれのスプリットでどのレプリカ使ったかでも違う結果になりそうですね。仮説としては全部リーダーを避けた場合が最適だろうけど、マルチリージョンじゃないと狙えないし外部からは観測できないか。
マルチリージョンにしないとRead Only Replicaが登場しないから、Writeに影響を与えないようにReadのクエリを投げるのは難しそうだねー。 https://cloud.google.com/spanner/docs/replication?hl=en#read-only
ゾーン障害時以外は全部のレプリカでクォーラム取ろうとするから、リーダーが少し仕事が多いとはいえリーダー以外の負荷もレイテンシに影響するとかそんなかんじですかね
nam3, nam-eur-asia1 でも同じようなことしてみれば、何か面白い結果になったりするかな?
https://cloud.google.com/spanner/docs/instances#multi-region_configurations
少なくともマルチリージョンの方だと staleness を使うのはベストプラクティスに沿っているからだいぶ性能影響があるでしょうね。
https://cloud.google.com/spanner/docs/instances?hl=ja#multi-region-best-practices
デフォルトのリーダー リージョン外で最適な読み取りパフォーマンスを得るには、15 秒以上のステイルネスを使用します。
何が起こるのかというと、 https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes?hl=ja#strong_read_multi-node
API レイヤが、スプリット 0、スプリット 1、スプリット 2 の一部のレプリカに読み取りリクエストを送信します。また、前のステップで選択した読み取りタイムスタンプも含まれます。この時点で、次の 3 つ状態が考えられます。
の中の
a. 多くの場合、それぞれのレプリカは読み取り可能な状態であることを自身の内部状態と TrueTime から認識し、処理を実行します。
となって
b. レプリカが最新のデータかどうかわからない場合もあります。この場合、リーダーに RPC を実行し、読み取り実行に必要な最新トランザクションのタイムスタンプを取得します。トランザクションが適用されると、読み取りが実行されます。
の必要がなくなり、通信やトランザクションの適用待ちがなくなるという理解ですかね。
現時点の理解でとりあえず予想
これの query って全部 strong read ですよね。 staleness は別の検証する感じです?