なんだか分かった気がして分からないSnowflakeのウェアハウスの同時実行特性。
ウェアハウスが1度に何個のクエリを同時処理するか
だいぶ抽象化されているがウェアハウスは並列化された計算可能なコンピュータ。
処理すべきクエリが大量にあった場合、1つのウェアハウスがそれらを同時に処理しようとする。
1個のウェアハウスが同時に最大何個のクエリを同時処理するか、
MAX_CONCURRENCY_LEVEL により制御できる。
デフォルト値は 8 に設定されている。
MAX_CONCURRENCY_LEVEL を超えると、クエリはキューに入れられる。
または、マルチクラスタウェアハウスの場合は、次のウェアハウスた立ち上がる。
もちろん、クエリ1個が軽ければ同時処理は早く終わるが、重ければ時間がかかる。
逆に言うと、MAX_CONCURRENCY_LEVEL を小さくすると、1つのウェアハウスが同時処理する
最大クエリ数の上限が下がり、クエリ1個に割りあたるコンピューティングリソースが増える。
MAX_CONCURRENCY_LEVEL を大きくすると、クエリ1個に割り当たるリソースが減る。
同時実行数を減らすとキューイングされる数が増える
MAX_CONCURRENCY_LEVEL を小さくするとクエリの処理性能が上がるが、
キューに入るクエリの数が増える。
ちなみにデフォルトだと、キューに入ったクエリは永遠にキューに残り続ける。
キューに入ったクエリをシステム側でキャンセルする時間を
STATEMENT_QUEUED_TIMEOUT_IN_SECONDS により設定できる。
ウェアハウスサイズとの関係
ウェアハウスサイズアップはスケールアップ、マルチクラスタはスケールアウト、
なんかと、テキトーに丸めて表現されたりするが、
ウェアハウスサイズアップにより、コンピューティングリソースが増加するため、
同じ MAX_CONCURRENCY_LEVEL であっても クエリ1個に割り当たるリソースが増えることで、
結果的に所要時間が小さくなる。見かけ上、並列性が上がった風になる。
ウェアハウスサイズ、ウェアハウス数の2つのファクタによりリソースの総量が決まるため、
これらを固定した状態で MAX_CONCURRENCY_LEVEL を増やしたとしても、
結果として処理できる量が増えたりはしない様子。
同時実行性能が関係するパフォーマンスのベスプラ
お金をかけずに性能が上がるということはない。
MAX_CONCURRENCY_LEVELはあくまで微調整用途。
大量の小さなクエリをガンガン処理するといったケースでは、ベスプラでは
順当にウェアハウス数を増やして、その上でウェアハウスサイズを増やすべきとされている。
この辺りが、「気分でウェアハウスサイズを増やしても性能上がらないなー」
という現象の一因（、かもしれない）。