Top 3 Reasons to upgrade to MongoDB 3.4
Tags: mongodb34
Published: 2017-05-02 16:29:40

---
title: Top 3 Reasons to upgrade to MongoDB 3.4
published: true
description: Top 3 Reasons to upgrade to MongoDB 3.4
tags: mongodb34
---
MongoDB 3.4 was released on Nov 29, 2016 withÂ <a style="font-size: 16px; font-weight: 400;" href="https://docs.mongodb.com/manual/release-notes/3.4/">tons of new features</a>.Â In this post, I will be listing the top 3 reasons to upgrade to MongoDB 3.4.
<h2><a href="https://docs.mongodb.com/manual/release-notes/3.4/#faster-balancing">Faster Balancing</a></h2>
In the previous releases, it takes ages(4s per chunk, last I seen in 3.2.10) for the balancer to move or pre-split chunks. Imagine if you have 100,000 chunks to pre-split, it's going to take days. There are 2 reason for this:
<ol>
	<li>In a sharded cluster, there can only be 1 chunk migration at any point of time. It's a single threaded operation</li>
	<li><a href="https://jira.mongodb.org/browse/SERVER-26778">This</a>.</li>
</ol>
In MongoDB 3.4,Â for a sharded cluster with n shards, MongoDB can perform at most n/2 (rounded down) simultaneous chunk migrations. So, if you have a 4 shard MongoDB cluster, it will migrate 2 chunks at a time! If you have lesser than 4 shards, the behaviour will stay the same unfortunately. :(
<h2><a href="https://docs.mongodb.com/manual/release-notes/3.4/#linearizable-read-concern">Linearizable Read Concern</a></h2>
In general, MongoDB has various <a href="https://docs.mongodb.com/manual/reference/read-concern/#read-concern-levels">readConcern option</a>. These options allow the developers to choose different readConcern suitable for their application requirement. Do useÂ readConcern:local for unimportant queries that doesn't careÂ if it reads data that could be rolled back. Using readConcern:majority preventsÂ readingÂ data that can be rolled back. However, it does not prevent you from reading stale data in unique network partitions edge cases.

In MongoDB 3.4, usingÂ readConcern:linearizable allows you to prevent stale reads too. This featureÂ is not free and has the highest performance overhead.Â readConcern:local only require 1 operation to return your results.Â readConcern:majority requires a majority acknowledgement from a majority of the nodes in your replica set which depends on your network latency.Â readConcern:linearizable requires an additionalÂ no-op majority write to the replica set to ensure the data being read is durable and not stale.

In essence, what readConcern:linearizable does is the <a href="https://jira.mongodb.org/browse/SERVER-24497">following</a>:
<ol>
	<li>Client sends query to primary node</li>
	<li>Node gets the results without erroors</li>
	<li>Node sends a noop majority write to the other nodes in the cluster to confirm that it is still the primary node.</li>
	<li>Results gets returned to the client</li>
</ol>
<h2><a href="https://docs.mongodb.com/manual/reference/configuration-options/#net-compression-option">Network Compression</a></h2>
I'm not sure why this wasn't publicise widely as a new feature. I like it a lot because, now all the traffic between mongos/mongod are compressed so we save on bandwidth. This really saves you lots of money if you are running it on AWS or if you are constrained by the network bandwidth.
<h2><span style="text-decoration: underline;">Summary</span></h2>
In general, I do agree with <a href="http://www.infoworld.com/article/3180620/application-development/review-mongodb-learns-cool-new-tricks.html">infoworld</a> that MongoDB 3.4 is a no-brainer upgrade! We are currently waiting on it to be available on our O/SÂ of choice so we can start rolling it out!

Hope this helps! :)

Regards,
Wei Shan