Изменения

== Барсик (постфактум) ==

BARSiC — асинхронная репликация и консенсус для 70 баз данных.

Хрень какая-то, честно говоря. Технических деталей было крайне мало, просто общая мысль - вот, им ничего готовое не подошло, Raft они почему-то сочли слишком сложным, поэтому сделали всё сами и на основе другого протокола - Viewstamped Replication аж от целой Бабы Лизы... то есть Барбары Лисков. Я раньше про этот протокол вообще не слышал, уже после конфы почитал - так вот, '''ОНО ВООБЩЕ НЕ ОТЛИЧАЕТСЯ ОТ RAFT-а''', точнее, отличается, но в худшую сторону - оно '''СЛОЖНЕЕ'''! 10 типов сообщений вместо 4-х у Raft-а. {{WikiCutBegin|Развёрнутое объяснение под катом, взял [https://groups.google.com/g/raft-dev/c/cBNLTZT2q8o отсюда]}}With apologies to Barbara, James, and Brian. VR introduced some greatideas, and VRR was a huge improvement in clarity. I think the industrywould be in a better place now with respect to consensus if it hadpaid less attention to Paxos and more to VR. You're right, Heidi, that Raft and VR/VRR are similar, and weacknowledge this in the first page of the paper. At a high level, you could argue they're exactly the same. Lamportwould probably call them both Paxos. Their messaging pattern issimilar. Why they work is similar, and their proofs of correctnesscould be similar. At a low level, you could argue they're very different. Raft'smechanism is compact (VRR uses 10 message types where Raft uses 4 toaccomplish the same tasks). Raft spells out how to do leader electionwith randomized timeouts and how to avoid transferring entire logs. And of course membership changes are entirely different. Now (2015), there's a huge difference in completeness. Raft hasseveral implementations including membership changes and logcompaction, some evaluation, a proof or two, my dissertation (a lot ofdiscussion about design choices), and many online resources to helppeople learn. I don't think VR/VRR is competitive with any of thatcurrently. For example, I just searched GitHub for "ViewstampedReplication" and found only one project; searching "VRR" yields noise.   Paper-wise, I'm biased, but I think the Raft paper is more accessibleto beginners. That's because the Raft paper explains the why, and theVRR paper just tells you the what. I also think the leader election algorithm in the original VR isbetter than in VRR. I discuss this in the related work in mydissertation. The original VR has the view manager tell the new leaderto start, yes, but it doesn't have to transmit any log entries. And Istill don't feel great about the leader being a function of the view(term) number. It feels misleading, since of course different serversmight be in different views, especially during leader changes. But Ihaven't implemented or evaluated that approach. We (John and I) actually didn't know about the VRR paper until afterwe had started Raft. I think the earliest time someone mentioned it tous was three days before our first paper submission on Raft, inSeptember 2012, buried in an email with a bunch of other pointers.Would we have used VRR instead of creating Raft if we knew abut it intime? I'm not sure, but it definitely would have been a betterstarting point for us. Know of any performance evaluation between these two protocols? Nope.Normal-case operation would be the same, so you'd probably have tocompare leader changes. And I feel like that depends on the details ofhow you "optimize" VRR, so I don't know if it'd be apples-to-apples. Hope I haven't offended anyone, and hope this helps,Diego {{WikiCutEnd}}. == Оптимизации Go (постфактум) ==

== Перила (постфактум) ==

== Шардирование: с нуля до Яндекс Диска (постфактум) ==