分ける先を512個に増やしても、鍵が偏っていれば最大は平均の26.1倍でした。
偏りがなければ1.0倍前後です。並列に効かせるかどうかは、鍵の選び方で決まります。
行の散り方は分配の鍵で決まります。偏った鍵では、分ける先を増やしても集中が残ります。
Redshiftでは、行の散り方が分配の鍵で決まります。公式は表にデータが読み込まれるとき、行は、その表に定められた分配の鍵に従って節の切れ端へ配られると述べています。
鍵が偏っていたらどうなるか。実際に振り分けて数えました。
鍵 50,000種・引く回数 500,000回 鍵を混ぜて置き場所を決める。置き場所の数を変えて、いちばん多い置き場所の割合を見る 置き場所の数 均等なら よく引かれる鍵がある場合 均される場合 最大と均等の比 8個 12.50% 15.98% 12.60% 1.3倍 32個 3.13% 7.46% 3.18% 2.4倍 128個 0.78% 5.52% 0.82% 7.1倍 512個 0.20% 5.10% 0.22% 26.1倍
右から2列目は、偏りがない場合です。ほぼ均等な値に収まっています。
その左が本題です。偏りがあると、512個に分けても5.10%で止まります。均等の0.20%とは26.1倍の開きです。
混ぜてから振り分けているので、鍵の並びによる偏りは消えています。それでも残ります。
残る理由は、同じ鍵の行が同じ切れ端に行くことです。1つの値に行が集まっていれば、分けても分かれません。
だから直し方は、鍵に選ぶ列を変えることになります。値の種類が多く、件数が均される列を選びます。
偏った鍵では、分ける先を増やすほど比が広がる。
When the table is loaded with data, the rows are distributed to the node slices according to the distribution key that is defined for a table.原文AWS ドキュメント「Data warehouse system architecture」 この内容の有効期限2027-02-18
分けた先が並行して動きます。ただし、読む量そのものは選んだ項目の数で決まります。
Redshiftでは、計算の節がさらに細かく分かれます。公式は計算の節は切れ端に分割されると述べています。
分けた先は並行して動きます。公式も切れ端は、その操作を完了するために並行して働くと説明しています。
並行して動いても、読む量そのものは減りません。減らせるのは選ぶ項目のほうです。
表 200,000行・1行あたり 12項目（1項目 4バイト） 集計に使う項目の数を変えて、読む量を見る 使う項目 行ごとに持つ形 列ごとに持つ形 比 1個 9.2MB 0.8MB 12.0倍 2個 9.2MB 1.5MB 6.0倍 3個 9.2MB 2.3MB 4.0倍 6個 9.2MB 4.6MB 2.0倍 12個 9.2MB 9.2MB 1.0倍
1項目なら12.0倍の差です。12項目すべてを使えば1.0倍になります。
つまり全項目を選ぶ書き方は、この利点を打ち消します。並列に動かしても、読む量は変わりません。
並列が効くかどうかは前の節の鍵で決まり、読む量は項目の数で決まります。別々の判断です。
鍵が偏っていて、しかも全項目を選んでいれば、どちらの利点も出ません。
列ごとに並べる形そのものの効き方はClickHouseの記事で扱っていて、量の比が時間の比になるとは限らない点も測りました。
A compute node is partitioned into slices.原文AWS ドキュメント「Data warehouse system architecture」 この内容の有効期限2027-02-18
置く量が増えても、計算の側を増やさずに済みます。どちらが効いているかを分けて見られます。
Redshiftでは、計算と保管が分かれています。公式は管理された保管の層により、計算と保管を別々に増やして支払えるので、計算の必要だけに基づいてまとまりの大きさを決められると述べています。
分かれているので、どちらが効いているかを分けて見られます。
1番目と2番目は別物です。10年ぶんを置いていても、直近1か月だけを読めば読む量は1か月ぶんです。
だから古いデータを消す判断と、読む量を減らす判断は別々になります。
計算の側を増やす前に、3番目を確かめることになります。鍵が偏っていれば、増やしても効きません。
512個に分けて26.1倍の偏りが残る構成では、増やした分の多くが遊びます。
同じ分かれ方は、他の分析向けの仕組みでも見られます。読む量と置く量が別勘定になる話はBigQueryの記事でも扱いました。
鍵の偏りは式で作ったもので、実在の分布ではありません。混ぜる関数も簡単なものを使っており、実際の実装とは違います。読む量も項目の数からの計算で、圧縮の効きは含めていないため、実際にはこれより小さくなります。1項目4バイトという値も置いたものです。ここで見せているのは、分ける先を増やしても鍵の偏りは消えないこと、並列の効きと読む量が別々の判断だということの2つです。
RMS lets you scale and pay for computing and storage independently, so that you can size your cluster based only on your computing needs.原文AWS ドキュメント「Data warehouse system architecture」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る