In and Out of the Weeds With MongoDB 4.4 Hedged Reads
summary
Hedged Reads in MongoDB 4.4 claims to cut tail latency by sending reads to multiple replicas and returning the fastest result; mongos picks eligible secondaries by ping time, calculates a default latency window 15 ms, routes one read, then fires a duplicate and cancels the slower one when the first returns. Setup requires enabling hedging on mongos and non-primary read preferences; defaults include maxTimeMS 150 ms. ServerStatus exposes hedged counters. Tradeoffs: extra host load, potential staleness and nonmonotonic reads, only non-primary reads.
AI-written summary · about
chapters (8)
- 0:00Start
- 5:58High Latency - Lost Revenue Three Seconds = Magic Cut-off Point
- 9:09Basic MongoDB Architecture - Single Replica Set
- 9:44Sharded Cluster Architecture
- 11:38Read Preference Mode
- 13:10How Hedged Reads Work - Simplistic View
- 14:03How Hedged Reads Work - Explained
- 18:09Hedged Reads Diagnostics - AKA serverStatus to the Rescue The command serverStatus and the mango shell method db.serveStatus() return hedgingMetrics for the mongos only (starting in 4.4 of course)
related talks
51m5 boring performance improvements in MongoDB 3.4 that matter
36mUnderstanding all the Options for Replica-sets and Replication Patterns
25mHybrid Applications with MongoDB and RDBMS
32mA New Sharding Architecture for MongoDB
28mComparing MongoRocks, WiredTiger and mmapv1 for performance and efficiency
47mSchema design for fast applications
29mMulti Active-Active and disaster recovery with MongoDB database center
24mWhen and How Should you Shard?