CODEWITHSUNDEEP
mongodbtransactions
vincentsty
vincentsty

Reputation: 3221

Transactional guarantee in mongodb

So, I am doing research on MongoDB, in line with upper management decision to embrace open source and to migrate existing product database from SQL Server to MongoDB and revamp the entire thing. Do note that our database should focus on data consistency and transactional guarantee.

And i discover this post: Click here. A summary of the post is as follow:

MongoDB claims to be strongly consistent, but a lot of evidence recently has shown this not to be the case in certain scenarios (when network partitioning occurs, which can happen under heavy load). This means that you can potentially lose records that MongoDB has acknowledged as "successfully written".

In terms of your application, if you have a need to have transactional guarantees (meaning if you can't make a durable write, you need the transaction to fail), you should avoid MongoDB. Example scenarios where strong consistency and durability are essential include "making a deposit into a bank account" or "creating a record of birth". To put it another way, these are scenarios where you would get punched in the face by your customer if you indicated an operation succeeded and it didn't.

So, my question is as follow:
1) To what extend does "lost data" still valid in current version of MongoDB?
2) What approach can be take to ensure transactional guarantee in MongoDB?

I am pretty sure that if company like PayPal do use MongoDB, there is certainly a way of overcoming these issue.

Upvotes: 0

Views: 784

Answers (2)

Sammaye
Sammaye

Reputation: 43884

The references in that post have been discussed here before (for example, here is one: MongoDB: Does Write Concern guarantee the write on primary plus atleast one secondary ). No need to duplicate your question.

The blog "Aphyr" mostly uses these articles to tout it's own tech (if you read the entire blog you will realise they have their own database which they market). Every database they show loses data except their own.

2) What approach can be take to ensure transactional guarantee in MongoDB?

I agree you should be handling database problems in client code, if not then how is your client side ever going to remain consistent in the event of partitions?

Since you are not Harry Potter (are you?) I will say that you need to check for exceptions thrown in your client code and react to them as needed.

1) To what extend does "lost data" still valid in current version of MongoDB?

As for the bug he mentions in 2.4.3: he fails (as I mention in the linked post) to state the bug reference so again, no comment still.

Besides 2 writes in 6,000? That's less data loss than I have seen in MySQL on a partition! So not too shabby.

I have not noticed such behaviour in my own app and, from small to extremely large sites, I have not noticed anyone reproduce benchmark type scenarios as displayed in that article, I doubt very much you will.

I am pretty sure that if company like PayPal do use MongoDB, there is certainly a way of overcoming these issue.

They would have tight coding to ensure consistency in distributed environments.

Of course, they would start by choosing the right tech for the situation...

Upvotes: 1

Ebubekir Dirican
Ebubekir Dirican

Reputation: 386

Write Concern Reference

Write concern describes the level of acknowledgement requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters. In sharded clusters, mongos instances will pass the write concern on to the shards.

https://docs.mongodb.org/v3.0/reference/write-concern/

Upvotes: 0

Related Questions