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

161–170 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#161

Post by jstimpfle »

arethuza wrote: post #39
jstimpfle wrote: post #38

Earlier quoted context omitted.

As a serialization format, JSON is horrible. Way too loose regarding formatting and way too much noise. All that is typically needed is a standard text format for relational data. I.e. a fixed CSV. The only "advantage" to JSON is that it maps directly to the object trees most developers use in their scripted programs (which is misguided IMHO).

Not sure I would call CSV a "standard text format" - I've seen many many problems over the years with badly formed CSV files and bad Unicode handling. CSV appears to be an "almost standard" where 98% of the time it is fine and the remaining 2% are an utter nightmare.

Yes, CSV in the wild is an absolute mess. It was made an RFC standard at some point but even that was quite unclear if I recall correctly. That's why I wrote "a fixed CSV".

Re: Was MongoDB Ever the Right Choice?

#162

Post by harunurhan »

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.

Postgres has JSON support. In fact Amazon's documentdb which is alternative to Mongo, is built on top of Postgres AFAIK.

Re: Was MongoDB Ever the Right Choice?

#163

Post by Jean-Philipe »

a13n wrote: post #52

These "caveats" are mostly false, or outdated. > Loss of transactions MongoDB 4.0 supports ACID transactions: https://www.mongodb.com/transactions > Loss of relational integrity (foreign keys) > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. I've never seen anyone use MongoDB without also using something like Mongoose where you get all…

> > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. > I've never seen anyone use MongoDB without also using something like Mongoose where you get all this for free. Zero work for your engineers.

For me, Mongoose is actually another argument against MongoDB. It's basically trying to add basic functionality on top of MongoDB, that most RDMS already have.

And no, it does actually not "all of that", just some of it. Just an example: Mongoose would still let you delete a user, while all of the related posts are remain with broken references to that user.

> Can you give an example of something that you realistically would want to do in SQL that you can't with a JSON query?

Sure everything can be done, it's just clunky and hard to get right. This graphic perfectly summarises the horror of writing simple queries in MongoDB: http://twiki.org/p/pub/Codev/TWikiPresentation2016x07x14Mong...

I've been using Mongoose in production for several years, 2011-2014 and again for the last 12 months, within teams of 4-8 developers. The amount of engineering, bug fixing and testing was definitely higher in MongoDB than with MySQL or Postgres.

Once I got to work with MySQL and Postgres after 2014, I found it so much easier to query for the data I'm looking for and to ensure data strong consistency, mind you, even without any use of a library!

Re: Was MongoDB Ever the Right Choice?

#164

Post by scarface74 »

TimFogarty wrote: post #160
scarface74 wrote: post #145

Earlier quoted context omitted.

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.

Thank you! As an aside, is there a reason you're not using a write concern of "majority"? If you have w:3 in a three node cluster then if one node goes down, writes are going to start throwing wtimeout errors (assuming you have wtimeout set) even though the data may safely be written to a majority of nodes. We generally recommend setting w:"majority" for this reason.

It was recommended by our vendor. I asked why, he was just paranoid. But, most of the data was entered on a semi connected mobile device, stored on the handheld and synced when they had service. If it wasn’t immediately writable to the server, it wasn’t a show stopper.

Re: Was MongoDB Ever the Right Choice?

#166

Post by alexandercrohde »

TimFogarty wrote: post #139
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.

Plenty of people are successfully using MongoDB for real, customer supporting data at a large scale. There's a selection of users on the website for a start: https://www.mongodb.com/who-uses-mongodb (Disclaimer: I work for MongoDB)

But we'll never know if those companies will be better off if they hadn't. You're just making a bandwagon argument

(Disclaimer: I hate MongoDb)

Re: Was MongoDB Ever the Right Choice?

#167

Post by Thaxll »

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.

Re: Was MongoDB Ever the Right Choice?

#168

Post by dankohn1 »

JustSomeNobody wrote: post #125

Man, I remember the Mongo craze. You couldn't have a rational discussion about databases with some of the most rabid supporters. I made a comment on a post yesterday about tech having those few early and loud supporters who shut down any conversation that doesn't support their chosen technology. The Mongo craze was like that early on. It was really frustrating not being able to look at other databases when everyone w…

If you haven't watched it recently, this was always my favorite look at "MongoDB is web scale": https://www.youtube.com/watch?v=b2F-DItXtZs

Re: Was MongoDB Ever the Right Choice?

#169

Post by [deleted] »

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…

[deleted]

Re: Was MongoDB Ever the Right Choice?

#170

Post by golergka »

ohaideredevs wrote: post #113

The main use case for MongoDB I have seen are custom forms or data that can be nested a variable number of times. The main problems I have had with MongoDB were that, as of several years ago, it did not integrate well with most (I would argue any in practice) data reporting / displaying third parties. Also, some of the more advanced queries were not at all intuitive. In fact, I barely remember any of the syntax now.…

> data that can be nested a variable number of times

I'm far from a SQL expert and have mostly done client-side work in my life, but SQL-based database does seem like a good match for things like these. You just need to write more foreign key relations, and constraints are a bit more complicated, but I see no reason to switch to NoSQL for things like these.

Post reply on HN