分割を32個に増やしました。キーに偏りがなければ、最も多い分割は平均の1.28倍です。
偏りがあると5.09倍でした。分割を増やしても、1つのキーは分けられません。
分割は処理を並べるための仕組みです。キーが散っていれば、件数はほぼ均等に分かれます。
イベントストリーミングでは、出来事を複数の分割に振り分けて並べて処理します。実際に数えました。
出典もこの狙いをデータをこのように分散して置くことは、多くの仲介役に対して同時に読み書きできるようになるため、規模を伸ばすうえで重要であるとしています。
出来事20万件・キー2000種を用意しました。キーを混ぜてから分割へ割り当てる形です。
偏り 分割数 最も多い分割 平均 最大が平均の何倍か なし 4個 53399件 50000件 1.07倍 なし 8個 28542件 25000件 1.14倍 なし 16個 14587件 12500件 1.17倍 なし 32個 8015件 6250件 1.28倍 1/i^0.5 4個 51610件 50000件 1.03倍 1/i^0.5 8個 27665件 25000件 1.11倍 1/i^0.5 16個 15466件 12500件 1.24倍 1/i^0.5 32個 9079件 6250件 1.45倍
偏りがない場合、32個に分けても最大は平均の1.28倍です。ほぼ均等に分かれます。
分割数を増やすほど、1つあたりの件数は減ります。4個の53399件から、32個の8015件までです。
少し偏りを入れた場合も、16個までは1.24倍に収まります。32個で1.45倍です。
分割を増やすほど倍率が上がっていることに注意してください。1つあたりが小さくなるほど、偏りの影響が目立ちます。
キーが散っていれば、分割数を増やしても偏りは小さい。
This distributed placement of your data is very important for scalability because it allows client applications to both read and write the data from/to many brokers at the same time.原文Apache Kafka「Introduction」 この内容の有効期限2027-02-18
同じキーは同じ分割へ入ります。1つのキーに集中していると、分割を増やしても分けられません。
イベントストリーミングで詰まる原因の多くがキーの偏りです。強い偏りを入れて測りました。
偏り 分割数 最も多い分割 平均 最大が平均の何倍か 1/i^1 4個 64253件 50000件 1.29倍 1/i^1 8個 41939件 25000件 1.68倍 1/i^1 16個 35686件 12500件 2.85倍 1/i^1 32個 31811件 6250件 5.09倍
分割を4個から32個へ8倍にしました。平均は50000件から6250件へ、きれいに8分の1です。
ところが最も多い分割は64253件から31811件までしか減りません。半分にしかなっていません。
出典も割り当ての規則を同じキーを持つ出来事は、同じ分割へ書き込まれると明記しています。
この規則があるので、1つのキーに集中した分は、どれだけ分割を増やしても1か所に残ります。
分割を増やすほど平均だけが下がるので、倍率は上がり続けます。32個で5.09倍という数字はそれを表しています。
2番目は効きますが、そのキーの中の順序が崩れます。順序が要るかどうかで選び方が変わります。
平均は分割数で下がるが、最大は下がらない。
Events with the same key (denoted by their color in the figure) are written to the same partition.原文Apache Kafka「Introduction」 この内容の有効期限2027-02-18
分割をまたぐと順序は保証されません。守りたい範囲とキーを一致させる必要があります。
イベントストリーミングの順序は、分割の中でしか守られません。どこまで守られるのかを数えました。
出来事10万件について、前後に並んだ組が同じ分割に入っているかを数えます。同じ分割なら順序が保証されます。
分割数 同じキーの並び 別のキーとの並び 順序が守られる組の割合 1個 99999組 0組 100.0% 4個 24989組 75010組 25.0% 16個 6352組 93647組 6.4%
分割を1個にすれば100.0%です。全体が1本の並びになるので、順序は完全に守られます。
16個に分けると6.4%です。前後の組のうち、9割以上は順序が保証されません。
この数字は「全体の順序」を見たものです。実務で必要なのは、たいてい全体ではありません。
同じ顧客の申請が順に処理されればよい、といった形です。その単位をキーにすれば、必要な範囲では順序が守られます。
つまりキーの決め方は、負荷の散り方と、順序の範囲の両方を決めます。片方だけで選べません。
同じ分割へ、複数の書き手が同時に書くこともあります。出典も適切であれば、両方の書き手が同じ分割へ書き込めることに注意と書いています。
この場合、書き手どうしの順序は決まりません。並びは、分割に届いた順になります。変更を並びとして拾う側の話はCDCの記事で扱っています。
キーは、負荷の散り方と順序の範囲を同時に決める。
キーの偏りは式で作った分布です。実際の偏りは業務によって違い、特定の1社や1店舗に集中することがあります。順序の割合も「前後に並んだ組」で数えた単純な形で、実務で必要な順序の範囲とは別です。ここで見せているのは、同じキーが同じ分割へ入るという規則から、偏りが分割数では解けないという関係です。
Note that both producers can write to the same partition if appropriate.原文Apache Kafka「Introduction」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る