Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Was MongoDB Ever the Right Choice?

simplethread.com

Post reply on HN
Print view View original

141–150 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#141

Post by tinco »

tgtweak wrote: post #117
skywhopper wrote: post #106

As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…

You and I must be the only ones on HN using mongo at scale and enjoying it. We use it as an event database which collects over 100M+ semi-structured records daily with about 200 (and growing) different schemas... It keeps 1.5TB of records in the collection which is achieved using the invaluable capped collection function, and we can index the structured fields very easily. We also pipe the data into elastic for quick…

My project as well, sharded over 4 nodes, ingesting about a TB every two weeks. Automatic deletion of old data was too slow so we had to work with a scheme that allowed us to drop daily collections, but beside that it ran great. This was 6 to 3 years ago though. Maybe there's a better log stash out there now? I haven't seen one yet.

Re: Was MongoDB Ever the Right Choice?

#142

Post by TimFogarty »

jandrewrogers wrote: post #128
TimFogarty wrote: post #61

Earlier quoted context omitted.

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 was…

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?

Re: Was MongoDB Ever the Right Choice?

#143

Post by mailslot »

I went to production with Mongo and it exceeded my expectations. It operated without a single issue for years under high load. It was a dream to administer and a vital piece of a multimillion dollar franchise.

Everybody else I know, however, has had nothing but headaches.

They’re the same reasons I’ve seen people fail at using Cassandra, Redis, or Spanner. If you can’t adjust to the limitations and paradigm shift, you get no benefits. And an ORM often makes everything worse.

The “no” in NoSQL doesn’t seem to stop people from modeling join relationships in Redis, or chaining distributed queries with fully consistent writes on Cassandra.

I’m on a project right now, where a developer has selected an ORM for PostgreSQL that forgoes joins. They’ve managed to generate about 100 queries, in one case, where a single query is all that’s needed. 2ms vs. 800+ms. That individual is incapable of using something more complicated. Substituting Mongo as-is will make everything worse, and they’ll triumphantly proclaim how terrible NoSQL is and then write an article.

I feel confident using Mongo for any task. I don’t feel confident letting most of my peers use it.

There are a LOT of legitimate gripes, but no article I’ve read mentions them. It’s always the same superficial complaints from ten years ago. If you can’t get past those, choose another tool. End. Of. Story.

Re: Was MongoDB Ever the Right Choice?

#144

Post by scarface74 »

jacques_chester wrote: post #73
mattparlane wrote: post #8

I'm still in charge of a production system serving around 2,000 small to medium websites from a 2-machine MongoDB cluster. It's been running on MongoDB since around 2010 and we have NEVER had any issues. I accept that the unacknowledged writes was a bad decision, but IMHO if you deploy a new database without reading the documentation, you have bigger issues. The reality is that there are some places where speed of mo…

1. Writing DDL is not hard. It's just not very hard. 2. You can go from strict guarantees to looseness safely, when you demonstrably need to. The reverse isn't true -- it's easy to wind up realising, much too late, that you actually needed particular guarantees that you didn't even think of. Relational databases didn't become incredibly popular by accident. It's because they were a drastic improvement -- theoreticall…

Writing DDLs are hard when you don’t know in advanced what the schema is or the schema is changing frequently.

A lot of things “become popular” but that doesn’t necessarily mean they are good.

Re: Was MongoDB Ever the Right Choice?

#145

Post by scarface74 »

djhaskin987 wrote: post #135

I've only ever heard of mongo successfully used for two use cases: 1. As a cache, like redis 2. As a log store, like Elasticsearch In both cases, the data is somewhat ephemeral, and not the "source of truth" for the app. The minute it is used for holding real, customer supporting data, things start to get dire real fast.

I have used Mongo to store medical data that had to be stored for 7 years. We set it to make sure that all three servers in the cluster did a write acknowledgement.

Re: Was MongoDB Ever the Right Choice?

#147

Post by scarface74 »

geezerjay wrote: post #29
mruts wrote: post #15

Earlier quoted context omitted.

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

> Why not just use a SQL db that handles json and stick everything in a couple columns? Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.

You just answered your own question. If I’m only working with objects, why wouldn’t I just store everything as objects?

And most ORMs suck outside of LINQ based ones since they aren’t a part of the language.

Re: Was MongoDB Ever the Right Choice?

#148

Post by TimFogarty »

joncrane wrote: post #110
TimFogarty wrote: post #61

Earlier quoted context omitted.

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 was…

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.

Re: Was MongoDB Ever the Right Choice?

#150

Post by TimFogarty »

aaron42net wrote: post #109
TimFogarty wrote: post #61

Earlier quoted context omitted.

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 was…

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.
Post reply on HN