16 ms·
It's very simple, on every insert/update/delete the node that receives the command calls all the other nodes async. and waits until they have made the call befo
by bullen 5y ago
It's very simple, on every insert/update/delete the node that receives the command calls all the other nodes async. and waits until they have made the call before it makes it and then responds.
The id's are secure random longs, so collisions are rare.
You can see the code in Root.send(...) or see the live trace by going here and pressing the Make button: http://root.rupy.se/node?make&info http://root.rupy.se/node?make&info
- ithkuil 5y agoSo if one node fails (or the network fails), some nodes will have the new value, while other nodes won't have it. I'm confused about why you call this "coherence".
- bullen 5y agoThe system only works for writes when every node is online. It's a tradeoff that is well worth the simplicity. To have fault tolerance for writes never really works and it's very wasteful. Specially when the nodes can be very reliable and report downtime for you to fix the issue manually if a node goes down. In 5 years of operation my home hosted cluster has better uptime than all cloud providers: AWS, GCP etc. for writes and 100% uptime for reads. I have blogged about how to make a 100% write uptime database here: http://talk.binarytask.com/task?id=4662372011677848884 http://talk.binarytask.com/task?id=4662372011677848884 But my conclusion is that it's a waste of time.
- ithkuil 5y agoThis is a legit solution if your requirements allow it. I'd advise you to not be too bullish on the universality of this principle of yours. Unfortunately real life is often more complicated than the scenario you describe and I wouldn't describe the solutions smart people came up with (various consensus algorithms or convergent replicated data types) as a waste of time.