最終的な整合性で使用するマークルツリーの説明
Merkle Trees は、いくつかの分散、複製されたキー/値ストアでアンチエントロピーメカニズムとして使用されます。
間違いなく、アンチエントロピーメカニズムは良いことです-運用中に一時的な障害が発生するだけです。なぜマークルツリーが一般的なアプローチであるのか理解していない。
完全なマークルツリーをピアに送信するには、ツリーの最下位レベルに保存されている各キー値のハッシュとともに、そのピアにローカルキースペースを送信する必要があります。
ピアから送信されたマークルツリーを比較するには、独自のマークルツリーが必要です。
両方のピアには既にソートされたキー/値ハッシュスペースが手元にある必要があるため、不一致を検出するために線形マージを行わないのはなぜですか？
維持費を考慮に入れると、ツリー構造が何らかの節約をもたらすとは確信していません。また、ツリーの葉を通る線形パスは、表現をシリアル化するためだけに既に行われているという事実ワイヤー上。
これを裏付けるために、ストローマンの代替案は、ノードにハッシュダイジェストの配列を交換させることです。ハッシュダイジェストは、モジュロリング位置によって増分的に更新およびバケット化されます。
私は何が欠けていますか？
マークルツリーは、同期時に転送されるデータの量を制限します。一般的な前提は次のとおりです。
- ネットワークI/Oは、ローカルI/O +ハッシュの計算よりも高価です。
- ソートされたキースペース全体を転送することは、いくつかのステップで比較を段階的に制限するよりもコストがかかります。
- キースペースは、類似点よりも差異が少ないです。
マークルツリーの交換は次のようになります。
- ツリーのルート（1つのハッシュ値のリスト）から始めます。
- Originは、現在のレベルでハッシュのリストを送信します。
- 宛先は、ハッシュのリストをそれ自体に対して比較し、異なるサブツリーを要求します。違いがない場合、要求は終了できます。
- リーフノードに到達するまで、手順2と3を繰り返します。
- Originは、結果セットのキーの値を送信します。
典型的な場合、キースペースの同期の複雑さはlog（N）になります。はい、極端な場合、共通のキーがない場合、操作はハッシュのソートされたリスト全体O（N）を送信することと同等になります。書き込みが来たら動的に構築し、シリアル化された形式をディスクに保持することで、Merkleツリーを構築する費用を償却できます。
DynamoまたはCassandra Merkleツリーを使用する方法について話すことはできませんが、Riakはクラスター内同期のためにそれらの使用を停止しました（ほとんどの場合、ヒント付きハンドオフと読み取り修復で十分です）。いくつかの内部アーキテクチャビットが変更された後、それらを後で追加し直します。
Riakの詳細については、メーリングリストに参加することをお勧めします。 http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com