
The Verdict on MongoDB - sylvinus
http://www.rackspace.com/blog/the-verdict-on-mongodb-from-devs-and-ops/
======
cmer
Here's my verdict in MongoDB after using it for a few years in a very high
traffic application:

I personally love most concepts behind Mongo. Schemaless, simple replication
and sharing, JavaScript console, just to name a few. MongoDB is pretty much my
dream database.

However, the ugly truth is that it doesn't work as advertised (this was 2-3
years ago). Replication would often crash or stall leaving us with only one
option: DELETE OUR ENTIRE DATA SET and start fresh. Acknowledged by 10gen at
the time. This happened 3 times.

Mongo was fast until we hit a wall. That was was at around 200GB for us, which
is not that much when you put things in perspective. It was ridiculous.
Running a given query took 1 ms and running it again right after could take up
to 15 seconds. You'd think the second time would be faster.

The global write lock is just insane. This simply cannot work in a high
traffic application. Our app was write heavy and this bit us in the ass quite
a bit. We didn't feel this until much later, after we were fully invested in
mongo.

Lastly, 10gen was literally the worst tech company I ever dealt with. They
we're plain disrespectful to me, calling me cheap for not wanting to shell out
100k/year on a support contract. I was willing to pay them their hourly
support rate (which is very high, but that's fine) to have them fix their
replication bugs with our dataset.

For us, MongoDB was a terrible mistake that I'll never make again. I'm glad
the truth has been coming out over the last couple of years.

~~~
bsg75
> Running a given query took 1 ms and running it again right after could take
> up to 15 seconds. You'd think the second time would be faster.

Were you able to determine why this was? It does seem backwards, given the
data should be cached at some layer.

~~~
cmer
We never figured it out...

~~~
bsg75
Was this issue raised with 10gen?

Either way, was your experience the per-incident support was lacking because
you did not have a support contract?

It becomes interesting, because for $100K per year, I could budget for a lot
of choices.

~~~
cmer
They refused to give us per incident support because they figured we could
afford the yearly support plan (this was post acquisition at a public company)

We eventually just gave up on the whole thing.

------
gaoshan
To be fair this is an article that takes the opinions of employees of
Rackspace, specifically, to deliver it's "verdict" which isn't a verdict so
much as a collection of pluses and minuses. More importantly, Rackspace offers
a Mongodb service (which they plug at the end of the article) so take their
opinion with a grain of salt.

Kind of like a Chevrolet dealer writing an article offering a "verdict" on the
Chevy Volt that consists of opinions of Chevy engineers and mechanics and
ending the article with a link to their showroom selection. Not invalid but
not objective and not really a verdict.

~~~
AdrianRossouw
that's the same reason i discount any of these type of things from
mongodb.com, which are pretty well resulted in the search results.

especially because the only reason I can see for everybody using mongodb is
because it's popular.

------
zenonu
Schemaless databases are such an awful concept for any data you actually care
about. After 12 years in the industry, I've realized any natural controls
(e.g. schema) you can place on maintaining the integrity of your data, the
better off you'll be long-term.

Data matters the most. Your UI will be a tired POS in 3 years. Your backend
data store won't scale for your new business problems. It'll be time to
migrate, and then you'll start by asking yourself how clean and well-managed
your data is.

~~~
lampe3
you can still do schemafull databases with NOSQL databases but its in your
hands to do it or not do it.

All the problems you list you can have on SQL databases too It has to do with
discipline to keep your data clean not with SQL or NoSQL

~~~
dasil003
Oops! He didn't say NoSQL or SQL anywhere in his comment.

------
troymc
Maybe it makes sense to use MongoDB when you're just getting started, before
you fully understand the data, so it's easy to add new attributes/columns etc.

But why even bother with MongoDB? You could just use a text editor to make
bunch of JSON text files, with one record per file.

Then, once you better-understand the data, and you haven't made many "schema"
changes for a while, you can set up a SQL database and import everything.

~~~
fiatmoney
One better: use a SQL database with a PK, and a text field containing your
JSON data. If your DB is Postgres, it'll even let you parse & query the JSON
on the DB side.

------
angrybits
I think this article is just google bait, there is nothing of any real
consequence in it.

------
nailer
What about reliability? Current stable official node mongodb native driver
throws away exceptions in callbacks, as acknowledged by MongoDB Inc.

There have been other 'surprises' in the past.

------
zemo
>Modern web applications that have to scale for millions of transactions

except MongoDB doesn't support transactions.

>Initially, the lock scope of MongoDB was database wide, but later versions
have a scope per database.

that's just an editing error, it should say that initially the scope was
instance wide, but now it's database wide.

------
benwilber0
what was the point of this article other than to just plug their hosted
mongodb service

------
ww520
This reads like an advertisement for MongoDB. Is it the real verdict?

~~~
bobzimuta
That's a resounding Lana-like _yuuuuup_.

------
AdrianRossouw
I was trying to get feedback on this in an ask hn earlier:

Ask HN: When is MongoDB the Right Tool for the Job?
[https://news.ycombinator.com/item?id=7446919](https://news.ycombinator.com/item?id=7446919)

 _edit_ added title of post.

------
fooyc
Well, as a dev I'm obviously not a fan or Eventual Consistency at all.

