# Design Google Map
## Design Google Map
> Ref: [Original Video](https://www.youtube.com/watch?v=v2_hv4qIEPc)
> Ref: [系统设计系列讲解 Design Point of Interest (POI) or Nearby Interests](https://1o24bbs.com/t/topic/20416)
> Ref: 老印的这个视频讲解了 quad tree 和 Hilbert Curve 的一些原理：[Food delivery algorithms: Designing a location database](https://www.youtube.com/watch?v=OcUKFIjhKu0)
***
## Requirements
* 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
***
## High-level design
* 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
***
## Traffic
* 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
***
## Database
### Data schema
* Uber uses a Hexagon to index each of the spatial data
* storing 4 points of (latitude, longitude), area, road length, locale, etc.
* Ref this [doc](https://eng.uber.com/h3/)
* sample data:
```json
City: Seattle,
Id: 245324,
Name: "McDonald's",
Address: "1520 Eastlake St"
Location: (latitude, longitude)
```
***
### Database selection
* use Graph Database: like neo4j
* Read this [neo4j spatial search doc](https://neo4j.com/blog/building-spatial-search-algorithms-neo4j/), explaining how to do location based search, route finding, etc.
* Cassandra also has GeoSpatial support
* use BinTree to store geo data(Store)
***
## Algorithms
> Ref this doc: [Damn Cool Algorithms: Spatial indexing with Quadtrees and Hilbert Curves](http://blog.notdot.net/2009/11/Damn-Cool-Algorithms-Spatial-indexing-with-Quadtrees-and-Hilbert-Curves)
### Quadtrees
* 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.
### Geohashes("Z" shape)
* 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("U" shape)
* 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.
***
## Sharding
### Based on the business model with region-based sharding
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.
### Consistent hashing use LocationID
* 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)
***
## Questions
> 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:
* **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
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://liuyang89116.gitbook.io/system-design/chapter-2/google_map.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.