Performance is a key and very vital feature of an application. Ageing of applications , dataload and high throughput are the factors which effect the performance of an application and can bring it down steeply. In this post we will be discussing the Performance aspect in MongoDB.
Increase in datasets and size of data in the server can bring the performance of an application down because of few factors like increase in query execution time which will directly increase the time for which the server remains busy.
Many times we have heard that MongoDB is faster then relation databases. It’s because of the unique way in which Mongo can store the datasets in different data servers and can effectively query them. Mongo uses Sharding to achieve this.
Database Sharding is a highly scalable approach for improving the throughput and overall performance of high-transaction, large database-centric business applications.
Sharding is a unique way of horizontal scaling in which we distribute the data over different servers known as shards. Each shard is a single independent database which can be used to store the datasets. The collection of these shards form a logical database. Chunking down big database into small shards will ensure high availability and data consistency.
How It Works :
In MongoDB, to retrieve the whole entity, Mongo instance follow below procedure:
- One index lookup on the collection (assuming the entity is fetched by id)
- Retrieve the contents of one database page (the actual binary json document)
Possible question arise in mind that how do a Mongo Instance knows that which shard out of many will be containing the relevant dataset which contains the information it is looking for.
When the sharding is done and a cluster of shards is created , all the metadata about the distribution of the datasets is stored in Config servers.
So the Mongo Instance also known as Query routers uses the metadata stored in the config servers to target operations to specific shards.
So this is how we handle Scaling in MongoDB.
Through this partitioning there is a ensured enhancement in the usability of RAM.
Horizontal scaling or sharding automatically handles the load balancing between the shards(Will be next thing).
Load Balancing :
Initially created shards are created with equal sizes but as the chunk size increases there are possibilities of unequal load among shards. May be one shard grows huge in size in comparison to other shards.
This is big problem because if chunk size of a shard increases to a big size then complete concept of sharding will be of no use as only one shard will be getting handling the most execution and others will be relatively free .To overcome such situation MongoDB has a process of maintaining a balance between shards.
A balancer is a entity of MongoDB which is responsible to maintain the balance between shards by transferring chunks from a crowded shard to a less crowded shard.
Balancer transfers a big chunk from a shard(Origin Shard) to another less crowded or relatively free shard(Destination shard). It transfers the documents of Origin Shard chunk to destination shard chunk. Destination shard takes care of the changes done to the documents and implement them to the documents after the migration is done.
What happens to the mapping ? As i told earlier that the information about the address of a document that a MongoDB instance is looking for is stored in the config servers, Now as and when a chunk gets transferred from one shard to another the routing will go off.
Balancer only handles this situation as well , once the migration is done balancer modifies the Metadata ,related to the location of the chunk ,stored in the config server so that it remains relevant.
This is how the performance is scaled in MongoDB.