MongoDB size management
summary
Shows concrete steps to cut MongoDB footprint and what actually worked: migrate to WiredTiger with Snappy drops some collections from ~1 TB to ~100 GB (single-collection examples), but increases CPU and needs staged testing, replica priority changes and monitoring via MMS/New Relic. Use TTL index when a date field exists, or delete by ObjectId in controlled batches (3k–5k ids) for large history. To reclaim disk space run compact/repair (requires downtime and ~2x free space) or do a resync secondary rebuild by wiping a secondary and letting it replicate.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:14Outline
- 0:37MongoDB Cluster Architecture
- 1:22Advantages To Reduce Data Size
- 1:58Migrate To Wired Tiger
- 3:27Wired Tiger VS MMAPv1
- 3:46Things to Consider Before Migration
- 7:05WiredTiger Migration Procedure
- 9:15Compression Ratio After Migration (Lise Wired Tigersnappy compressor)
- 10:10Set TTL Index On Timestamp Field
- 12:04TTL Index Notes
- 12:52Purge data Using _id field
- 13:47Sample script for Purge
- 14:23Purge Large Volume Collections
- 17:29Reclaim Deleted Space After Purging
- 19:18Summary
related talks
51m5 boring performance improvements in MongoDB 3.4 that matter
46mUnderstanding and tuning WiredTiger
47mSchema design for fast applications
46mUnderstanding and tuning WiredTiger
40mData Migration Lessons from the Trenches
44mMongoDB: optimize your indexing
40mMongoDB Backups Overview
24mTSDB Data Compactions on Scale Without Headache: Now & Future