3 ms·
It's always fun the first time. Good luck. Some notes from my experience implementing AP: - Easiest way to support scaling out is pre-sharding an entire datab
by zzzcpan 12y ago
It's always fun the first time. Good luck.
Some notes from my experience implementing AP:
- Easiest way to support scaling out is pre-sharding an entire database at the beginning, so there will be no need to ever reshard it. Like have 16 shards spread manually across all nodes and put into configs which nodes synchronize with which. Once you add another node simply move some shards to that node and be done with it.
- Synchronization is easy with hash/Merkle trees but they don't need to keep in-memory hashes of every single record or recalculate them on insertion or deletion. Instead every time new record is inserted its hash should be added arithmetically to the one stored in particular leaf. Same on deletion, but subtracted arithmetically. No scanning of other records for no reason or anything like that.
- Jitters are super important. Synchronizing data or doing anything periodically will cause lags if you forget to schedule at random times.
- Also, don't forget that random disk accesses are slow and organize your data in such way, that disks are read sequentially for most of the bulk access patterns, like during synchronization.
- marknadal 12y agoThanks! Although I would like to disagree with some of your points: - Sharding is only necessary for centralized systems, where there exists some "Single Source of Truth" of the record. GUN can and will store things in multiple places, so it behaves more like BitTorrent. This reduces the complexity and thus makes the database significantly easier to use and scale, however I had to solve some hard conflict resolution problems to get that to work. - Yes, Merkle trees are awesome. But deletion is a very dangerous action in a database and should be avoided (as noted in the original article). It causes all sorts of potential data-corruption/divergence problems. - All data syncs in realtime, cause GUN sports push notifications. However, if the there is a network partition, the data will sync (without problems) after it is restored. So yes, agreed, don't do things periodically - do them immediately! - Disk access is slow, correct. That is why you should keep as much of the working set in memory. Doing so minimizes disk access, so the majority of your write/read ops are lightning fast. Do you have any links to your stuff?
- zzzcpan 12y agoI'm not gonna argue with your points, just gonna warn you, that you have too much confidence in your algorithms, be careful. > Do you have any links to your stuff? No, it's not open source. Maybe with next implementation I will finally be ready to share it.
- marknadal 12y agoAlgorithms should never be used based on confidence, only whether they work or not. Try them out and let me know your thoughts!