
I’ll Give MongoDB Another Try In Ten Years - nachopg
http://diegobasch.com/ill-give-mongodb-another-try-in-ten-years
======
daveungerer
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 run out of disk space, more silently discarded data?

I know a lot of you may have cut your teeth on MySQL which, in its default
configuration, will happily truncate your strings if they are bigger than a
column. Guess what? Anyone serious about databases does not consider MySQL to
be a proper database with those defaults. And with this, neither is MongoDB,
though it may have its uses if you don't need to be absolutely certain that
your data is stored.

EDIT: Thanks for pointing out getLastError. My point still stands, since
guaranteed persistence is optional rather than the default. In fact, reading
more of the docs points out that some drivers can call getLastError by default
to ensure persistence. That means that MongoDB + Driver X can be considered a
database, but not MongoDB on its own.

I'm just struggling to imagine being willing to lose some amount of data
purely for the sake of performance, so philosophically it's not a database
unless you force it to be. Much like MySQL.

EDIT2: Not trying to be snarky here, but I would love to hear about datasets
people have where missing random data would not be an issue. I'm serious, just
want to know what the use case is that MongoDB's default behaviour was
designed for.

EDIT3: (Seriously) I'm sure MongoDB works splendidly when you setup your
driver to ensure that a certain numbers of servers will confirm receipt of the
data (if your driver supports such an option), nowhere am I disputing that.
But that number really should have a lower bound of 1, enforced by MongoDB
itself. And to the guy who called me stupid: you are what's wrong with HN.

~~~
ceejayoz
> 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."

~~~
diminoten
It blows my mind that you'd have to post this at all. Who's writing to mongo
without making sure the write succeeded?

~~~
olalonde
The people over at MongoDB who wrote the tutorial?
[http://api.mongodb.org/wiki/current/Ruby%20Tutorial.html#Rub...](http://api.mongodb.org/wiki/current/Ruby%20Tutorial.html#RubyTutorial-
InsertingaDocument)

~~~
diminoten
Then they fucked up.

~~~
icelancer
"It's like, literally, right there in the brief manual. Takes an hour to read
and understand."

Huh.

~~~
diminoten
Yeah, manual. Like I said in the other comment.

------
bdcravens
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 software, bits and config files. It's not like
someone called your mom a harlot.

Here's what I think. New developers, for a long time, have come into the
industry and become overwhelmed with everything they need to learn. Let's take
typical database servers. Writing a SELECT is easy enough, but to truly be an
expert you have to learn about data writing operations, indexing, execution
plans, triggers, replication, sharding, GRANTs, etc. As it's a mature
technology, you start out barely an apprentice, with all these experienced
professionals around you.

In recent years, software development has really been turned on its head.
We're not building apps using the same stack we've used for a long time: OO +
RDBMS + view layer + physical hardware. The younger the technology, the
better, it seems. In theory, a 3 year developer and a 20 year developer are
now pretty equal when we're talking about a technology that's been around 2-3
years. That wouldn't be true if we were dealing with say, OO design patterns.
(Even when new languages come along, you still get to keep your experience in
the core competencies.)

Attacks on these new technologies are perceived as an assault on this new
world order, and those who have walked into being one of the "newb elite"
respond emotionally to what they see as a battle for the return to the old
guard. Am I totally off base here?

~~~
lmm
I think you're way off base. Even assuming your claims about experience with
traditional databases (which I disagree with), we don't see the same kind of
emotional tone when talking about equally new datastores like redis or
couchdb.

Mongodb was very aggressively marketed; its advocates produced benchmarks
comparing it directly to traditional relational databases as though the use
cases were the same. I think that set the tone for future discussion in a way
that's still being felt.

If you're as old as your opinions suggest you'll remember the early days of
Java were very similar - Sun marketing pushed it no end, and so tempers ran
high and discussions were emotionally charged in a way that never happened
when talking about perl or python or TCL.

~~~
bdcravens
I'm not terribly old: 35. Been doing web development as a career since 1999.

More relevant, is my experience. I didn't come in when Java came out. I
started (1997-1998) with some high-level dynamic web languages: ASP classic,
ColdFusion (To this day, I still do CF - I'm a CF user group manager and I
speak at CF conferences). Building HTML and JavaScript since 1996 (GeoCities,
HotDog, and HomeSite). Nerded around with programming 1995-1997 in high school
(TI Basic, Pascal, and Qbasic) In the days when I started web development, a
lot of folks were still monkeying around with Perl and flatfiles. I can't
really speak to early days of Java: until 2000, didn't really use it.
ColdFusion 6 went from C++ to Java, at which point CF devs ran on the JVM and
could target it.

From the beginning I was a consumer of RDBMSes. Started with Access and moved
on to SQL Server. There wasn't a need to know the full DB, only the pieces you
needed for CRUD. Perhaps for newbs that has changed, and they have to learn
the full SQL administrative experience. Personally I doubt that. Do some db
migrations in Rails: you don't even need to know what SQL engine you're
running on. (A good thing, IMO, but still means a lesser body of knowledge)

Good point that a lot of products try so hard to be the "new sexy" that they
suggest an inaccurate comparison, or at best, implement a subset of what
they're trying to replace.

------
calpaterson
It's pretty incredible that the author of a post called "I’ll Give MongoDB
Another Try. In Ten Years." criticises a comment on this same post telling him
to read the tutorial all the way through as "unnecessarily aggressive".

Aside from that, though, the 32 bit limitation is clear in the documentation
and present on the download page. It's fine not to read the documentation
before you use something but you can't then complain that it did something you
did not expect. Mongodb is a little different from other databases. So is
Redis. You can't blow everything off that is conceptually different.

~~~
diego
See my comment below. If you use a package manager you never see the warning.

~~~
matthewcford
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.

~~~
jonny_eh
I don't think his problem was the size limit, it was the lack of exceptions
being raised or log errors being recorded.

------
nemesisj
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 purpose tool,
but I have yet to talk with a candidate who can actually describe why they
were using the DB vs. a SQL database. I'm all for learning new things, but I
can't help but wonder if the string of negative MongoDB posts is coming from
people who pick it b/c it's new, then realise pretty far in that this is
nothing like a normal DB, and "having no schema" isn't really a reason to go
with a tool as foundational as a data store.

I think Mongo is great for really specific problems that its designed to
solve. It's probably pretty bad for a general purpose tool, but I'd be
surprised if anyone serious actually considers it one.

~~~
clintonb11
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.

~~~
icelancer
>but with MongoDB it is trivial

We did not have this experience when I worked at a large datamining company.
It was a nightmare.

~~~
bsg75
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.

------
jeffdavis
I think blaming the user here is partially valid (he didn't read the docs),
but that's not the whole story.

There is a discontinuity between the ease-of-use story and the blame-the-user
story, regardless of how well documented the async insert behavior is.

And it doesn't have to be this way. There are ways of designing interfaces,
APIs, and even naming that go a long way to prevent your users from shooting
themselves in the foot.

Take postgres. It also supports at least a couple kinds of async insert, one
of which is a part of libpq (postgres C client library). It's called
"sendQuery" and it's documented under the "Asynchronous Command Processing"
section. It's hard to imagine a user trying to use that and expecting it to
return an error code or exception. Even if the user doesn't read the docs, or
reads some fragment from a blog post, they will still see that the name
suggests async and that it returns an int rather than a PGResult (which means
it obviously doesn't fit into the normal sync pattern).

There is no reason mongo couldn't be clear about this distinction -- say,
rename "insert" to "async_insert" and have "insert" be a wrapper around
async_insert and getLastError. But instead, it's the user's fault because they
didn't read the docs.

Careful API design is important to reduce the frequency of these kinds of
errors. In postgres, it's relatively hard to shoot yourself in the foot this
badly in such a simple case. I'm sure there are gotchas, but there is a
conscious effort to prevent surprises of this sort.

~~~
chimeracoder
> There is no reason mongo couldn't be clear about this distinction -- say,
> rename "insert" to "async_insert" and have "insert" be a wrapper around
> async_insert and getLastError. But instead, it's the user's fault because
> they didn't read the docs.

Because if you don't read enough of the docs to understand that 'insert' is
asynchronous insert, you don't understand MongoDB and haven't done your
research.

Why should 'insert' default to synchronous? Why shouldn't we instead have a
sync_insert function instead? The only reason is that you're assuming
familiarity for people coming from SQL/synchronous-oriented DBMS, but why
should they be forced into an awkward design just because it's what people are
familiar with from _other_ DBMS?

~~~
justinsb
A good system is forgiving; it encourages exploration; if there's a choice
between safety and performance it defaults to safety. If/when profiling shows
the safe behaviour to be a bottleneck, then users can Google the issue and
discover "Oh, I just need to set flag X; I can live with the consequences
here".

Expecting the user to be an expert in your product from the start is simply
not realistic; a well-designed system facilitates use by people of varying
levels of expertise.

~~~
chimeracoder
> A good system is forgiving; it encourages exploration; if there's a choice
> between safety and performance it defaults to safety.

Not if you're choosing a system that's explicitly marked for performance over
safety.

> Expecting the user to be an expert in your product from the start

The 'product' in this case is a non-relational database, not an iGadget. The
user can and should be expected to be familiar with the main strengths and
weaknesses of the database as a whole.

There is no way you can convince me that someone who has done a reasonable
level of due-diligence in investigating MongoDB can be surprised when it
behaves asynchronously.

~~~
justinsb
Kudos to you for doing your research. If you're saying "don't use MongoDB
without doing at least N days of research first", then you're very much at
odds with (my perception of) the 10gen marketing message.

I think you're right though: MongoDB should not be used without _lots_ of
research into its limitations.

~~~
chimeracoder
> I think you're right though: MongoDB should not be used without _lots_ of
> research into its limitations.

That's true about any database, not just MongoDB; nothing new here.

> then you're very much at odds with (my perception of) the 10gen marketing
> message.

10Gen is fairly straightforward about the original issue, having blogged
openly _several_ times about their decisions - but at the end of the day, any
engineer should do research beyond the simple marketer's pitch.

I won't doubt that there are people who make snap judgements about fundamental
architecture based on marketing pitches[1], but that's very unfortunate, and
the marketers really can't be blamed, _especially_ when they make no effort to
conceal the truth or deceive you!

[1]<http://www.pinaldave.com/bimg/dilbert5.jpg>

~~~
justinsb
> 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. Once you want higher performance or
remote access, you can read about the configuration options to change and
learn on-the-fly, evaluating the trade-offs as needed.

Other systems are safe by default (e.g. PostgreSQL), and their out-of-the box
performance and setup complexity suffers because of it. MongoDB could ship
"safe" (with the same trade-offs), but chooses not to. That sort of marketing-
led decision-making has no place in my technology stack.

~~~
chimeracoder
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.

> MongoDB could ship "safe" (with the same trade-offs), but chooses not to.

Because that's one of the main points of choosing MongoDB...

~~~
jeltz
This "main point" is never mentioned in their philosophy page. And the
introduction mentions "Optional streaming writes (no acknowledgements)" which
sounds like the default is synchronous writes.

<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.

------
mtkd
This is the latest in a long line of negative posts on MongoDB based solely on
first impressions because either:

1) it does not behave exactly like SQL

2) the user didn't read any more than a Quickstart Guide

3) the user fundamentally misunderstands the aim of the new technology or the
application it is intended for

Ember.js suffers from the same ignorance.

What makes it worse is all the morons who upvote without even reading the
detail purely because the title reinforces some misconceived bias they already
have.

'NoSQL' is part of the problem. This technology has absolutely no comparison
with SQL other than it persists data.

~~~
linuxhansl
I'm sorry. Which part of "It silently ignored my data" do you not understand?

You call people "morons", yet it appears that you did not read the article
yourself.

Whether SQL or not, scalable or not, old or new, or whatever... Is completely
immaterial here.

When a database silently stops accepting data, and apparently has done so for
3 years, you have to at least admit that there are strange design goals at
play.

Now, the entire claim of the article might be incorrect. Did you verify that
yourself?

Edit: Spelling

~~~
pooriaazimi
It's stated plainly and prominently in <http://www.mongodb.org/downloads> that
32-bit version is limited to 2GB. It's mentioned elsewhere in the
documentation, but the OP didn't bother to read them. "A gem and two lines"
and it worked, so he expected it to work forever. That's not how engineers
usually work. Most of the time, they over-engineer, not the other way around!
They research the hell out of any new technology they want to use. I'm
definitely less talented than OP and others on HN, but even I know a hell of a
lot about Redis, MongoDB and CouchB, _and I haven't even started to write a
line of code_.

And anyone who has read more than an introduction to mongo knows that you
SHOULD use getLastError to be safe. If you do that, no data will be dropped.

~~~
zzzeek
I think they need to change the word "limit". This is what "limit" means:

    
    
        [root@li321-238 tmp]# dd if=/dev/zero of=./filesystem bs=1M count=128
        [root@li321-238 tmp]# mkfs.ext2 filesystem 
        [root@li321-238 tmp]# mount -o loop filesystem myfilesystem
        [root@li321-238 tmp]# dd if=/dev/zero of=myfilesystem/im_too_large bs=1M count=129
        dd: writing `myfilesystem/im_too_large': No space left on device
    

that is, a "limit" means, the program stops, complains. It's "limited".

A program that continues along without issue, only changing its behavior in
some unannounced (documented or not) way, is not "limited". It's free as a
bird.

------
ef4
While 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 fact that many programmers don't see it that way is a testament to their
irrational fear of diving into other people's code.

~~~
taligent
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.

~~~
prodigal_erik
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.

------
ceejayoz
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.

~~~
diego
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 default that's so counterintuitive for a database should be featured
prominently with a huge neon sign. It wasn't in the Ruby tutorial, or in any
of the many documents I read. It's buried deep in the Mongo website, and the
first Google match about the 32-bit limitation is a blog post from 2009.

~~~
lbcadden3
It's on the download page.

<http://www.mongodb.org/downloads>

~~~
diego
I installed it through Ubuntu (apt-get). Most people must (or should) be
installing MongoDB through a package manager. Once again, assuming that people
will see the warning because it's on the download page is shortsighted.

~~~
deelowe
See dmaz's comment about the log files. I'm a complete mongodb noob as well,
but found out pretty quickly that there's a 2GB limit on 32bit systems. It
really is hard to miss.

------
andrewvc
I'm a pretty big detractor of mongo, but I don't agree with this post. One of
mongo's main design decisions is to defer writes, making this sort of thing
possible. I think it's a crappy tradeoff but it is one of the things that
makes mongodb mongodb. If you use it without knowing this you haven't
researched it well.

~~~
DanWaterworth
When is this behaviour useful? (Benchmarks don't count)

~~~
eli
Well, any time you'd rather have speed over completeness. Maybe you're
aggregating tweets from the Twitter API and if the occasional one goes
missing, it's not a big deal, or perhaps you can grab it on the next update.
Maybe you're generating a real-time stats dashboard for your site and if one
pageview gets lost every million, it's not a big deal.

Look, I agree that in most cases you probably want to do everything you can to
make your data 100% complete. But failed writes should be really rare, and
there are plenty of times I'd trade the rare missing write for cheaper/faster
database servers.

~~~
DanWaterworth
This wasn't the occasional write though, this was every write after 2GB. That
should set off alarm bells somewhere.

~~~
benatkin
The way MongoDB is designed, this would be outside the scope of a driver. A
storage library that's based on the ruby MongoDB driver could certainly do it,
though. That's what the OP ideally should have been using. In fact MongoDB
would be a good choice for his use case, if he would switch to a 64-bit VM and
handle error conditions (heh).

------
eranation
I'm using MongoDB for experimental work for about 6 months, it has a few
amazing advantages, it's the MVP / POC king, you just do it, it's the agile
iteration master, it's definitely not the best choice for doing any
statistics, or any financial like transaction handling.

However, it starts to feel like Anti MongoDB is just considered cool today,
when I see someone that worked with MongoDB for a year, upgraded to 2.2, knows
it inside out and still hates it, I would listen, and start to worry. but
until then, I'm going to keep using it, and saving time.

~~~
nestlequ1k
Agreed. I've been using it almost daily for 2 years. It was not an instant
learning curve (what DB is?), but it's an absolute joy to develop for.

People who would rather not bother, can stick with their tools, work slower,
and be happy.

------
base698
I used MongoDB one afternoon, and guess what! It doesn't have table-locking
writes?! :)

In all seriousness, I built a 10 machine Mongo cluster, talked with a 10gen
consultant a full day, went to Mongo meetup, and ran all sorts of benchmarks
before ever using it in production. I still don't feel like I have the
expertise to write a snarky blog post about it.

~~~
meritt
> It doesn't have table-locking writes?! :)

Not really following the snark there. Are you trying to compare MongoDB to
MySQL's MyISAM storage engine? Like there aren't numerous other extremely
valid RDBMS solutions out there, which don't do table locks during a write?
(MySQL InnoDB, Percona, Maria, Aria, Postgresql, Firebird, etc...)

~~~
gnufied
No. He is saying out of all faults Mongo has - blog author picks the one which
is rather well known.

~~~
chimeracoder
Worse, it's the necessary tradeoff of one of MongoDB's self-proclaimed
benefits (asynchronicity) - it's not an edge case; it's part of the core
reasons you'd switch to MongoDB (or at least take into account when making
that choice). If that surprises you, it's because you haven't switched for the
right reasons _or_ haven't researched enough to know that every benefit has a
tradeoff (and to know _what_ those tradeoffs are).

To give an analogy, it'd be as if someone read this post and decided to use a
SQL database _solely_ because they care about write-durability... and then
complaining when they "suddenly" encounter an error when trying to include an
extra field with an INSERT on-the-fly. ('You mean SQL has fixed schemas??')

~~~
mattmanser
Where on this page is the word asynchronous mentioned:

<http://www.mongodb.org/>

If they just wrote asynch on that page somewhere most experienced programmers
would immediately understand the implications. And also understand how the
amazing performance was being achieved.

------
ShabbyDoo
The author doesn't mention if he had called getLastError after inserting data:

<http://www.mongodb.org/display/DOCS/getLastError+Command>

The MongoDB "way" is that clients know the importance of their data and can
choose write strategies which make the proper trade-off between insertion
throughput/latency and durability/consistency.

------
ericcholis
First, your friends with MongoDB are fsync and safe. These are both documented
and discussed in more than a few places:
[http://nosql.mypopescu.com/post/1052759609/mongodb-safe-
and-...](http://nosql.mypopescu.com/post/1052759609/mongodb-safe-and-fsync-
explained)

So, assuming you are writing an ecommerce application, here's where I think
these flags come in.

\- Session data: fsync = true. Wait for a response, and ensure it's written to
disk

\- Internal web analytics: safe = false. Who cares if it's written, I've got
an application to serve!

\- Orders: fsync = true. I know, RDBMS, transactions, blah blah blah.

People tend to look at NoSQL and wonder why it doesn't function like MySQL,
then they loudly complain how bad the software is. Nobody is writing articles
about how Memcached doesn't function like MySQL.

------
jff
Maybe in another 10 years, he'll have managed to lay hands on the elusive
64-bit computer.

------
etrain
I had a very similar experience about a year ago. Except instead of running
out of RAM on a 32-bit instance, I was running out of disk on a 64-bit
instance. That's right, my database ran out of disk, and the driver didn't
throw an exception.

Yes, I realize that there's a "safe=True" option to my python driver. But I'm
_writing to a database._ As others have said here and elsewhere, the default
behavior of a database and its drivers should be to complain loudly when a
write fails. It is ridiculous that safe!=True by default. If I want to turn
off this feature to improve performance, I will.

------
jeremiep
I stopped reading at "WTF zomg LOL zombie sandwiches!". Just another script
kiddie who can't read documentation and blames his tools instead.

------
manuscreationis
Does he have a point that it should have very vocally complained to him that
his size limit have been reached, and records were not being stored?

Yes. Without question.

Is this his own fault for not reading the documentation and understanding that
he should have opted for the 64bit version outright?

Yes. Without question.

------
arielweisberg
When I wrote some hobby code for Postgres using the PHP driver I had to
manually check error codes after each and every operation. This came as no
surprise to me.

Exception throwing database drivers are a relatively new thing not an old
thing. The only thing MongoDB does differently is that the writes are fire and
forget in that the database hasn't returned a response of any kind when the
function returns.

In native code you can forget about using exceptions in a database driver
because exception handling can be exceptionally broken on some platforms.
SmartOS I am looking in your direction.

~~~
alwold
Exception throwing is not that new. It's just a question of what is the style
in the language you're using. In Java, for example, throwing exceptions has
been the norm since JDBC was invented in 1997. PHP is definitely different in
that exceptions are rare. Same story with C++. I'm not super experienced with
Ruby, but they seem pretty common there, so I would've expected to get one.

------
xoail
The world is moving towards 64 bit. 9 out of 10 machines I lay hands on run 64
bit. Just move on and stop complaining.

~~~
ceejayoz
In fairness, this would eventually happen on a 64 bit machine too, just not as
quickly.

No excuse for not reading the docs, though.

~~~
cheald
The 64-bit limit is 8.6 exabytes. There won't be anyone using Mongo that runs
into that limit this century.

~~~
krzyk
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.

------
DanWaterworth
Interesting that you're quoting the zen of python, but using ruby. I wonder if
the python mongo client would have the same behaviour.

There seems to be a number of people commenting, telling you to read the
documentation, but I'm with you, that is completely counter-intuitive
behaviour and should be viewed as a bug.

~~~
agscala
This has nothing to do with the client library, so it would not matter which
language you use to interface with MongoDB.

~~~
DanWaterworth
As I understand it, it has everything to do with the client library, some
clients may call getLastError on every operation and raise errors when they
occur, for example.

~~~
omni
PyMongo, for instance, can do this for most operations by passing safe=True.

------
kombine
A lot of bashing of MongoDB lately is a sign to give a technology at least a
try.

~~~
nestlequ1k
Great point. That's usually how you to tell when a technology is starting to
disrupt things. Really smart people / experts in their field (which Diego
definitely is) start to bash it. In this case, he has a point but has way
overblown things. But that's ok, that means Mongo is on the right track.

~~~
wglb
I am trying to reconcile the ideas of "Mongo is on the right track" with
burning a user by losing data.

------
Adirael
Just read the documentation and learn the APIs, this is what happens when you
just copy and paste code from a tutorial.

~~~
diego
This type of attitude is not constructive. Of course I read the documentation.
Much more than "copy and paste from the tutorial." I looked at tons of code
samples as needed, read blog posts, etc. The limitation wasn't obvious at all.

This reminds me of the attitude that I had to correct in developers that
worked for me:

\- There is a huge difference between "it works" and "it does what the user
expects in a friendly way."

Steve Jobs said that if you need to read a user manual (particularly to do the
most vanilla usage of a product), the problem is the product. Not you.

~~~
bkanber
> Steve Jobs said that if you need to read a user manual (particularly to do
> the most vanilla usage of a product), the problem is the product. Not you.

He's talking about consumer products, not databases that were intended for use
by technology experts. There's a big difference there.

The onus is on you to understand the limitations of software before you start
using it. You complain that the 32-bit warning doesn't show up in the package
manager, but you still should have read the documentation before committing to
a new technology. It's that simple.

Is it a flaw that mongo doesn't work well on 32 bit systems? Maybe. Probably.

Is it a flaw that you didn't do the requisite research before committing to a
database and subsequently complaining about it? Definitely.

------
jcoder
All I'm getting from this conversation is that there is a heavy prevalence of
Stockholm Syndrome among MongoDB users.

------
pjungwir
I ran into this same nasty surprise building a prototype to store requests in
Mongo instead of Postgres. It was enough to scare me away, too. Glad I noticed
it while it was still just a script+Makefile simulation.

Another problem with Mongo I never heard anyone else raise is that there are
no namespaces. If I install Mongo, all the tables/collections live in the same
namespace. What if I want to use it for multiple projects? How do other people
solve this problem?

~~~
clintonb11
You have multiple databases, just like a sql solution. One database per
project.

~~~
pjungwir
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?

~~~
cheald
"use foobar" creates a new database called foobar.

~~~
pjungwir
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!

~~~
cheald
Nope. Collections are analogous to tables, and documents to rows.

------
louischatriot
I agree with posts stating that you should read the docs before using a tool
you don't know. But I also think that these two really important points should
be mentioned in the Getting Started guide, in bold: \- The 32bit 2GB
limitation (seriously when I started with MongoDB I wasn't expecting this!) \-
The fire-and-forget policy

These are really not points to be discovered in chapter whatever of the docs.

~~~
taligent
It's on the download page:

<http://www.mongodb.org/downloads>

~~~
louischatriot
Indeed. It is definitely not big enough though.

------
frederico
Two paths for working with new technologies:

\- Download, Brief 3rd party tutorial, Production, Break, Complain, RTFM /
Complain

\- RTFM, Smile, Download | Move On, Staging, Production

Seems most of the issues from this article came from a lack of reading and
investigating.

------
ojosilva
I 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.

------
Andrex
Interesting you switched to Couch. I was hesitant to recommend it reading the
post because I feared you were turned off JSON stores entirely, glad to hear
that's not the case.

In general it feels like Couch actually takes storing data seriously. Append-
only and whatnot. It's slower and a little bulkier than Mongo, but it does the
important things right (1.0 bugs notwithstanding.)

I'd love a follow-up blog post on your experience with Couch.

------
eranation
Isn't the write result containing the info? e.g. if the write failed, it will
contain the error if you just check for it? if so, and I haven't checked (but
I assume it's so) then this post is equivalent to ranting on Go's lack of
exception handling. like it, don't like it, it is what it is, you can either
use it, or fork it and make your own database / language.

------
bobx11
The fact that this is on the front page shows that HN is no longer a real news
trading site for real hackers. :(

------
rjzzleep
i 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 the memory
usage. Which means that the only way you can limit the amount of memory used
is by keeping the size of the database below your memory. quite important
things to know imho.

here's an interesting post mentioned in the comments:
<http://www.zopyx.com/blog/goodbye-mongodb>

~~~
pooriaazimi
> _it's not written anywhere _obvious_._

Isn't <http://www.mongodb.org/downloads> an obvious place?

~~~
krzyk
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.

------
markmm
One of the main reasons I hear people advocating MongoDB is it's ease of
horizontal scaling, via replication and auto sharding. I wonder how many
projects have such large data sets that they really require sharding of their
data?

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.

