Earlier quoted context omitted.
If it blows your mind that people would write to mongo without making sure the write succeeded, then doesn't that make the default behaviour itself mindblowing? Perhaps a better option would be to have an 'unsafe_write' option. But then of course, benchmarks would look less impressive which didn't use a function with 'unsafe' in the name.
It blows my mind a person wouldn't read the manual.
I’ll Give MongoDB Another Try In Ten Years
181–190 of 194 posts
Re: I’ll Give MongoDB Another Try In Ten Years
#182We'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.
>but with MongoDB it is trivial
We did not have this experience when I worked at a large datamining company. It was a nightmare.
Re: I’ll Give MongoDB Another Try In Ten Years
#183We'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.
>but with MongoDB it is trivial
We did not have this experience when I worked at a large datamining company. It was a nightmare.
Re: I’ll Give MongoDB Another Try In Ten Years
#184Earlier quoted context omitted.
In fairness, this would eventually happen on a 64 bit machine too, just not as quickly. No excuse for not reading the docs, though.
The 64-bit limit is 8.6 exabytes. There won't be anyone using Mongo that runs into that limit this century.
But when you run out of disk space (as one of the posters wrote) it doesn't complain either. And running of of disk space happens.
Re: I’ll Give MongoDB Another Try In Ten Years
#185i welcome the post. even though most of my stuff runs on 64bit, i actually do have a few 32 bit systems here and there. I never knew. Because as the op mentions it's not written anywhere _obvious_. another thing I didn't realize was that because of the memory mapped systems which i guess is fine performancewise it's hard to estimate memory usage on a machine. from what I understand there is no possibility to limit th…
> it's not written anywhere _obvious_. Isn't http://www.mongodb.org/downloads an obvious place?
Yeas, there is a small "note" there.
But for me the problem is not that the author didn't know about 2GB data limit.
The problem is that Mongodb didn't complain when he was inserting data above the limit. A data store doesn't complain when it runs out of space? It should be mentioned as the biggest problem with 32bit version.
Re: I’ll Give MongoDB Another Try In Ten Years
#186Earlier 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.
>but with MongoDB it is trivial We did not have this experience when I worked at a large datamining company. It was a nightmare.
It would be interesting to hear what the difficulties were.
Mongo markets ease of sharding as an advantage, and if that is not the case at times, it limits the attractiveness of losing RDBMS features.
Re: I’ll Give MongoDB Another Try In Ten Years
#187I can think of several cases where throwing an exception is counterintuitive to Mongo's design and applications. Let's say, if your app returns control to the user while storing data asynchronously, throwing an exception might not be the best way of handling errors. In fact, if throwing exceptions were Mongo's default, I wonder how long it would take for a blog post entitled "Mongo blew up my app" to appear.
Re: I’ll Give MongoDB Another Try In Ten Years
#188Earlier quoted context omitted.
Can you elaborate please? With a Postgres/MySQL/Oracle installation I can say `CREATE DATABASE` and get a new namespace. I couldn't find anything like that with Mongo. Am I just missing something?
"use foobar" creates a new database called foobar.
Ah, somewhere along the line I got the impression that in Mongo a "database" and a "collection" were the same thing, but that's not true. Glad to know this was just my mistake!
Re: I’ll Give MongoDB Another Try In Ten Years
#189Earlier quoted context omitted.
Surely "getLastError" is an extremely questionable concept in the asynchronous world? How do I know the 'last' error is the one relating to the operation my code just executed?
Presumably this has to be done in the driver directly after the insert call - on the same connection, to ensure that you actually get the last error, and not someone else's error, if you have several instances writing to the db?
Mongo's wire protocol actually has request IDs, but it appears db.$cmd.findOne({getlasterror:1}) doesn't use that. Instead you have to send it over the same connection as the operation in question, and if you had to reconnect you're just fucked and will never know what you may or may not have committed.
Re: I’ll Give MongoDB Another Try In Ten Years
#190While this article is a bit flippant, I think ten years is a pretty good number when you consider the vast amount of engineering effort that has already been poured into projects like Postgres. This brings me back to the recent discussion about reading other people's code: it is almost certainly smarter to extend an existing database until it's capable of meeting your needs, rather than write one from scratch. The fa…
10 years and PostgreSQL still has no easy, manageable solution for replication or sharding. And it's JSON support is still nothing more than a bolted on hack on top of a BLOB. People need to stop acting like PostgreSQL is some holy grail database. It isn't.
Correctly and efficiently querying sharded tables is not only a very complicated dark art but also heavily patented. I thought they had a replication story, though.