

The growing irrelevance of MongoDB - jraedisch
http://www.itexto.com.br/devkico/en/?p=60

======
kicolobo
Actually, they posted thw wrong link. That article is not written by
wwwdesigned, but by me. Here is the original text:
[http://www.itexto.com.br/devkico/en/?p=60](http://www.itexto.com.br/devkico/en/?p=60)

~~~
jraedisch
I actually came there via two other aggregators (Twitter and Prismatic) and
thought that I had found the source. Will be more careful next time - sorry
about that. In any case it was an interesting read.

~~~
kicolobo
Thanks!

------
collyw
I have seen many people try and shoehorn various problems into MongoDB, when
in most cases a relational database would have been better suited.

I have yet to see a real use case for Mongo unless you are building a Facebook
clone. Can someone suggest when it is actually useful over a properly tuned
relational database?

I guess I kind of reached the irrelevance stage just thinking about the sort
of problems it would be suited to rather than actually building anything.

~~~
Harrisburg
Think of an Amazon like product catalogue.

I don't want to create a schema in a relational database for that kind of use
case. A MongoDB fits as well.

Edit: Sorry for my short and unprecise comment. I regret posting it, loosing
all my Karma. Yes, of course I would use a schema, but I may use hundreds to
get my products presented with all attributes and variants available. There is
a set of attributes that will remain for all products, others will vary, some
will change and will be dropped. Some may be conditional, depending on size or
color. I could model that in RDBMS as well, adding those properties in an
additional JSON or something else.

Yes, I'm also mainly using relational databases and just wanted to give an
example of a use-case for MongoDB. I regret, sorry.

~~~
crdoconnor
So what happens when you want to list all of the products in a category?

~~~
Harrisburg
query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'})

@see: [http://docs.mongodb.org/ecosystem/use-cases/product-
catalog/](http://docs.mongodb.org/ecosystem/use-cases/product-catalog/)

I personally miss Joins in MongoDB - but other vendors support Joins.

~~~
ris
There - you're consistently using a field named "type" across your objects -
you're using a schema.

~~~
onion2k
Not quite. The 'type' in the example is a _label_ for what it contains - it's
wholly semantic - as opposed to a _field_ that would exert some sort of
constraint such as describing the data type, collation, restraints, etc.
Schemaless databases don't completely abandon all forms of organisation
because that'd be unusable. They just make the organisation looser. For
example, if the user wanted to they could add a record to the products in that
example that doesn't have a 'type' (although in the case of that example that
probably wouldn't be useful).

~~~
takeda
The thing is that in order to use that /label/ you need to write logic to
handle it in your code, ultimately you end up implementing schema, the only
difference is that you enforce it in your application. This label becomes not
much different than a column in database that is nullable.

Now things become more hairy when you realize that perhaps you want to keep
more information about the actor so for example you want to change
details.actor to details.actor.name. You will have two choices, either run
through your database and modify all documents (which is something similar to
RDBMS is doing) or write code to handle both cases. The second one seems
easier, but as you'll have more changes it'll come back and bite you hard.

Later in the future you might realize that by repeating details about actor
for every single movie you simply not only wasting a lot of resources (your
database is bigger and slower) but also this affects integrity (in one movie
perhaps you include actor's middle name, or maybe you have a typo).

At that point you'll start creating a collection that holds actors and then
only store key of it in "details.actors". You will soon realize that you're
basically reimplementing a relational database on top of Mongo, except not
only it is way slower, your application is becoming more complex.

There are uses for NoSQL, but whenever you have to ask yourself which model
you should go with pretty much always the answer will be: relational.

------
nchelluri
Unfortunately I didn't find much information in the article.

Basically I got out of it:

\- he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web
framework/AngularJS/Node.js)

\- he found that for document oriented purposes MongoDB could sometimes be a
nice fit

\- he found that replacing MongoDB with the drop-in replacement TokuMx (seems
like a MySQL/MariaDB type of idea), he could get a big performance increase

\- he found that with Postgres 9.2+ using the JSON/document storage there he
could get some of the relational benefits and some of the document benefits,
and ACID

\- he likes ACID because of transactions/handling multiple documents at once

Ok, so I guess I was wrong, there is a bit there. But: this is all stuff that
I've heard several times about MongoDB.

One of the things he got into was that he learned when MongoDB was appropriate
and when it wasn't -- but IMO he didn't really go into detail here other than
to say: joins and transactions. I wish there was more substance than that.

I also seem to recall reading recently that even supposedly ACID compliant
databases have problems with transactions under load and that the only way to
really get full ACID compliance is to treat transactions as serializable -
perhaps I am wrong but I think this is the gist of what I've learned.

Personally, I'm working on a project right now that uses MongoDB and I
definitely do miss joins, transactions, and schemas. I am not even remotely
sure where one would benefit from a system that had documents with arbitrary
fields in it. (I didn't pick the technologies for my project.)

I would really like to know when to choose which database - I feel like I know
the bare basics of several, and none of them in depth. I really don't have
time to learn them all. I feel like even when I'm building one application
it's only some months after deployment that if I'm lucky or made a mistake
that I will run into some actual performance constraint.

~~~
crdoconnor
>I would really like to know when to choose which database

I have asked this question before - under what situations is Mongo not _just_
equally good as Postgres - but actually better?

The only really coherent answer was that it was easier to configure
replication (presumably because it chooses a lot of defaults for you). I'm not
even sure that was a good thing given the number of obscure bugs that can
arise from incorrectly configured replication.

Postgres even seems to be more performant at NoSQL use cases (using the JSON
store) than Mongo, which is frankly embarrassing.

------
bigiain
MongoDB 2.8 (in RC4 right now, due out "in early January" last I heard) has
the WiredTiger storage engine, and as well as high performance and compression
also gets document level locking and multi document transactions. The roadmap
says this'll become the default storage engine in 3.0 (3rd quarter 2015). I
think the blog author's claim that for basically those omissions "MongoDB can
still beat TokuMX on a future release. But only in a future release. Today it
can’t." observation is only true if you ignore the development releases
completely, and will be incorrect within a week or two.

Sure, if you want SQL or traditional relational database, a traditional
relational SQL database is a better choice. Using Postgres or Oracle for
workloads better suited to tied hashes or BerkleyDB doesn't automatically
become "right" though.

~~~
jraedisch
Could you provide a source for "multi document transactions" support in 2.8?
According to this comment they are supported by WiredTiger but won't be in the
MongoDB API anytime soon:
[http://blog.mongodb.org/post/102461818738/announcing-
mongodb...](http://blog.mongodb.org/post/102461818738/announcing-
mongodb-2-8-0-rc0-release-candidate-and#comment-1710534263)

~~~
dm_mongodb
you are correct, that's not in 2.8. might want to follow this jira:
[https://jira.mongodb.org/browse/SERVER-11500](https://jira.mongodb.org/browse/SERVER-11500)

that said it will be a big release in other aspects, with pluggable storage
engines now, and WiredTiger specifically.

------
gasping
MongoDB will always be a relevant example of false advertising and over-
marketing (to the point of 10gen probably opening themselves to litigation)
and how we all need to stop drinking the kool-aid.

There is LITERALLY no reason to use MongoDB today. If you're thinking of using
MongoDB, for the love of god just try PostgreSQL.

~~~
mwj
this is a ridiculous comment.

we use a mongodb cluster for a multi-hundred GB document store that powers ~50
various worker instances, 2 sites and an API with sub 100ms response times. we
have never lost data or experienced downtime worse than other dbs i've used in
the past.

at the end of the day you just need to do your job properly and read the
documentation, not blame the tool when you can't use it properly.

*disclaimer - this is not to say postgres isn't awesome.

------
Harrisburg
I can't agree. MongoDB 2.8 with WiredTiger is a performant NoSQL solution.

The way you solve things in document dbs like MongoDB is the key - not the
fact that you get competitve performance in RDBMS as well.

I like Postgres and the possibility to easily use JSON data. But I still
prefer to build applications the NoSQL way...

------
octix
It may be hype, but when MongoDB was released, what other RDBMS was offering
the same functionality? I see Posgresql + JSON mentioned, but when was JSON
support added?

I personally like MongoDB for: \- flexible schema (less migration pain) \-
easy tags implementation \- product attributes (list of name-value pairs) \-
GridFS - store binary files \- nested documents for analytics (ex: a record
for each day with a nested doc for each hour)

I wish MongoDB had \- some support of join \- multi-master replication

I personally used MongoDB as primary storage (yeay dot me), but currently
prefer it as secondary storage.

As any product it evolves and I expect to see more improvements. I think
MongoDB brought NoSQL to the masses :)

Just my 0.02. Thanks.

~~~
snird
Everything you said is true, but I don't think the argument here is about the
past, but rather about the future.

MongoDB was great and innovative compared to other solutions when it started,
but now, it's dragged behind while other solutions are much better.

~~~
jbergens
Then we should probably compare other NOSQL solutions to relational databases.
Like CouchDb, CouchBase, FoundationDb, Neo4J, etc.

------
jnaour
Probably this link:
[http://www.itexto.com.br/devkico/en/?p=60](http://www.itexto.com.br/devkico/en/?p=60)

------
jraedisch
If transactions are the biggest problems, there are driver solutions like
[http://godoc.org/labix.org/v2/mgo/txn](http://godoc.org/labix.org/v2/mgo/txn)
for that. I am not sure, how they compare to "real" transactions. Still
missing "joining" in some cases though. Otherwise I am ok with MongoDB so far.

~~~
politician
Jeez. Please do not mention client-library-managed transactions and then put
"real" transactions in scare quotes. At least read the Wikipedia article
first.

~~~
jraedisch
I just wanted to distinguish between the two. I wasn't scared in any way but
read up on scare quotes now - so thanks for that.
[http://en.wikipedia.org/wiki/Scare_quotes](http://en.wikipedia.org/wiki/Scare_quotes)

------
anilmujagic
I never understood the hype around MongoDB. Maybe it is the fact that I
started programming when SQL DBs were the prevalent/mainstream option, and got
too much used to it... Anyways, Im glad people are recognizing the hype and
realizing that RDBMS has enough to offer.

------
scarygliders
Site seems to be overloaded or broken in some other way.

Google cache :
[http://webcache.googleusercontent.com/search?q=cache:wwwdesi...](http://webcache.googleusercontent.com/search?q=cache:wwwdesigned.com/growing-
irrelevance-mongodb/)

------
FallDead
Nice writeup, I always felt mongodb as a really fast product prototyping
database . After you get to certain point you in web scale I would guess you
would use one of these alternate solutions.

------
crzrcn
The submission url is malformed :(.

~~~
tech-no-logical
I think it should be

[http://www.itexto.com.br/devkico/en/?p=60](http://www.itexto.com.br/devkico/en/?p=60)

