Why do we need to persist QuadTree and care about it’s a recovery?
Our drivers send their location every 3 seconds, meanwhile, they mostly drive around or just staying in one place.
What is the purpose to persist QuadTree into datastore? Anyway, our drivers will send us their geolocation max in 3 seconds.
What is the need to recover QuadTree in a case of failure if we can rebuilt it on the fly when drivers are sending us their locations?
This is true, ideally, since every driver is reporting their geolocation every 3 seconds, the QuadTree could be rebuild from this information. There could be some practical considerations though. As the chapter mentions that we don’t update the QuadTree every time a driver’s report their status (to facilitate our read traffic), hence we might need a few seconds before every driver gets updated in the QuadTree. During this time, what should happen with all the read traffic? This window would be small though, so we might decide to ignore it and let all the read requests wait a bit before the QuadTree become fully available.
looking at this question, i doubt if we need a restriction of 500 vehicles in one grid as in yelp?Because once quad tree is dead and let us say system is up after x mins, the previous data in inavalid and we cannot use it to build our index,if we use we may put drivers in wrong location(previous location).It seems impossible solution how to rebuild when quad tree server fails.backup does not help and new data stream is too fast to build a quad tree. The solution is to partition map and let that partition be static as of now.And we should scale it dynamically base on node,so what we need to backup is mapping of which grid contains which part of map and not the vehicles in backup