5 ms·
Scale really. GoatDB easily handles hundreds of thousands of items being edited in realtime by multiple users
by ofriw 2y ago
Scale really. GoatDB easily handles hundreds of thousands of items being edited in realtime by multiple users
- tkone 2y agoso can couch/pouch? (pouch is a façade over leveldb on the backend and client-side storage in your browser) have you done benchmarks to compare the two? i know from personal experience leveldb is quite performant (it's what chrome uses internally), and the node bindings are very top notch.
- CyberDildonics 2y agoHundreds of thousands of items and multiple users could be done on a $5 PI zero 2 w (1Ghz quad-core A53) with the C++ standard libary and a mutex. People were working at this scale 30 years ago on 486 web servers.
- jaennaet 2y agoI swear we've been going backwards for the past 15 years
- ofriw 2y agoDoing concurrent editing AND supporting offline operation?
- CyberDildonics 2y agoWhat do you mean by "offline operation"? Which part is non-trivial?
- ofriw 2y agoYour server/network goes down, but you still want to maintain availability and let your users view and manipulate their data. So now users make edits while offline, and when they come back online you discover they made edits to the same rows in the DB. Now what do you do? The problem really is about concurrency control - a DB creates a single source of truth so it can be either on or off. But with GoatDB we have multiple sources of truth which are equally valid, and a way to merge their states after the fact. Think about what Git does for code - if GitHub somehow lost all their data, every dev in the world still has a valid copy and can safely restore GitHub's state. GoatDB does the same but for your app's data rather than source code
- CyberDildonics 2y agoSo now users make edits while offline, and when they come back online you discover they made edits to the same rows in the DB. Now what do you do? Store changes in a queue as commands and apply them in between reads if that's what you want. This is really simple stuff. A few hundred thousand items and a few users is not a large scale or a concurrency problem.
- ofriw 2y agoYup. Go ahead and try it, then you'll discover that: - The queue introduces delays so this doesn't play nice with modern collaborative editing experience (think google docs, slack, etc) - Let's say change A set a field to 1, and change B set the same field to 2. GoatDB allows you to easily get either 1, 2 or 3 (sum) or apply a custom resolution rule Your only choices before goat to solve this were: Operational Transformation, raw CRDTs or differential synchronization. GoatDB combines CRDTs with commit graphs so it can do stuff other approaches don't at an unmatched speed