For every positive article on MongoDB there are ten which are negative. Now that's a strong brand.
http://blogs.gartner.com/hypecyclebook/files/2010/09/2010-Em...
IMO MongoDB is currently in the trough of disillusionment
Mongodb – not evil, just misunderstood
41–50 of 53 posts
Re: Mongodb – not evil, just misunderstood
#42You may take a look at a "MongoDB Gotchas" discussion. https://news.ycombinator.com/item?id=4745067
Looking at that list, I would conclude:
"MongoDB Gotchas and How To Avoid Them: Don't use MongoDB"
It doesn't inspire much confidence in reliability to be honest...
Re: Mongodb – not evil, just misunderstood
#43> The advantages of schemaless documents are priceless. Not having to migrate is just one of the perks. Was the first sign that this person doesn't know what he is talking about... Of course you still have to migrate. Either your DB or your code, because you can't handle a change in how you store stuff without one or the other. "No migrations" is true only for the most trivial of changes, and only if you're willing t…
I'd wager that the vast majority of schema changes are adding new columns or new tables-as-child-relations, so to be fair those are free in a schemaless DB. So the "trivial" case is actually pretty common.
Honestly, I think the difference between schemaless and SQL corresponds very closely to the differences between static and dynamic-typed languages. The schemaless approach provides faster iterations and the ability to simply express things that require elaborate language features in a static-typed language. The difference is that in a DB, you have to support the data created by all your previous versions, so a DB requires far more discipline than the application code.
I can see the appeal, but I'm not sure that it's worth it.
Re: Mongodb – not evil, just misunderstood
#44> Mongodb expects that your working set fits into RAM along with the indexes for your database. I don't really get this. Surely any database system is going to be faster if all frequently updated/accessed pages fit into ram...what makes mongo special in this regard? Why does it degrade so badly when it has to access disk (beyond the obvious)?
The problem with this in MongoDB in particular I (think) is due the fact that it tries to work transparently on memory, leaving all the internals of moving things from disk to memory to the OS. Therefore, the DB be accessing disk without knowing, and being able to make any possible mitigation strategy. Maybe other DBs can deal with it in a more intelligent way, working better in degraded performance mode. But yes, th…
> But yes, this is a problem on any DB. The moment it hits disk, performance is terrible.
This is an over-simplification for any mature database unless all you care about are massive, completely random read workloads[1]. RAM will obviously be faster but there's a difference between terrible and performing at the level of the underlying disk subsystem. With a decent system, commits per second should track the underlying storage array's IOPS, large read / write traffic should be capable of approaching disk bandwidth, etc.
Where things do get bad is when the database is doing more random I/O than required by the workload – if storage is fragmented, it's playing sim-MySQL and creating lots of temporary tables, etc. you will see performance which is pathologically worse. This is a bug and should be fixed.
1. If writes aren't disk I/O limited, you should expect data loss because it's lying about durability.
Re: Mongodb – not evil, just misunderstood
#45Earlier quoted context omitted.
At my last job we did that on a regular basis, for the most part without even having downtime.
And at my last job no one would risk it because any issues with this would mean loss of revenue, angry customers and people having to revert code at a whim. (Of course, not only migration issues, but any code issues as well)
MongoDb is not going to solve development/operations issues, which is what you are describing. If anything, it makes those things worse as it is much more cavalier with your data.
Re: Mongodb – not evil, just misunderstood
#46Earlier quoted context omitted.
"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.
How does this change with MongoDB? The question of development support applies equally to both but it's usually MUCH safer to add a SQL column (default null, etc.) than to dive into a thicket of app-specific JS. This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.
Changing code is one thing, changing the DB is another. A deployment that changes only the code is simpler than one that changes the DB.
How many DBs do you have? Testing (usually local), staging, production? For how many sites?
It works the same, if row['new_field'] do_something() else do_something_else()
You have unit tests to make sure it works.
And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
Re: Mongodb – not evil, just misunderstood
#47About a year ago I implemented a sub-system relying heavily on MongoDB. The load is not that immense, a couple of hundred requests per minute. The dataset is large however, several hundred GB, spread over millions of documents. Also, updates happens in batch, during the night, while reads are happening all the time. I have not had to touch the system since it was put in production over a year ago - it just runs.
MongoDB is a tool, understand it's strengths and limitations and it will serve you well. We achieves great performance for our use-case by correct schema-design / partitioning of data, and sane use of indexes - which are excellent in MongoDB. If you need to scale large, you need to store the data in such a way that it does not require much resources to fetch them, i.e. you must store the data according to your read-requirements. This is even more true in "key-value" systems like Cassandra, which is more limited in how you can store data. MongoDB is very flexible, so it's a lot easier to shoot yourself in the foot.
Re: Mongodb – not evil, just misunderstood
#48I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…
"A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.
> Nobody would risk migrating that table
People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.
Re: Mongodb – not evil, just misunderstood
#49> Mongodb expects that your working set fits into RAM along with the indexes for your database. I don't really get this. Surely any database system is going to be faster if all frequently updated/accessed pages fit into ram...what makes mongo special in this regard? Why does it degrade so badly when it has to access disk (beyond the obvious)?
Some databases are relatively tolerant of indexes not all fitting in RAM, especially if the access pattern is localised within the index.
Re: Mongodb – not evil, just misunderstood
#50Earlier quoted context omitted.
How does this change with MongoDB? The question of development support applies equally to both but it's usually MUCH safer to add a SQL column (default null, etc.) than to dive into a thicket of app-specific JS. This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.
Changing code is one thing, changing the DB is another. A deployment that changes only the code is simpler than one that changes the DB. How many DBs do you have? Testing (usually local), staging, production? For how many sites? It works the same, if row['new_field'] do_something() else do_something_else() You have unit tests to make sure it works. And if it was so safer and easy to do it PostgreSQL wouldn't have add…
> A deployment that changes only the code is simpler than one that changes the DB.
In your experience, perhaps, but that's reversed in many other places.
As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.
> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.