Experience with MongoDB and Optimizations

 

Experience with MongoDB and Optimizations

• Before reading below. I would like to point out that this experience is related to version 6.0.14-ent, having 6 shards, each shard having 3 machines, each machine is VM with 140 GB RAM and 2TB SSD. And, we had been hosting almost 36 TB of data.

• MongoDB is not good with Big Data Joins and/ or Big Data OLAP processing. It is mainly meant for OLTP purposes. 
• Instead of joining millions of keys between 2 collections. It is better to lookup data of one key from one collection then lookup it in other collection. Thus, merging data from 2 collection for same key.
• Its better to keep De-normalized data in one document. 
• Updating a document later is cumbersome. 
• MongoDB crash if data is overloaded. And, it has long downtime if crashed unlike other databases which fails write to database if disk space achieves certain limit. Thus, keeping database active and running for read traffic.
• MongoDB needs indexes for fast querying, and indexing can take long time based on size of data.
• Reading one MongoDB collection and writing to another MongoDB collection can be very slow. To make it fast- one can utilize distributed computing framework like Spark but that leads to data loss scanning full MongoDB collection.
• Indexes occupy space if data is big. 
• Always use Sharding. Range Sharding should be avoided because it leads writes going to one shard when bulk data is loaded. Hash Sharding distrubutes write traffic better among shards. 
• Note that Chunks can grow in size to a high value in MongoDB. As MongoDB do not care about number of Chunks rather it relies more on equal distrubution of data ( size) among shards. 
• Theoretically, MongoDB says there is no limit to size of collection. But we have seen that as collection size grows above 2 TB - writes to collections slows down. So, it's better to have 12 collections for 1 year rather having 1 collection with 12 years of data.
• Having multiple collections instead of one can also be advantageous from API application perspective as well. Rather than querying one collection. Application can concurrently fire same query to multiple collections and merge there results. Thus, optimizing response time. 
• Breaking collection also resolves time it would take build indexes on collection. Also, gives fail safety that in worst case one collection can go bad, not all 12 collections will screw up. 
• It’s always good practice to ensure connection pool on MongoDB. So, as to not over-utilize TCP pool which in turn can hinder I/O operattions. 
• MongoDB by default will have unique index on _id. If possible, try to utilize same for shard key or unique index to avoid an additional index. 
• Note that you may not specify a unique constraint on a hashed index.
• Starting in MongoDB 7.0.3 (and 6.0.12 and 5.0.22), you can drop the index for a hashed shard key. This can speed up data insertion for collections sharded with a hashed shard key. It can also speed up data ingestion when using mongosync.
• It's better to bulk load collections then built indexes on same. Rather than running bulk load on collection which has all the indexes.