I got "Error establishing a database connection", maybe this wouldn't have happened if they had used MongoDB :-)
Yeah, the post would have never even have been saved to disk in the first place :P
Why you should never use MongoDB (2013)
51–60 of 188 posts
Re: Why you should never use MongoDB (2013)
#52This article was posted almost three years ago and went through the same love/hate cycle on Hacker News then. Why the repeat? I am sure a number of technical points could be outdated by now.
Re: Why you should never use MongoDB (2013)
#53Earlier quoted context omitted.
before: mongodb is bad because it imposes we handle the case where we'd like to shard the db (which breaks joins). after: mysql is sooo much easier with joins. Who cares about sharding anyway. I hope people understand distributed systems a bit better today, but I don't have high hopes.
Without any knowledge of mongodb; if using it means you have to handle sharding right away, and using MySQL means you have to handle sharding when you outgrow a single instance, isn't that a big deal? MySQL scales pretty well these days, I think, so you can get a huge box -- a lot of stuff will fit in 2TB of ram.
MySQL can't scale horizontally if you're using it like it's a relational database.
No joins between shards means Sarah Mei could throw away her data model if she needs sharding.
She would then need to denormalize her data to avoid joins, which is the main argument in the article.
The project they were working on was a social network, a free alternative to Facebook. So I guess it's safe to say a single box, even the biggest you can imagine, could not ensure scalability. Beyond certain limits, sharding is the only option.
Facebook has implemented exactly the denormalization despised in the article, and they're using MySQL, albeit just as a dumb key/value store ;-)
Re: Why you should never use MongoDB (2013)
#54At this point in time, making a statement about MongoDB on HN should almost be considered trolling. We already know about the short-comings of that code-base. It will work fine until it doesn't and you'll loose some of your data. Some folks are using it and enjoying it. Others aren't. "Your shouldn't use it" is like saying you shouldn't use javascript for things other than UI. Noone cares anymore.
To be fair, I think your comment shows why this sort of post _can_ still be useful. You're very unlikely to lose data on a modern Mongo system using default configuration (their troubles with durability have largely been solved), but there are many other good reasons not to use it, and it's enlightening to read about and understand what they are.
Re: Why you should never use MongoDB (2013)
#55I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…
> I would likely not use it as a main source of truth for any application but for a lot of things, it's a good database. I really don't understand this. In what case is it every acceptable for a data store to lose data? And that's not even MongoDB's only problem: it memory leaks!
Here's one: I have an aggregation engine where 99.99something% of the data is cycled out within 3 days, and where the system can be functional again within about ~5 minutes of ingesting new data after a total data loss.
There are a lot of applications where your database is not the or even a source of truth, but effectively a big cache that you can either fully rebuild or where rebuilding isn't necessary (the data is too "fast moving" for there to be much point).
Here is another: A search engine for classifieds where the source of truth of 99%+ of listings were external feeds that'd get re-crawled at least once a day. If we lost a few million updates, who cared? If it was few enough, we'd just let the normal updates take care of it. If we had a major problem, or needed to do a major update that'd have compatibility implications, we could just do a re-crawl of all the feeds.
Here's another one:
You're scaling reads by replication, and so the vast majority of your data exists in multiple data stores. You may choose one you consider reliable for the source of truth, and the rest are basically caches, but you may want/need something more capable than a straight up key/value store for various reasons.
I believe the vast majority of data stores I've worked with have been ok to suffer a total loss of because most of them are not the source of truth, and the source of truth can be re-queries fast enough for it to not be a big deal to deal with losses in secondary copies.
Re: Why you should never use MongoDB (2013)
#56My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
I've always looked on 'duplication' (or denormalization) as an optimization to be used sparingly when performance dictates.
Regarding it as essentially a form of caching has been helpful. In fact there is a spectrum that goes from simple caching to denormalized schema with many points inbetween.
Re: Why you should never use MongoDB (2013)
#57Earlier quoted context omitted.
I have to say that I did not experience a single data loss that was a result of the database misbehaving. Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us. The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system. So, we would insert BIG amounts of data at a time and ag…
Fire-and-forget is awesome for when you do not care at all about your data. I'm sure those types of writes are super (duper) fast. What exactly is the use case for that? Serious question.
Don't know about the guy you replied to, but e.g. consider any application that regularly crawl feeds, api's etc. where the data is rapidly changing and only a portion of the data is necessary to give good output. There are lots of applications like that where you just need "enough" data to give good results and/or where any loss will auto-heal next time you crawl the original source.
Re: Why you should never use MongoDB (2013)
#58My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
While not a fan of mongoDB for many reasons, any sufficiently large scale application will have denormalization. Caching layers cause all sorts of cache invalidation bugs because of this exact problem. Indexes, while often managed by the DB, are essentially denormalization. One could even argue that syncing data between a client and server is a class of the same problem.
My point is that we deal with these problems out of necessity. If you don't get a ton of traffic, then sticking with a normalized RDBMS is probably best. However, large scale systems will have redundant logic. Generic solutions (letting the normalized DB do the work) will often be slower than specific ones (denormalizing your schema and moving logic into the application layer). These are pretty simple principles that I've seen on almost every large-scale application I've worked on.
Re: Why you should never use MongoDB (2013)
#59My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
Have a look at RethinkDB, it's the best of MongoDB and MySQL with real time feeds. A relational document store.
[deleted]
Re: Why you should never use MongoDB (2013)
#60Earlier quoted context omitted.
Mildly, but less so when you consider that it's a blog not a product. And even less so when you consider it likely fell over due to load and didn't silently delete the blog data.
No matter the load. A blog is only reads. Any db system should be able to hold up. It's a different kettle of fish when there's writes; but for reads, it should be a walk through the park.
There's comments on the article, although I doubt the volume of writes there would be troublesome I have no idea really.