Hacker News Reader

Comment by jandrewrogers | Hacker News Reader

My anecdote: several years back I had a test lab for measuring the performance and scalability characteristics of various geospatial databases. We added MongoDB to the mix a couple years after they released geospatial support.

We always verified basic correctness with a new database by inserting several billion geometries as fast as the database would accept them, reading the entire data set back out, and comparing it to the original data set we inserted for any discrepancies. MongoDB never passed this test. It would apparently lose records semi-randomly every time, so we removed it from the test set. It was the only database we tested that had this issue.

View on HN

I evaluated several distributed databases for a healthcare-related system. The ability to lose messages in sharding scenarios, and the specifics of how one would recover them, made me think I could never support MongoDB for anything more serious than Reddit.

The Jepsen tests [1] have been run against MongoDB - while older versions presented edge-case opportunities for data loss, that's no longer the case with recent versions. The Jepsen tests also specifically test sharded clusters. From Aphyr's report:

> MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments.

These tests are now integrated into MongoDB's regular test suite. Maybe MongoDB wasn't the right choice for you at the time you were evaluating it, but I just want to point out that MongoDB has matured and improved a great deal.

(Disclaimer: I work for MongoDB)

[1] https://jepsen.io/analyses/mongodb-3-6-4

Wasn't it only has of version 3.4 that Jepsen stopped finding single-node data loss bugs in MongoDB? So it's been 3 years that MongoDB has been suitable for single-node data storage, and apparently 5 months that it's been reasonable to use in a sharded deployment.

Perhaps in another decade, MongoDB can shed its well-earned reputation for eating data.

I think it's fair to say that it might take some time to regain trust. Just want people to know that the software is being improved and large strides have been made in this area.

The thing is, it's too late. When MongoDB was in its heyday, it got known as something that loses records. Not much you can do now when for every post affirming its consistency, there are two about how someone tested it and it failed consistency checks.

I'm not disagreeing with anybody else's test results. Just want to say that MongoDB has matured a lot and people should test out the newer versions to see how they fare.

Kind of in line with the article, I think that people should methodically check what works for them... particularly for something as serious as a database. It would be a shame if somebody decided against using something because they heard about an issue that has been fixed and/or improved in more recent versions.

> people should test out

Why should they, though? The fault here is on its management team. Users and clients lost their trust, for good reasons.

I never used MongoDB, but I know people that got in real trouble due to it.

FWIW, the data loss I was referring to happened on a single node. There may have been issues in a distributed environment as well but we never got there.

When did you perform the test? Can you remember what MongoDB version you were using?

You are aware that 10gen state clearly that single node is not supported for production deployments. And that a replica set is required.

Reply on news.ycombinator.com