151–160 of 194 posts
Earlier quoted context omitted.
See my comment below. If you use a package manager you never see the warning.
One would presume, if you're going to use a database you would check it's limitations first, this one is well documented. There are plenty of valid arguments for not using MongoDB, but this is the weakest I have seen so far.
Earlier quoted context omitted.
Me: "MongoDB, please store this: ..." MongoDB: "Done!" [Ed: The following is an unusual default requirement] Me: "MongoDB, did you store what I asked?" MongoDB: "Nope! Good thing you checked!"
But if you actually read about how it works... Me: "MongoDB, please store this: ..." MongoDB: "Okay, I've accepted your request. I'll get around to it eventually. Go about your business, there's no sense in you hanging around here waiting on me." Or, if you really want to be sure it's done: Me: "MongoDB, please store this. It's important, so let me know when it's done." MongoDB: "Sure boss. This'll take me a little b…
To me, the choice of performance over reliability is the hallmark of mongodb, for better or worse.
Not reading the documentation (or hell, the red "note" text under each 32 bit download link at http://www.mongodb.org/downloads ) for basic limitations will bite you in the ass in 2022 just as easily as it will in 2012.
Except that it was hidden deeply in the documentation. It's like making a car that has the gas and brake pedals switched, and then blaming accidents on people not reading section 5 of the owner's manual. I'm hardly an inexperienced programmer. I've used Cassandra, SimpleDB, Voldemort, etc. I wrote part of the Inktomi Search Engine in the 90s, and plenty of (what today would be called) NoSQL stores over the years. A d…
We've been interviewing candidates to join our team for a few months, and I've also lent some interviewing support to other startups in our area. I've noticed a trend across about 20+ candidates, all of whom are smart people: people are using Mongo without actually understanding what the hell it's trying to solve by getting away from the RDBMS paradigm. I'm not sure if this is because 10gen markets it as a general pu…
What about scalability? Trying to cluster and shard MySQL is a very difficult task, but with MongoDB it is trivial. No schema can be good, but scaling out easily is the big plus I see.
Earlier quoted context omitted.
But if you actually read about how it works... Me: "MongoDB, please store this: ..." MongoDB: "Okay, I've accepted your request. I'll get around to it eventually. Go about your business, there's no sense in you hanging around here waiting on me." Or, if you really want to be sure it's done: Me: "MongoDB, please store this. It's important, so let me know when it's done." MongoDB: "Sure boss. This'll take me a little b…
Thank you for taking the time to respond in kind; I do not disagree with what you have stated. I disagree with choosing this by default; it violates the principle of designing tools and APIs for use by the general programming public in such a way that they fall into the "pit of success". http://blogs.msdn.com/brada/archive/2003/10/02/50420.aspx To me, the choice of performance over reliability is the hallmark of mong…
That said, I think that people really do overblow the issue and make mountains out of that particular molehill, because all the tools are there to make it do what you want. Many times, it comes down to people expecting that MongoDB will magically conform to their assumptions at the expense of conforming to others' assumptions. Having explicit knowledge of the ground rules for any piece of technology in your stack should be the rule rather than the exception.
Earlier quoted context omitted.
> That's true about any database, not just MongoDB; nothing new here. That's exactly the point where we started. A well-designed system fails "safe"; it should obey the principle of least surprise. Specifically: MongoDB should default to synchronous writes to disk on every commit; official drivers should default to acknowledging every network call; MongoDB shouldn't allow remote access from the network by default. On…
The Principle of Least Surprise has local scope. You may be surprised to find asynchronous writes on an arbitrary database, but not for a database that is documented, advertised, and marketed as asynchronous-by-default. 'Surprise' is relative to the current environment and paradigm (in this case, asynchronicity)- if you find that surprising, then that means that you should have read the basic documentation properly.…
http://www.mongodb.org/display/DOCS/Philosophy
I admit that the default unsafe tuning of MongoDB becomes quite obvious when you read more of the manual, but I can hardly say 10gen is without blame for causing this confusion.
I understand having another node or two for fail over but I reckon with the spec of the largest offerings from AWS or Linode most people will never need to worry about this and can manage everything on one Postgres or MySQL db. Why complicate things before you have to.
There's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just…
It's almost like the commenters who are bashing the author of the post did not read the bit in bold, which is his main point: If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored. This has nothing to do with the 2Gb limitation. Nowhere in the documentation does it mention that it will silently discard your data. What will happen with the 64-bit version if you…
> Nowhere in the documentation does it mention that it will silently discard your data. Demonstrably false. http://www.mongodb.org/display/DOCS/getLastError+Command "MongoDB does not wait for a response by default when writing to the database. Use the getLastError command to ensure that operations have succeeded."
And I say this as an old-skool C guy who does do this in critical sections of code... But for everything else I'm in a language like OCaml that behaves sanely, using a DB like Oracle that behaves sanely.
Earlier quoted context omitted.
What about scalability? Trying to cluster and shard MySQL is a very difficult task, but with MongoDB it is trivial. No schema can be good, but scaling out easily is the big plus I see.
/dev/null is the most scalable system though, just fire up a node and it's there.
It is just a setting you know that right ?