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

191–200 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#191

Post by matthewmacleod »

Thaxll wrote: post #167
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

"passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Fortnite uses MongoDB for everything, they have a huge load ( 7.5M CCU is insane ) and don't have more problems than if they choose something else. MongoDB gets bad press on Reddit / HN probably because of past marketing campaigns, but nowdays it's a very solid solution.

You can use Citus, as others have mentioned, or something like BDR – but bear in mind that vanilla Postgres will happily do big pile of hot standby servers for scaling reads, and will scale vertically very well.

You might have a case in which you need something faster – I'd argue that there are still better solutions, but YMMV.

Re: Was MongoDB Ever the Right Choice?

#192

Post by matthewmacleod »

zjaffee wrote: post #171
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

I have to absolutely disagree with the point you're making about mongodb never being something an experienced developers should use. An experience developer understands when the goal is to deliver something as fast as possible vs building something more resilient. If you're building an internal tool, particularly one that won't be storing data that would later be used for analytics, there's absolutely no reason to no…

You could be saving at least 20% of the time spent not having to worry about a datamodel.

You are not "not worrying about a datamodel" – you are just ignoring the data model that exists. And that overhead, if it exists at all, is far less than "20%".

Re: Was MongoDB Ever the Right Choice?

#193

Post by duxup »

Scarbutt wrote: post #189
duxup wrote: post #157

Earlier quoted context omitted.

As a n00b when it comes to web development I've sort of given up on fretting more than "too much" about "Is this the best way?" and focused on "let's try some stuff and it doesn't work I'll learn from it and make a better choice when I come to it". There seems to be a cost associated with evaluating optimal paths. Personally I get SQL (well enough to use it) and I can work with so I don't bother with MongoDB much, bu…

Perfect is the enemy of good. I know this but I keep ignoring it ¯\_(ツ)_/¯

That and sometimes what you think is perfect ... isn't always it.

I've gotten time to make something polished and perfect and came out with "uh you know that first run prototype ... might be better in some ways".

Re: Was MongoDB Ever the Right Choice?

#194

Post by matthewmacleod »

ex_ex_nihilo wrote: post #158
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.

In what situations do you feel MongoDB is a better solution than Postgres? The latter is both relational and document-oriented as required.

Re: Was MongoDB Ever the Right Choice?

#195

Post by ex_ex_nihilo »

zkomp wrote: post #182
ex_ex_nihilo wrote: post #158

Earlier quoted context omitted.

Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.

But postgres actually is that with json and jsonb. The postgres developers are also very focused on providing a better alternative to mongo. Afaik similarly configured postgres also challenge or beat mongodb in performance.

Cool thanks, I did not know about that.

Re: Was MongoDB Ever the Right Choice?

#196

Post by Fins »

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…

I have to say that when I worked with MUMPS (and even then MUMPS was older than anyone who thought up Mongo) we've never lost any data.

Too bad GlobalsDB went nowhere...

Re: Was MongoDB Ever the Right Choice?

#197

Post by kdbeall2 »

StavrosK wrote: post #105
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

In my experience, when there's something that offers additional guarantees for additional work, it's very rarely the right solution to completely forgo the guarantees. This goes for schemas, typing in languages, etc. Maybe the additional work is too much for the benefit, but it's not that there's no benefit. Forgoing the guarantees usually leads to much more extra work. I think Python's "no types anywhere" was a reac…

> I think Python’s “no types anywhere” was a reaction to Java’s “types everywhere”

To nitpick, Python actually came before Java. But, the overall sentiment is something I agree with.

Re: Was MongoDB Ever the Right Choice?

#198

Post by StavrosK »

kdbeall2 wrote: post #197
StavrosK wrote: post #105

Earlier quoted context omitted.

In my experience, when there's something that offers additional guarantees for additional work, it's very rarely the right solution to completely forgo the guarantees. This goes for schemas, typing in languages, etc. Maybe the additional work is too much for the benefit, but it's not that there's no benefit. Forgoing the guarantees usually leads to much more extra work. I think Python's "no types anywhere" was a reac…

> I think Python’s “no types anywhere” was a reaction to Java’s “types everywhere” To nitpick, Python actually came before Java. But, the overall sentiment is something I agree with.

Oh yeah, that's not nitpicking, that's a good point. Replace "Java" with any type-verbose language of the era.

Re: Was MongoDB Ever the Right Choice?

#199

Post by chrshawkes »

Thaxll wrote: post #167
matthewmacleod wrote: post #30

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…

"passable clustering" you talk about PG which has nothing, so when you start to re-implement sharding yourself you're in trouble. Fortnite uses MongoDB for everything, they have a huge load ( 7.5M CCU is insane ) and don't have more problems than if they choose something else. MongoDB gets bad press on Reddit / HN probably because of past marketing campaigns, but nowdays it's a very solid solution.

Compass is a solid product shipping with Mongo these days as well. I missed having something like that many years ago when first trying Mongo.

Re: Was MongoDB Ever the Right Choice?

#200

Post by aeorgnoieang »

scarface74 wrote: post #144
jacques_chester wrote: post #73

Earlier quoted context omitted.

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.

All the SQL databases with which I'm familiar support large string columns. What's the downside to just stuffing your schema-less or volatile-schema data in one of those?
Post reply on HN