How MongoDB Boosted LBS Query Performance by Over 10×

Background

Location‑based services (LBS) such as bike‑sharing, umbrella‑sharing and power‑bank sharing generate two characteristic workload patterns: strong periodic traffic spikes (peak vs. off‑peak) and highly uneven geographic point distribution (dense clusters around transit hubs, sparse elsewhere). Native MongoDB geoNear queries, while convenient, can suffer severe latency degradation under these conditions.

MongoDB 2D Index

MongoDB creates geographic indexes with either 2d (planar) or 2d_sphere (spherical) types. The index precision is controlled by the bits option; higher values increase resolution with negligible insert overhead. Example:

db.coll.createIndex({ "location": "2d" }, { "bits": 26 })

With the default 26‑bit precision the index resolution is about 0.57 m (≈2 ft).

Index Internals

MongoDB builds a GeoHash using a planar quadtree. Each document receives a 52‑bit GeoHashId that serves as the B‑tree key, mapping GeoHashId → Record. The same 2d index can be interpreted as a flat grid ( spherical: false) or as a latitude/longitude grid ( spherical: true) at query time.

Typical geoNear Query

db.runCommand({
  geoNear: "places",
  near: [-73.9667, 40.78],
  spherical: true,
  query: { category: "public" },
  maxDistance: 0.0001531,
  num: 10
})

The command expands outward in concentric rings, returning the nearest N points. Ring expansion reduces the number of points that need sorting, but when inner rings contain few matches and outer rings are dense the algorithm scans many irrelevant points (the “BadCase”).

Observed Performance Problems

During peak hours some customers experienced 10‑20× higher QPS than off‑peak, while a 500 m radius geoNear query touched >24 000 records and took ~500 ms. Profiling ruled out lock contention; the bottleneck was CPU/IO caused by excessive point scans.

Root Cause: Large Scan Sets

The ring‑expansion algorithm doubles the radius when the current ring does not yield enough results. In dense urban areas (e.g., subway stations during rush hour) this leads to scanning thousands of points far from the query centre, dramatically increasing latency.

Optimization – Controlling Scan Size

The MongoDB team added two parameters to the geoNear command:

hintScan : stop scanning once the scanned point set exceeds this threshold, then fall back to a fuzzy result.

hintCorrectNum : guarantee that at least this many exact nearest‑neighbor results are returned before fuzzy handling begins.

These knobs let callers trade strict ordering for faster responses, which is acceptable for most LBS scenarios where exact ranking is not critical.

Performance Gains

Enabling hintScan and hintCorrectNum increased single‑node MongoDB throughput for dense LBS workloads from ~1 000 QPS to >10 000 QPS (≈10×) without observable loss of functional correctness.

Comparison with Redis 3.2

Redis 3.2 provides geo queries via GEORADIUS:

GEORADIUS appname 120.993965 31.449034 500 m COUNT 30 ASC

Benchmarks on a 24‑core machine showed MongoDB’s multi‑threaded, persistent engine outperformed Redis’s single‑threaded in‑memory engine for dense datasets, while also offering higher availability.

Conclusion

Native MongoDB geoNear remains the mainstream choice for Chinese LBS services. By adding scan‑size hints the cloud MongoDB team eliminated the BadCase slowdown, delivering >10× throughput gains and robust support for large‑scale LBS platforms.