Published: Nov 06 2011 / 10:21
Well plus one for the guts of the article, ofcourse it's not really possible to check all this. It would be cool if people who actually have exeperience with similar scenarios would confirm/infirm all this. On the whole, even though the article sounds convincing I cannot but stop and remember a similarly convincing article about how GAE is a piece of garbage - and it was NOT because of the price changes, it was all performance and quality of service - and that one was something that I've NEVER experienced in all my workings with GAE/GWT.
Yes one never can be sure the author is not just bashing because it give him personal benefit and not because mongoDB is bad.
On the opposite of the spectrum, the claims here are perfectly plausibles and predictibles. Most NoSQL database relax ACID property for more speed. At first, no one care. The implicit is that ACID will be preserved and only in rares case that will never happen in pratice the system will fail.
But theses can happen, and they happen often. It is interresting to note that nobody has heard that bank are using latest NoSQL databases to store their data.
No, we mostly ear of NoSQL in place like social network or as applicative cache for read only data. If a few tweets are lost, or even if one tweet history is lost, it is not that good, but this is the end of the story.
If a few hundred bank accounts are deleted, the problem is really different.
The storry here for me is just the normal case. You choose a new technology, not really battle tested. It work great, but there are bugs. And when the load is too high for your current setup, the server are not really responsives and don't perform the admin stacks you want fast enough. Not really surprising, isn't it?
The problem maybe is why it wasn't anticiped in the first place? You know, Oracle database isn't the wordwide leader in the field for nothing. And there a reason many mix NoSQL databases with more classic ones.
I always had these suspicions... :-(
Simple Rule: Don't use NoSQL unless you have to! You are not Google!
If you need hyper-performance, HSQLDB. Why? Mulithreading, eons better performance than MongoDB, full XA Transaction Support, JPA, and recycling the existing relational knowledge you already have. If you are already at big-data like capacity, try VoltDB which puts HSQLDB on a cloud.
Wow, all these guys have done a big mistake.... http://www.mongodb.org/display/DOCS/Production+Deployments
PS: Perhaps it's a matter of right tool for the right job?
I wonder why everybody totally believes this article. It's been uploaded to pastebin anonymousely... Even if that guy's right (and I would not doubt some of his complaints), who says, that Ops did setup mongo correctly? There's no way to ask the author for feedback.
While that article actually ripped off the glow around mongo for me, I would not take anything in it for granted. In any case, I've seen weird things happening with MySQL databases aswell. In some cases it was caused by too much traffic, in others it was caused by breaking servers, but the most common usecase for a database to fail is (at least from my experience) that it's being not properly used by the client application.
MySQL has always been a pain in the ass, if you ask me. I suppose it has caught up with the SQL standard now, so that it is reasonable to call it a RDBMS. The best I can say is that all it's quirks (deviations from SQL standard) and shortcomings are well documented... which just makes it more mysterious why so many people actually use it.
I dont see anything wrong with this article all the author points are kinda true and it is not just MongoDB is any NoSQL. If you treat a NoSQL as a Relational Database of course you will fail and that is the point of this article.
NoSQL should be handle with careful and always study carefully the uses cases to know if a NoSQL would be the right choice or a Relational Database. The author admitted they fu**ed up the project and also some ranting about but you can believe this is the everyday food when you work on a NoSQL, It happend to me on Azure some of the points, NoSQL are not ACID.
I tend to think that most people are well educated in using RDBMS but no so much in using any type of NoSQL. It is also the reason why I disagree with most tutorials on GAE using JPA to access the datastore. We are all generally inclined to mentally connect JPA with regular RDBMS and using the same API with a NoSQL datastore can make for very confusing semantics when reading the code. I take the article simply as a hint what to watch for when not using RDBMS (leaving all the rant aside)
I would add that everybody agree that for a classic RDBMS you need a DBA, or even more a DBA team to manage your DB server, perform the optimisations, backups and restores.
NoSQL database are used by quite competent at tweeter, google etc and they do it very professionnaly. But there also a tendancy to view NoSQL as some sort of silver bullet database that doesn't require an ORM and where you can just store your objects without any need for optimisation, maintenance, whatever. The fact that theses database may not support all ACID properly is simply ignored.
All a hoax, though? http://www.h-online.com/open/news/item/MongoDB-FUD-or-Hoax-controversy-spreads-online-1374710.html
I am grateful when other developers share their experiences with new technologies.
This developer gave enough specific examples, that it would help me better evaluate MongoDB against the alternatives.
The developer seems reasonable and objective. It doesn't sound like an emotion based rant to me.
This is NoSQL!. If you want ACID use a Relation Database period. It is that simple really.
Problem is human think everything moves on fashion so NoSQL is the thing now so everything have to be in NoSQL, "WRONG" Think and review your use case to see if apply a NoSQL or a relation database. This will be over and over 10gen responding, users responding never ends.
Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.
Advertising - Terms of Service - Privacy - © 1997-2014, DZone, Inc.