golang ゴルーチンで ReadOnlyTransaction を使用する Spanner クエリが徐々に遅くなるのはなぜですか?

#質問の内容

テーブルから約 10,000 行をクエリしようとしています。

limit offset を含む他のさまざまなオプションを試してみましたが、望ましい結果が得られなかった後、各 goroutine に対して 1 行のクエリを実行してみました。各行のクエリとフェッチには ~5ms しかかかりませんが、10,000 個のバッチには 20s かかるという考えです。

以下に、コードの簡略化したバージョンを示します。

リーリー

結果は次のように追跡されます:

リーリー

期待どおりに正常に開始されますが、クエリ時間は増加し続けます。

spannerClient

の MaxSessions と MinSessions は 100 なので、100 を超えるとわずかに速度が低下するのではないかと想像されますが、実際はそうではありません。真実ではありません。

ここをお読みください:

リーリー

非反復クエリ (

ReadRow など) でも同じ結果が得られます。

for ループの外で

tx := spawnerClient.Single() を使用すると、同様の結果が得られます。 ＃＃＃質問：＃＃＃

これは、ゴルーチンで

spannerClient.Single()

を実行しているにもかかわらず、ゴルーチンは依然として同じセッション/トランザクションを使用しようとしていることを意味しますか?
1. この問題を解決するには、上記の内容を変更するにはどうすればよいですか?

正解

TLDR: デフォルトの最大セッション プール サイズは 400 です。これは、400 を超えるクエリを同時に実行できないことを意味します。この同時実行性を実現するには、セッション プールのサイズを増やす必要があります。

まず第一に、各クエリが 1 行を読み取るように 10,000 個のクエリを並行して送信することは、問題に対する最も効率的な解決策ではないと思います。 従業員 ID によるフィルタリング以外の基準がなく、それらの ID があちこちに分散している場合は、次の形式でクエリを作成する方が効率的です。

リーリー 完全な例については、このコメントを参照してください: https:// /github.com/googleapis/google-cloud-go/issues/858#issuecomment-550982307

具体的な質問に戻ります:

クエリの実行にかかる時間を実際に測定しているわけではありません。これは少し混乱しますが、行

it := tx.Query(gCtx, stmt2)

はクエリを
1. 実行するのではなく、実行の準備をするだけです。 row, err := it.Next() が初めて呼び出されたときに実行されます。これは、記録された実行時間からもわかります。最初のステートメントは 30 マイクロ秒以内に実行されるようですが、これは不可能です。 これは、クライアント上の何かが進行状況を制限していることを意味します。この場合、それはセッション プールの最大サイズであると確信しています。デフォルトの最大セッション プール サイズは 400 です。これは、最大 400 個のクエリを並行して実行できることを意味します。待機時間が増加しているのは、ゴルーチンが待機キューに配置され、セッションが使用可能になるのを待っているためです。キューの最後にあるゴルーチンは待機時間が長くなります。

以上がgolang ゴルーチンで ReadOnlyTransaction を使用する Spanner クエリが徐々に遅くなるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。