Design Google Map
Last updated
Was this helpful?
Last updated
Was this helpful?
Ref:
Ref:
Ref: 老印的这个视频讲解了 quad tree 和 Hilbert Curve 的一些原理：
Design a google map service
Support display maps for certain cities(San Francisco, Seattle etc)
Support tracking the user movement(GPS, telematics data)
Support routing from place A to place B
Support the place look up service
(Bonus) Tracking of the traffic
(Bonus) tracking of traffic light etc
location service: get location related info that we collect from users
navigation service: communicate with user for navigation
Spark Streaming cluster: All location pings coming into Kafka will be read by a spark streaming service, which can then use this information to add unidentified roads in our data, identify hot spots, identify change in avg speed etc.
graph processing service: processing and rendering map graph to user
area search service: covert locations to coordinates; search given locations
Google Map: 1 billion monthly user
Read/Write Ratio:
Location service: 1 : 1
Navigation service: 1 : 10^5
Graph processing service: 10^5 : 1
area search service: 10^5 : 1
Uber uses a Hexagon to index each of the spatial data
storing 4 points of (latitude, longitude), area, road length, locale, etc.
sample data:
use Graph Database: like neo4j
Cassandra also has GeoSpatial support
use BinTree to store geo data(Store)
Quadtrees are a very straightforward spatial indexing technique.
Each node represents a bounding box covering some part of the space being indexed, with the root node covering the entire area.
To query a quadtree, starting at the root, examine each child node, and check if it intersects the area being queried for. If it does, recurse into that child node. Whenever you encounter a leaf node, examine each entry to see if it intersects with the query area, and return it if it does.
At this point, you can actually throw out the quadtree itself - the node number, or geohash, contains all the information we need about its location in the tree.
Each leaf node in a full-height tree is a complete geohash, and each internal node is represented by the range from its smallest leaf node to its largest one.
Range Query: Thus, you can efficiently locate all the points under any internal node by indexing on the geohash by performing a query for everything within the numeric range covered by the desired node.
Hilbert Curves are part of a class of one-dimensional fractals known as space-filling curves, so named because they are one dimensional lines that nevertheless fill all available space in a fixed area.
One problem with region-based sharding is that the server for a region that is more popular can become overloaded with requests in comparison to servers of regions that aren’t as popular.
new POI's LocationID will be put through a hash function
query proximity places will use an aggregation server to aggregate geohashing server data. (Use Yelp's design graph as an example below)
Support tracking the user movement(GPS, telematics data)
use navigation service, constantly upload location data(latitude, longitude)
Support routing from place A to place B
It has been discussed in neo4j's design: https://neo4j.com/blog/building-spatial-search-algorithms-neo4j/
Dijkstra algorithm, which considers weights. As such, Dijkstra will always find the shortest path based on weights. However, it doesn’t go very fast because it’s searching in all directions. It starts from one side and just searches in all directions until it finally finds the other node.
A* search is more clever. You give it two functions, one for the weights and the other one for a preferred direction Or it’s an additional cross-function, which in our case implies a preferred direction. A Star tends to be much faster.
Support the place look up service
Elasticsearch
Tracking of the traffic
Collect user's upload data for analysis
Ref this
Read this , explaining how to do location based search, route finding, etc.
Ref this doc:
