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

Never, ever, ever use MongoDB

cryto.net

Post reply on HN
Print view View original

71–80 of 122 posts

Re: Never, ever, ever use MongoDB

#71

Post by foobarian »

joepie91_ wrote: post #21
_pdp_ wrote: post #6

I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. I've got nothing against relation databases but there are not a solution to every single problem. Heck, why not decide first if you can use flat files? Do you really need to query and join. Not all problems require that sort o…

> I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. The issues I listed provably exist. That you haven't run into them yet doesn't change that - and quite likely, you might not even know whether you've run into it. Losing data or having your database open to the wide internet…

If nothing else psql has a nice tabular output. Sometimes I go out of my way to import something into a local pg instance just so I can format things using psql.

Re: Never, ever, ever use MongoDB

#72

Post by cheald »

joepie91_ wrote: post #50
cheald wrote: post #35

Earlier quoted context omitted.

That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.

This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of init…

Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that.

It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.

Re: Never, ever, ever use MongoDB

#73

Post by joepie91_ »

djacobs wrote: post #68
joepie91_ wrote: post #57

Earlier quoted context omitted.

> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'. In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have…

I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.) Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.

Realistically, though, almost always at least some portion of your hacks makes it into production. And if you're saving 10 minutes for 5 hours lost, then even at a going-into-production-rate of 10%, it's still not worth it.

Hacks that remain hacks in 100% of the cases, are rare :)

Re: Never, ever, ever use MongoDB

#74

Post by joepie91_ »

cheald wrote: post #72
joepie91_ wrote: post #50

Earlier quoted context omitted.

This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of init…

Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially…

> It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time.

All the wrong places, as already stated. These are not the places where developers actually look. I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072

> [...] in the blog posts [...]

Certainly not there. Go look around for MongoDB tutorials from the timespan where unacknowledged writes were the default, and almost none of them remark on the 32-bits limitation.

> If you missed it, it's probably because you weren't paying attention.

Nonsense. It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today).

> Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.

If pointing out extremely dangerous past negligence from the MongoDB developers "degrades my credibility" in your view, then you have some very strange ways to determine credibility.

Re: Never, ever, ever use MongoDB

#75

Post by PebblesHD »

As a smaller setup that requires far less traffic than a large scale real-time application, what are the draw backs of just using a basic MySQL installation? We've hit over 20k views per day on our internal wiki with no signs of even coming close to any limits with either our hardware or the SQL stack.

Re: Never, ever, ever use MongoDB

#76

Post by cheald »

joepie91_ wrote: post #74
cheald wrote: post #72

Earlier quoted context omitted.

Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially…

> It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look . I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan wh…

> All the wrong places, as already stated. These are not the places where developers actually look.

If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry.

> Certainly not [in blog posts]

http://blog.mongodb.org/post/137788967/32-bit-limitations

> It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today).

I first started using Mongo in 2010 according to my gitlogs (after it having been on my radar for some time before that), and I very distinctly remember reading about the 32-bit limitation well before I'd ever installed it, because we were also using Varnish at the time, which has similar issues on 32-bit systems because it too uses (or at least, at that time used) memory-mapped files.

The claim that the limitation was not documented well, or was hidden, or was generally unknown at that time is just simply false.

Re: Never, ever, ever use MongoDB

#77

Post by facetube »

joepie91_ wrote: post #21
_pdp_ wrote: post #6

I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. I've got nothing against relation databases but there are not a solution to every single problem. Heck, why not decide first if you can use flat files? Do you really need to query and join. Not all problems require that sort o…

> I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. The issues I listed provably exist. That you haven't run into them yet doesn't change that - and quite likely, you might not even know whether you've run into it. Losing data or having your database open to the wide internet…

Postgres 9.4 even has `jsonb` and GIN indexes, which in a lot of ways provides nicer schemaless storage than some of the NoSQL databases provide. You're also free to mix in traditional relational tables (since `jsonb` is a data type like any other), or even efficiently join two tables based on a JSON containment operator. I haven't looked in to it _too_deeply, but what I've seen so far looks really neat.

Re: Never, ever, ever use MongoDB

#78

Post by facetube »

cheald wrote: post #76
joepie91_ wrote: post #74

Earlier quoted context omitted.

> It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look . I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan wh…

> All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the loc…

The word 'loss' does not appear on that page. There's a world of difference IMO between a rejected operation (which is what I would assume from that description – that the address space exhaustion would be detected and the database would stop accepting writes) and irreversible data loss.

Re: Never, ever, ever use MongoDB

#79

Post by cheald »

facetube wrote: post #78
cheald wrote: post #76

Earlier quoted context omitted.

> All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the loc…

The word 'loss' does not appear on that page. There's a world of difference IMO between a rejected operation (which is what I would assume from that description – that the address space exhaustion would be detected and the database would stop accepting writes) and irreversible data loss.

That's a consequence of their unacknowledged writes default - any write which failed for any reason wouldn't result in a rejection as far as the client is concerned (because the default was to shove the write request into the pipe and then continue without waiting for acknowledgement). As I mentioned earlier, most everyone acknowledges (heh) that as a bad default.

If you were checking getLastError on your writes, you would see the write fail when you ran out of address space.

Re: Never, ever, ever use MongoDB

#80

Post by fiatjaf »

joepie91_ wrote: post #23
fiatjaf wrote: post #9

I think people only use it because it stores JSON and let's you query it arbitrarily on demand. It appears to be as good as CouchDB, but with on-demand queries, as good as Postgres, but with JSON (!). It appears to be quick and easy and the tool for the job. Also, when people say NoSQL they actually mean MongoDB.

> as good as Postgres, but with JSON (!). PostgreSQL has supported JSON for a good while now, I've even explicitly linked to it in my post. And no, MongoDB is certainly not 'as good' - many of the problems listed simply do not exist in PostgreSQL.

I know. I'm just trying to say what I think people in general think about MongoDB.
Post reply on HN