replication is easy, sharding is very easy too.
MongoDB provides high availability with replica sets. A replica set consists of two or more copies of the data. Each replica set member may act in the role of primary or secondary replica at any time. All writes and reads are done on the primary replica by default. Secondary replicas maintain a copy of the data of the primary using built-in replication. When a primary replica fails, the replica set automatically conducts an election process to determine which secondary should become the primary. Secondaries can optionally serve read operations, but that data is only eventually consistent by default.
MongoDB scales horizontally using sharding. The user chooses a shard key, which determines how the data in a collection will be distributed. The data is split into ranges (based on the shard key) and distributed across multiple shards. (A shard is a master with one or more slaves.). Alternatively, the shard key can be hashed to map to a shard – enabling an even data distribution.
MongoDB can run over multiple servers, balancing the load or duplicating data to keep the system up and running in case of hardware failure.
MongoDB can be used as a file system, called GridFS, with load balancing and data replication features over multiple machines for storing files.
This function, called grid file system, is included with MongoDB drivers. MongoDB exposes functions for file manipulation and content to developers. GridFS can be accessed using mongofiles utility or plugins for Nginx and lighttpd. GridFS divides a file into parts, or chunks, and stores each of those chunks as a separate document.
MapReduce can be used for batch processing of data and aggregation operations.
The aggregation framework enables users to obtain the kind of results for which the SQL GROUP BY clause is used. Aggregation operators can be strung together to form a pipeline – analogous to Unix pipes. The aggregation framework includes the $lookup operator which can join documents from multiple documents, as well as statistical operators such as standard deviation.
MongoDB is not relational so you lose all the capabilities of relational databases.
No joins. You design as if they were never an option.
It scales well in a narrow range but other NoSQL solutions are better at scaling. Sharding is annoying, complex and seems like it was bolted on.
It uses eventual consistency, which is good and bad.
No transactions except at the record level. If you want a transaction you have to fit the whole transaction into a single record.
Hard to secure properly without going with an Enterprise license.
There is no patching, you have to do full upgrades and full upgrades are issued several times a year. So you have to build a patch schedule around those. There is no guarantee that your upgrade will work with your given driver so tests must be scheduled before upgrading.