Giving you the truth about MongoDB

Recently, an article was published at TechTarget titled "A side-by-side comparison of MongoDB and Cassandra databases" by Chris Tozzi. The author compares both databases considering the following aspects: High Availability Strategy, Write Speed, Data Structures, and Query Language.

I'm very excited about the fact the more people have been talking and writing about MongoDB, but we have to be extremely careful while publishing something like this on the Internet because no one wants to misinform their readers.

Unfortunately, the article mentioned above has tons of misinformation about how MongoDB works and I would like to clarify and give you the truth about MongoDB.

Let's start with the first aspect analyzed in the article and we will kill two birds with a single stone. About High Availability Strategy, the author says:

MongoDB doesn't ignore the issue of HA, but its strategy is based on the idea of automatic failover. You can only set up one master node in a MongoDB cluster.

That right there is one of the biggest pieces of misinformation in this article. You definitely can have multiple "master" nodes in a MongoDB cluster.

MongoDB has two supported deployment options: (a) Replica Sets and (b) Sharded Cluster. Let's talk about Replica Sets first and then we dive into Sharded Clusters.

A Replica Set is a group of three or more mongod processes responsible for the same data set. The main goal of a Replica Set is to provide data availability.

In a Replica Set, each member has a role and there are three possible roles: Primary, Secondary and Arbiter. The Primary is the member that handles reads and writes to the database. The secondaries are replicas of the database. The arbiters don't hold any copy of the database, they only help the replica set during elections as voters.

An election is when the Replica Set has to choose a new primary. Let's say your current primary has crashed, the secondaries (and arbiter if you have an arbiter in your replica set) will decided who will takeover as the new primary.

[note: Although, by default the primary is the only member that can read and write to the database, MongoDB allows you to read from secondaries. There are a variety of use cases where you could have your application fetching data from the secondaries, but that will be a subject for another post.]

Now that you have a better understanding about what is a Replica Set and how it works at a very high level, let's talk about Sharded Clusters.

A Sharded Cluster is a set of Replica Sets (so, by design it inherits all the data availability capabilities of Replica Sets) where your data will be automatically spread across them. In other words, a sharded cluster is the way you scale out your MongoDB cluster.

Let's go back to the statement made by Chris Tozzi in his article: "You can only set a master node in a MongoDB cluster." The correct terminology is primary node instead of master node and if you've deployed a MongoDB Sharded cluster you definitely can have multiple nodes in your cluster writing/reading data into/from your database.

Yet in the high availability strategy aspect, there is another bit of misinformation in the article regarding to the election process. It doesn't take close to a minute to elect a member as the new primary. Actually, there is a election timeout setting for the Replica Set and the default is 10 seconds.

The second aspect analyzed in the article is Write Speed. He says:

MongoDB's limitation to a single master node also has important implications for the speed at which data can be written to a database.

The author based his analysis on the wrong assumption that MongoDB cannot have more than one node writing to the database. Now you see why I previously said we would kill two birds with a single stone.

The third area Tozzi analyzed is data structure, or data modeling. I don't have any comments about that. It looks like this one he got it right. MongoDB offers a very flexible schema that perfectly fits that way we model objects in the real world.

The final piece of the analysis is about the Query Language. It reads:

MongoDB  has its own query interface. It's basically  JSON formatting, and you can learn it easily enough. But it's not something you're going to know already.

I had never have any issues learning MongoDB's query language. If you have an OOP background it actually comes natural for you. The way you send commands to the database will remind you of calling object's methods, for example db.collection.find(). Besides that, MongoDB has a BI Connector that you can write regular SQL Queries and it will translate it to MongoDB query language.

I hope this post helps to clarify the misinformation provided in the article mentioned above. MongoDB has evolved a lot since 2009. There are some people that tried it in the early releases and might not have had a good experience. But from my own experience with later releases, I can tell you that it is a much better and reliable database.

Thanks for reading.

REFERENCES

[1] "A side-by-side comparison of MongoDB and Cassandra databases" by Chris Tozzi

[2] MongoDB Replica Sets

[3] MongoDB Sharded Clusters