問題があるかどうかはわかりませんが、これが可能な解決策だと思います:
| Distribution:
parent | buffer = [hash(key, id)), data[id]]; send(buffer);
nodes | recv(buffer); h_id, data = buffer;
親ノードはローカルを使用して、送信するデータの一部にkey
ハッシュ値 ( h_id
) を生成し、ローカル ノードは結果とデータ自体の両方を受け取ります。id
h_id
| Reduction:
nodes | buffer = [h_id, data]; send(buffer);
parent | recv(buffer); h_id, data_id = buffer;
カウンター フローでは、ノードは元h_id
のデータと以前に受信したデータの両方を送信する必要があります。そうしないと、次の検証が失敗します。
hash(key, data) == h_id
は親ノードでしか認識されていないためkey
、ローカル ノードを変更することは難しく、親ノードで が引き続き有効になるdata
よう h_id
に変更することは困難です。hash(key, data_id)
data
順序付けに関しては、後で再構築するために、 の最初の 4 バイトにパーティションの番号が格納されていると単純に想定できます。
編集:
あなたが指摘したこの余分なストレージに気付いていないかもしれませんが、ここに私が提案しようとしたものがあります. 初期データを持つ4 台のマシン 、 A
、B
、C
およびを考えます。P
P{key, data[3]}
____|____
/ | \
A{} B{} C{}
次に、P
マシン間でデータを分散し、データ シャード自体と生成されたハッシュの両方を送信します。
P{key, data[3]}
____|____
/ | \
A | C
{data[0], hash(key, data[0])} | {data[2], hash(key, data[2])}
B
{data[1], hash(key, data[1])}
ストア内の最初のバイトがグローバル インデックスであると仮定すると、最初のベースを元の順序でdata[i]
再構築できます。data[3]
また、各マシンが を保存/受信key
できるようにすると、後ですべてのローカル ノードでハッシュを解除data[i]
して再構築することができます。data[3]
エラーの追加は、グローバルに有効であると想定する必要があるため、データのシャードとdata[i]
受信したキーに対してのみ発生する可能性があることに注意してください。ここでの要点は、データ パーティション自体だけでなく、値のリストもマシン間で分散されるということです。つまり、任意のマシンだけに保存されるすべてのファイルのリストは必要ありません。hash(key, data[i])
key
hash(key, data[i])
すべてのノードで維持する余裕があることkey
、または少なくともkey
元のデータを再構築しようとしている 1 つのノードに送信する余裕があることを考慮して、たとえば node の削減ステップの例を次に示しますB
。A
そしてC
ローカル{data[i], hash(key, data[i])}
をノードB
にP
送信key
しB
、に送信するため、このノードは受信したデータのハッシュを解除できます。
P{key, data[3]}
|
A | C
{data[0], hash(key, data[0])} | {data[0], hash(key, data[0])}
\ | /
B
{data[1], hash(key, data[1])}
次に、次をB
計算します。
/ {data[1], hash(key, data[1])} \ {data[1]}
unhash( {data[0], hash(key, data[0])} ) => {data[0]} => {data[3]}
\ {data[2], hash(key, data[2])} / {data[2]}
元のデータを正しい順序で復元します。