I think there's one other problem that affects most NoSQL systems - the perception that adopting a NoSQL means you don't have to think about your data. When designers and front-end developers want to develop a web application they can do one of two things; a) say "don't worry about the back-end, we'll just throw it in a NoSQL database" or b) learn to also be a back-end engineer.<p>The idea that you don't need to worry about your data structure is deadly. Every successful project I've been involved with thinks seriously about the data model. ER diagrams with 160 tables aren't uncommon and knowing the structure of your most common queries helps you make sure that your database isn't over-normalized. There's a science to data systems after all.<p>"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." - Frederick P. Brooks from The Mythical Man-Month.<p>I quote or paraphrase this fairly frequently as I've come to believe it. If I understand your data structures, I can pretty easily tell what you might be doing with the system and I can read the code to see which parts you've implemented. But don't use this as an excuse to delay working on the rest of the application. There are Architecture Astronauts in the realm of database modeling too!<p>"Normalize until it hurts, denormalize until it works!" - Unattributed adage.<p>The key is to understand your data (and it will provide an amazing boost to the rest of the project). If you're worried about having your data-model perfect before you start coding, you should have started coding already. There are practices you can adopt that make refactoring your database more tenable. I recommend you read the "Evolutionary Database Design" article by Martin Fowler and Pramod Sadalage (<a href="http://www.martinfowler.com/articles/evodb.html" rel="nofollow">http://www.martinfowler.com/articles/evodb.html</a>), then adopt a workable technique as a team.
I think the biggest lesson here for us engineers is that we should watch and brace ourselves for similar tech buzz offerings like MongoDB. A few years when I went for interviews for startups, it was shameful that I didn't have experience and wasn't using MongoDB in my own products. I was a 'rusty spoon' for using resilient SQL. Funny how even engineers, a whole industry, can get swept up in using a subpar data store because it's the new cool piece of tech that makes it easier to have json you throw to a wall stick. I will never feel shamed again for not using some hot shot popular offering only because it makes development a tad bit easier. As engineers the end result is most important and we shouldn't sacrifice our platform stability just to ease our code editors and some minor migration frustrations. /endrant
MySQL was a great database that solved a problem. It did not solve it in a 100% complaint way, it did not have all the features that "dbms experts wanted", but in the early days it was very easy to started. In version 5+ they have fixed a lot of the issues and it is now on-par (or better) than most other databases. I also think they have focused on the right stuff: ease of use, easy way to fix performance issues, great ways to setup replication, great ways to take backups, not losing data, optimized to be used for the web etc. Also, most bigger properties (including Facebook and Google) use extensively MySQL.<p>If Mongo is going to be like MySQL, then great!
If PHP is a fractal of bad design, then MongoDB is PHP of database world.)<p>As for MySQL, Mongo marketing guys have learned the lessons from MySQL very well - there are nothing but "satisfied users", "good documentation" and "quickness and easiness" (any thinking, leave alone understanding aren't required) on their site and paid content - well-done "product", designed to trigger an ignorant consumer snap-judgement, the same way MySQL did at its time. They use the same sales strategy.<p><a href="http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/" rel="nofollow">http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...</a>
Honestly, I see very few thought-out or backed-up arguments here. The server-level blocking, the unacknowledged writes, silly defaults, etc are not only old news but have been behind mongodb for a while.<p>You also get comments like 'it still has database level locking' but rarely is there an educated discussion about the work that's been done to yield locks as quickly as possible and the real-world impact of this design.<p>People seem intent on punishing the platform for old mistakes (or immaturity) rather than providing a balanced view of it today. And comments like "Absolutely no benefit to Mongo. It's even really slow, so there's really no advantage at all." are just misleading without context, because it's at all true as an outright statement.<p>I spent today at the MongoDB developers conference in Sydney, and heard the CEO speak about when they think mongodb is good vs when you should use RDBMS, heard them speak about their community and target market, and heard a lot of stories and strategies about how to prepare for scale, how to think about schema design, how to monitor and admin the database / clusters, etc.<p>I'll just say that from hearing them in person, and hearing what people say about both the platform and the "marketing guys", you'd never know they were talking about the same company or product.<p>My own company has had a lot of advantage from using MongoDB in recent projects over other technologies (we have a largely MSSQL background). No, we don't do 100GB+ "web scale" (yet). Yes, we build solutions to real world problems and make money. No, it's not a silver bullet. Yes, you should know what you're doing and read the docs.<p>To any hackers / entrepreneurs who are thinking that MongoDB might work for them I'd say do some research, talk to people who've actually used it, and understand the benefits / limitations for yourself.<p>But stay away from opinions not based in real experience (and anything that mentions problems from before version 2.4, it's nearly a year old people) or you might miss out on something good.
Sheesh, what's with the MongoDB witch hunt? It seems like HN can't go 2 days without some disparaging of MongoDB. I get it. I'm an idiot for using MongoDB even though it suits my needs perfectly.
From my experience, as soon as you need some kind of relation with Mongo, you end up writing more application logic to create and maintain your relations. This probably means you should move to a relational database.<p>For Mongo specifically, can anyone share a pragmatic use case where you did not run into problems with duplication?
I have never really touched NoSQL for anything serious, yet i have worked with Riak, MongoDB and Redis. In the case of MongoDB i have worked with an ODM on top of it where i had to define a Schema and Object relations and was left wondering: What is the benefit of this anyway if i still define Schemas and relationsships ? Does it just make sense at a big scale when i would have to shard using MySQL ?
Schema migrations arent that hard today in MySQL with a good framework, so i am not really sold on the benefits for smaller apps.
If i can just save a JSON Object to it, thats cool (however Postgre is goot at that too), but in practice with server side validation and schemas i have to decode/encode anything anyway. Can anyone enlighten me on the real benefit ?<p><i>Edit</i> I see many benefits in using Redis though, just for its sheer speed and more as a smart memcached replacement though.
Come on, give MongoDB a break. I use MongoDB and I am proud of it. And I have used numerous SQL DBs (MySQL, PostgreSQL, Oracle, MSSQL, SQlite) and HBase from noSQL camp, so I do have something to compare to.<p>Yes, it was overhyped (and is underhyped now, at least on HN). Yes, it has its problems. Yes, it is not correctly positioned in people's minds (web-scale? not really). MapReduce on top of MongoDB, in a single-threaded JS engine - are you kidding me??? But it is useful tool nevertheless; one I am happy to have in my arsenal.<p>MongoDB will NOT solve your scalability problems. Old news. It will even add some of its own problems on top of it. But man, is it nice to just fire that data into your database and forget about DB-level schemas... And when you need that data, it is just there. True, I have built an ORM on top of MongoDB so it manages the DB for me; but it was easy to do and is incredibly useful. I would have done it with MySQL too (actually, I did - and it was a PITA to build because of relational databases' rigidness).<p>So please, stop bashing MongoDB for wrong reasons. It is an excellent and easy to use storage - when used for the right kind of problems. Nothing more, nothing less.
This isn't really being fair to MySQL. It was pretty terrible when it started out (corrupted data, no joins, no transactions, silly locking, didn't support half of SQL, etc.), but we must not forget just how terrible Mongo was and still is. It shipped with unacknowledged writes as the default for a long time.
> The article is about handling MongoDB if it grows above 100GB. It gives me the impression that scaling MongoDB to that size is a serious issue.<p>I don't think so. It gives me the impression that 10gen (MongoDb Inc.) has made a mistake how to present "handling MongoDb over 100GB".<p>> example: global write lock up to release 2.2<p>Why are we still talking about this? It's not global write lock any more, okay? Stating previous inefficiencies doesn't bring much value to the table.<p>> At this point it was inevitable to see MongoDB as a popular, yet poor representative of it’s species.<p>Show me the real arguments! Show me the real arguments!
This discussion has happened before.<p>MySQL is to SQL like MongoDB to NoSQL - <a href="https://news.ycombinator.com/item?id=6481526" rel="nofollow">https://news.ycombinator.com/item?id=6481526</a>
My guess as to the rise of MongoDB usage is that the rapid application development needs of the startup world led to people deciding that representing application data as JSON across all tiers speeds up the early stages of development. Unfortunately, as soon as data needs to be used relationally, developers are finding themselves pigeonholed in an inappropriate persistence format.<p>In short, developers that skip studying how their data might need to be queried in the future are to blame, not MongoDB.
So he's saying MySQL is bad, and MongoDB (because of a statement on their home page) is kind of like MySQL, so MongoDB is also bad. Also there was some article about scaling it to "only" 100GB which means it damages NoSQL as a whole in the "most harmful way".<p>Sorry but I don't really get the reasoning.
Does this offer absolutely anything new ? No.<p>Is this person objective and well respected ? No.<p>Does this person understand why MongoDB/MySQL is popular ? No.<p>Is anyone going to gain anything from this ? No.