Senkronizasyon için Vector Clocks yerine açık DAG


13

Bir dizi akran arasında veri senkronizasyonu yaklaşımlarına bakmaya başladım. Eşlerin bağlantısı kesilmiş bir şekilde çalışabilmeli ve daha sonra yerel değişikliklerini birleştirmek için birlikte senkronize edebilmelidir.

Eşler yerel güncellemeleri "üç yönlü birleştirme" ile birleştirebilmelidir . Bu nedenle, senkronizasyonda akranlar hangi olguların daha yeni olduğunu bilmelidir, ancak katı bir siparişin olmadığı yerlerde, ortak kökene dayanan gerçekleri birleştirebilmelidirler.

Bağımsız akranlar değişiklik yaptığında, onları bir "saat" ile "zaman damgası" yapabilirler. "Saat" ve "zaman damgası" terimlerini kullanıyorum ama duvar saati anlamına gelmiyorum. Nedeni açıklığa kavuşturan olayların bir tür kısmi sıralaması demek istiyorum. Bu var "daha önce oldu" yönlendirilmiş Mercury grafik (DAG) oluşturan olaylar arasında ilişki.

Bu kısmi sıralamayı yapmanın "olağan" yolu bir vektör saati kullanmak gibi görünüyor . Ancak bunlar çok büyük olabilir. Aralıklı ağaç saatleri gibi daha yeni gelişmeler , zaman damgalarının daha kompakt bir şekilde saklanmasını sağlar.

Ne hakkında net değilim senkronizasyon protokolleri görünüşte DAG açıkça "basit" saklamıyor neden. (Ya da öyle mi?)

Eşler, rastgele bir UUID (veya başka yollarla <peer-name> + <local-monotonically-increasing-counter>) oluşturarak bağımsız olarak bir zaman damgası oluşturabilir . Bu zaman damgasının sıralaması bu akran için tamamen açıktır.

2 eş birbiriyle senkronize olduğunda, yeni bir zaman damgası üzerinde anlaşabilirler. Yine, bu zaman damgasının sırası her iki akran için de açıktır.

Şimdi olanları eşler arasında DAG'dan önce geçirme şartı var, ancak bunun depolama ve bant genişliği gereksinimleri küçük. Zaman noktaları grafik tepe noktalarıdır. Bu nedenle, 1 veya 2 gelen kenarı vardır (istemcideki bir olay için 1 ve istemciler arasında bir senkronizasyon için 2). Bu sınırlıdır ve ağdaki eş sayısından bağımsızdır.

Tek bir zaman noktasını kullanmak için, buna yol açan zaman noktalarının grafiğine ihtiyacınız vardır. Ancak, bildiğim kadarıyla gördüğünüz gibi, mümkün olan herhangi bir akran biliyorum bir zaman noktasının (o bunu kendisi oluşturulan veya başka eş ile oluşturulan, ya da onunla senkronize ederken başka eş tarafından da söylendiğini olan) olan da vardı o zaman noktasına kadar giden tarihi bilmek için bir fırsat. Bence bunun için endüktif bir kanıt var.

DAG'yi açık bir şekilde saklamanın ve senkronize etmenin basit göründüğü göz önüne alındığında: bu pratikte kullanılıyor mu? Değilse, neden vektör saatler tercih edilir?


notlar

Eşler arası

Bir istemci sunucu çözümü üzerinde bir eşler arası çözümü tercih ederim.

Muhtemel son topoloji, kendi aralarında çoğaltan çok daha küçük bir sunucu grubuna bağlanan birçok istemci olacaktır. Bununla birlikte, bu özel topolojiyi gerektiren bir çözümden ziyade bu özel topolojiyi destekleyen genel bir çözüme sahip olmak güzel olurdu.


Söylediklerinizi yanlış anlayabilirim, ancak bir duruma yol açan tüm olayların bir grafiğinin bir sayaç vektöründen nasıl daha küçük olabileceği belirsizdir. Çok fazla sayıda düğümü ve çok az sayıda değişikliği olan bir sistemde değilseniz.
kdgregory

Teşekkürler @ kdgregory - iyi bir nokta. Gelecekte üç yönlü birleştirme hesaplayabilmek için geçmişi bilmeniz (ve geçmiş zaman noktalarının DAG'ını belirleyebilmeniz) gerekir. Yani, geçmiş zaman noktalarını saklıyorsanız, DAG'yi açıkça saklamak daha ucuzdur. Eğer varsa değil o geçmiş zaman noktalarını depolamak sonra yine verilerin üç yollu birleştirme hesaplayamaz. - Acaba bu üç yol gerekliliği olabilir mi? 3 yollu istemiyorsanız, belki de saatler açık DAG'dan daha iyi?
Benjohn

Sanırım bu kritik nokta @kdgregory olabilir, bu yüzden soruya biraz daha ekledim. Tüm tarihin bilindiğini ima eden 3 yönlü birleştirme işleminin mümkün olduğunu varsayıyorum. Tüm tarih biliniyorsa, o zaman (sanırım) açık bir DAG daha ucuzdur. Tarih kısaltılırsa, vektör saatler muhtemelen daha az maliyetli bir yaklaşımdır.
Benjohn

1
Evet, vektör saatler hakkındaki anlayışım, basitçe bir kabul / reddetme kararına yönelik olmalarıdır: "düğüm C bu veri parçasını güncellemeye çalışıyor, ancak düğüm B'nin güncellemesinin farkında değil".
kdgregory

Yanıtlar:


1

Anlayabildiğim kadarıyla Git ve Mercurial gibi sürüm kontrol sistemleri vektör saatler yerine DAG yaklaşımını kullanıyor.


1
Bir açıklama yapılmadan, başka birinin aksi görüş bildirmesi durumunda bu cevap işe yaramayabilir. Örneğin, biri "DAG yaklaşımı yerine Git ve Mercurial gibi devir kontrol sistemleri vektör saatler kullanır" gibi bir talep gönderirse , bu cevap okuyucunun iki karşıt görüş seçmesine nasıl yardımcı olur? Nasıl Yanıt Verilir kalite standartlarını karşılamak için daha iyi bir şekilde düzenlemeyi düşünün .
gnat

2
Soruyu anlama şeklimde, vektör saatlerinden ziyade DAG'ın nerede kullanıldığına dair gerçek dünya örnekleri olup olmadığını soruyorlardı.
bikeman868

1
Hem Git hem de Mecurial, DAG kullanarak eşler arası değişim senkronizasyonunun gerçek dünya örnekleridir ve umarım benjohn, oy vermenize rağmen cevabımı yararlı bulacaktır.
bikeman868

Merhaba @ bikeman868 Size net 0 için oy verdim (özür dilerim). Yanıtınız olduğu belirsizlikle yatmak bile yararlı! Referanslar veya yetkili cevaplar her zaman güzel olsa da, yığın değiş tokuşları bunu zorunlu kılmaz! Öneriniz, soru hakkındaki yorumlarda puanlarla mantıklı. Tarihi saklamak ve geçmişleri birleştirmek istediğinizde, bir DAG uygundur. Geçmişi kaydetmediğinizde ve geçerli durumda senkronizasyon ve fikir birliği istediğinizde, vektör saatler ihtiyacınız olan şeydir.
Benjohn

1

Fikir birliği sorununa bir göz atın . Görev gereksinimlerinize bağlı olarak (ne kadar veriye sahip olduğunuza, kaç eşitleme düğümü, ne sıklıkta vb.) Bu soruna yönelik mevcut çözümler ("Sal" gibi) sizin durumunuz için uygun olabilir.

Bu probleme bir başka (belki teğetsel) yaklaşım bir CRDT tasarlamaktır .


Örgü HTTP , HTTP artırılarak CRDT tabanlı bir durum senkronizasyon protokolü oluşturmaya çalışıyor. Zaman DAG'ı ve Uzay DAG'ı ile bu iki kavramın nihai tutarlılığa ulaşmak için birbiriyle nasıl ilişkili olduğu konusunda büyük bir görselleştirmeleri vardır.
Duane J

-1

Aleph protokolü, fikir birliği ile işlemlerin (veya olayların) dağıtılmış bir DAG'sını oluşturan p2p lidersiz bir protokoldür

https://arxiv.org/pdf/1908.05156


Cevabınızı, referans verilen protokolün orijinal sorunun getirdiği noktalara nasıl hitap ettiğini göstermek için genişletmelisiniz. Cevapları kendi kendine yeterli kılmak önemlidir, çünkü bu soruya katılan herkes yarar sağlar.
BobDalgleish
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.