If you are just starting to learn MongoDB, or using it for the first time this article is for you. I am going to highlight all the important things that I have learned so far. As a MongoDB beginner these items are a must-know.
MongoDB is a document oriented NoSQL database. "Document oriented" means MongoDB stores records as BSON (Binary JSON) documents in collections. If you are coming from relational DBs, think of rows as documents, and tables as collections.
MongoDB is not a drop in replacement for MySQL. In fact you may need to use it in conjunction with MySQL sometimes.
MongoDB community server is free and is available on Linux, Windows, Mac and Solaris.
Once you install MongoDB, you can access the mongo shell by typing
mongowhere you can interact with the databases.
In certain Linux distributions,
mongoshell may fail to start with an error message : "manpath: can't set the locale; make sure $LC_* and $LANG are correct". Run the shell command
export LC_ALL=Cto fix this issue.
To get the best performance out of MongoDB, deploy the server on an SSD based VM. This is because SSDs offer better Random Access performance.
MongoDB caches most recently accessed items in RAM. So, if you are accessing some documents frequently, you may see a boost in speed. Also, make sure your machine has sufficient amount of RAM. More RAM means less page fault and better performance.
You should create appropriate indexes in order to speed up queries. Note that MongoDB by default indexes the automatically generated field
MongoDB 3.0+ supports two storage engines : MMAPv1 and WiredTiger. In case of MMAPv1 (3.0 series), MongoDB acquires a collection level lock while writing. The later one (WiredTiger engine) acquires document level locking. As a result, WiredTiger engine lets you modify multiple documents in a collection simultaneously without worrying about concurrency issues.
As of MongoDB 3.2 WiredTiger is the default storage engine.
MongoDB doesn't support multi document transactions. However, it supports atomic updates in a single document.
You should deploy MongoDB as replica sets in production. Replication is important to make sure you get high availability. If the primary MongoDB server goes down, one of the secondaries will take over as primary.
Replication is not same as backups. If you accidentally delete a database in primary, replication will kick in and all your secondaries will also lose the database. So, you still need to perform backups periodically to make sure you don't suffer from a data loss in case of a catastrophic failure.
To increase the read/write capacity you may take advantage of sharding. But, remember that premature sharding is bad and may further downgrade the performance.
As of now I can think of these points. Let me know if I have missed anything and I'll update the article.