
MongoDB is to NoSQL like MySQL to SQL - in the most harmful way - davvid
http://use-the-index-luke.com/blog/2013-10-01/mysql-is-to-sql-like-mongodb-to-nosql
======
smoyer
I think there's one other problem that affects most NoSQL systems - the
perception that adopting a NoSQL means you don't have to think about your
data. When designers and front-end developers want to develop a web
application they can do one of two things; a) say "don't worry about the back-
end, we'll just throw it in a NoSQL database" or b) learn to also be a back-
end engineer.

The idea that you don't need to worry about your data structure is deadly.
Every successful project I've been involved with thinks seriously about the
data model. ER diagrams with 160 tables aren't uncommon and knowing the
structure of your most common queries helps you make sure that your database
isn't over-normalized. There's a science to data systems after all.

"Show me your flowchart and conceal your tables, and I shall continue to be
mystified. Show me your tables, and I won't usually need your flowchart; it'll
be obvious." \- Frederick P. Brooks from The Mythical Man-Month.

I quote or paraphrase this fairly frequently as I've come to believe it. If I
understand your data structures, I can pretty easily tell what you might be
doing with the system and I can read the code to see which parts you've
implemented. But don't use this as an excuse to delay working on the rest of
the application. There are Architecture Astronauts in the realm of database
modeling too!

"Normalize until it hurts, denormalize until it works!" \- Unattributed adage.

The key is to understand your data (and it will provide an amazing boost to
the rest of the project). If you're worried about having your data-model
perfect before you start coding, you should have started coding already. There
are practices you can adopt that make refactoring your database more tenable.
I recommend you read the "Evolutionary Database Design" article by Martin
Fowler and Pramod Sadalage
([http://www.martinfowler.com/articles/evodb.html](http://www.martinfowler.com/articles/evodb.html)),
then adopt a workable technique as a team.

~~~
kamaal
I will go further on to say. The biggest problem is the perception that a
particular tool will make up for bad practices, general indiscipline and many
other small time problems.

If you start with such an assumption only bad can to the project.

MongoDB has its uses, but if you are making an assumption that its going to
make up for SQL related use cases then you shouldn't be surprised if the
consequences are going to be disastrous later on.

~~~
smoyer
Well-said!

------
goldenkey
I think the biggest lesson here for us engineers is that we should watch and
brace ourselves for similar tech buzz offerings like MongoDB. A few years when
I went for interviews for startups, it was shameful that I didn't have
experience and wasn't using MongoDB in my own products. I was a 'rusty spoon'
for using resilient SQL. Funny how even engineers, a whole industry, can get
swept up in using a subpar data store because it's the new cool piece of tech
that makes it easier to have json you throw to a wall stick. I will never feel
shamed again for not using some hot shot popular offering only because it
makes development a tad bit easier. As engineers the end result is most
important and we shouldn't sacrifice our platform stability just to ease our
code editors and some minor migration frustrations. /endrant

~~~
zimbatm
The key argument is that nobody knew the performance characteristics. While
developers looked at the API they where enchanted by it's perceived
simplicity, but knew nothing about the behaviors of the database under load.
Understanding the various tweaking parameters and failure modes is an even
more important part of any database than the API in production.

------
amix
MySQL was a great database that solved a problem. It did not solve it in a
100% complaint way, it did not have all the features that "dbms experts
wanted", but in the early days it was very easy to started. In version 5+ they
have fixed a lot of the issues and it is now on-par (or better) than most
other databases. I also think they have focused on the right stuff: ease of
use, easy way to fix performance issues, great ways to setup replication,
great ways to take backups, not losing data, optimized to be used for the web
etc. Also, most bigger properties (including Facebook and Google) use
extensively MySQL.

If Mongo is going to be like MySQL, then great!

~~~
lucian1900
MySQL still isn't on par or better than its most comparable peer, Postgres.
It's still nowhere near as terrible as Mongo, but let's not pretend it's
amazing when it's merely serviceable.

~~~
amix
Postgres got proper non-hackable replication in version 9... And it still
isn't that great.

~~~
asdasf
"Isn't that great" how? In that it imposes a bunch of limitations on you? Or
that it frequently breaks and slaves have to be manually syned? Oh wait no, I
was thinking of mysql.

------
dschiptsov
If PHP is a fractal of bad design, then MongoDB is PHP of database world.)

As for MySQL, Mongo marketing guys have learned the lessons from MySQL very
well - there are nothing but "satisfied users", "good documentation" and
"quickness and easiness" (any thinking, leave alone understanding aren't
required) on their site and paid content - well-done "product", designed to
trigger an ignorant consumer snap-judgement, the same way MySQL did at its
time. They use the same sales strategy.

[http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-
de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)

~~~
rodgerd
At least the MySQL guys eventually gave up trying to convince us that
referential integrity is a crutch for sub-par programmers.

~~~
dschiptsov
What referential integrity?) It is _My_ free SQL, everybody's using it. Table-
level locking? Never heard of them.)

~~~
chris_wot
Not sure what you are referring to here, but MySQL definitely has referential
integrity constraints, and InnoDB uses row level locking. Not sure what level
of transaction isolation support is build in though.

~~~
dschiptsov
The InnoDB was not the default storage engine for quite a long time and it
wasn't stable-enough for years.

~~~
chris_wot
OK, I'm not a huge fan of MySQL, but InnoDB is what is used now. I'm only
really interested in the latest releases of MySQL.

------
jed_watson
Honestly, I see very few thought-out or backed-up arguments here. The server-
level blocking, the unacknowledged writes, silly defaults, etc are not only
old news but have been behind mongodb for a while.

You also get comments like 'it still has database level locking' but rarely is
there an educated discussion about the work that's been done to yield locks as
quickly as possible and the real-world impact of this design.

People seem intent on punishing the platform for old mistakes (or immaturity)
rather than providing a balanced view of it today. And comments like
"Absolutely no benefit to Mongo. It's even really slow, so there's really no
advantage at all." are just misleading without context, because it's at all
true as an outright statement.

I spent today at the MongoDB developers conference in Sydney, and heard the
CEO speak about when they think mongodb is good vs when you should use RDBMS,
heard them speak about their community and target market, and heard a lot of
stories and strategies about how to prepare for scale, how to think about
schema design, how to monitor and admin the database / clusters, etc.

I'll just say that from hearing them in person, and hearing what people say
about both the platform and the "marketing guys", you'd never know they were
talking about the same company or product.

My own company has had a lot of advantage from using MongoDB in recent
projects over other technologies (we have a largely MSSQL background). No, we
don't do 100GB+ "web scale" (yet). Yes, we build solutions to real world
problems and make money. No, it's not a silver bullet. Yes, you should know
what you're doing and read the docs.

To any hackers / entrepreneurs who are thinking that MongoDB might work for
them I'd say do some research, talk to people who've actually used it, and
understand the benefits / limitations for yourself.

But stay away from opinions not based in real experience (and anything that
mentions problems from before version 2.4, it's nearly a year old people) or
you might miss out on something good.

~~~
jaxytee
Not to mention that the authors only critique of MongoDB was global write
locking from version 2.2. The rest of his article was empty text speaking
NOSQL databases his friends think are cool and statements equating too
"MongoDB is bad. Why? Cause it is."

All if this ends at his signature that mentions his scaling SQL book. Not like
he has an axe to grind or anything.

------
CalRobert
Sheesh, what's with the MongoDB witch hunt? It seems like HN can't go 2 days
without some disparaging of MongoDB. I get it. I'm an idiot for using MongoDB
even though it suits my needs perfectly.

~~~
nailer
I'm a long time (3 years) MongoDB user. My experience of the current state of
the art:

\- The official documentation is clearly written by someone who doesn't speak
English as a first language.

\- Their official driver (Node.JS 1.3.13) silently throws away exceptions.

Both these have been acknowledged by MongoDB Inc (formerly 10Gen). I can't
speak for you, but personally I do feel like an idiot for using MongoDB.

------
dmak
From my experience, as soon as you need some kind of relation with Mongo, you
end up writing more application logic to create and maintain your relations.
This probably means you should move to a relational database.

For Mongo specifically, can anyone share a pragmatic use case where you did
not run into problems with duplication?

~~~
jzwinck
One example is logs. People have logs, and lots of them. They're usually semi-
structured (hopefully there is at least a timestamp and topic and severity in
each record). You can put them in MongoDB, and relations are probably not a
big concern.

~~~
digitalzombie
Elasticsearch or Solr would be better than Mongodb for Logs.

Hell if you actually care about your log and want to search it use Solr or
Elasticsearch NOT Mongodb.

If you want to store even more data just use Cassandra and index it with Solr
or Elasticsearch.

Cassandra have faster write than read, it's perfect for logs.

You can decentralize logging system too, there are architecture layout out
there with elasticsearch and such (example: [https://medium.com/what-i-
learned-building/e855bc08975d](https://medium.com/what-i-learned-
building/e855bc08975d)).

MongoDB is a poor choice, in general for anything in my personal opinion.

------
egil
Earlier discussion:
[http://news.ycombinator.com/item?id=6481526](http://news.ycombinator.com/item?id=6481526)

------
kayoone
I have never really touched NoSQL for anything serious, yet i have worked with
Riak, MongoDB and Redis. In the case of MongoDB i have worked with an ODM on
top of it where i had to define a Schema and Object relations and was left
wondering: What is the benefit of this anyway if i still define Schemas and
relationsships ? Does it just make sense at a big scale when i would have to
shard using MySQL ? Schema migrations arent that hard today in MySQL with a
good framework, so i am not really sold on the benefits for smaller apps. If i
can just save a JSON Object to it, thats cool (however Postgre is goot at that
too), but in practice with server side validation and schemas i have to
decode/encode anything anyway. Can anyone enlighten me on the real benefit ?

 _Edit_ I see many benefits in using Redis though, just for its sheer speed
and more as a smart memcached replacement though.

~~~
lucian1900
Absolutely no benefit to Mongo. It's even really slow, so there's really no
advantage at all.

Redis, Riak and the like are actually useful for a change.

~~~
annnnd
MongoDB slow? Could you post a benchmark to support this claim?

~~~
chris_wot
He wasn't saying that MongoDB is slow...

~~~
annnnd
Sure he was: "Absolutely no benefit to Mongo. It's even really slow,..."

~~~
chris_wot
He did indeed, but it was in response to the following questions:

"In the case of MongoDB i have worked with an ODM [by which he means ORM] on
top of it where i had to define a Schema and Object relations and was left
wondering: What is the benefit of this anyway if i still define Schemas and
relationsships ?"

~~~
kayoone
i actually meant ODM which refers to Object Document Mapping in contrast to
ORM which refers to Object Relational Mapping

eg: [http://mongoosejs.com/](http://mongoosejs.com/) [http://docs.doctrine-
project.org/projects/doctrine-mongodb-o...](http://docs.doctrine-
project.org/projects/doctrine-mongodb-odm/en/latest/)

~~~
Zak
MongoDB stores JSON (in binary form) - serialized Javascript objects. That
there is what looks to be a large and polished library for mapping between the
two is a huge red flag to me.

------
hakcermani
What is this ? 'Lets bash mongodb' week ?

~~~
elchief
And 'make sweet love to Postgres' year

~~~
chris_wot
It's been a truly great year so far!

------
annnnd
Come on, give MongoDB a break. I use MongoDB and I am proud of it. And I have
used numerous SQL DBs (MySQL, PostgreSQL, Oracle, MSSQL, SQlite) and HBase
from noSQL camp, so I do have something to compare to.

Yes, it was overhyped (and is underhyped now, at least on HN). Yes, it has its
problems. Yes, it is not correctly positioned in people's minds (web-scale?
not really). MapReduce on top of MongoDB, in a single-threaded JS engine - are
you kidding me??? But it is useful tool nevertheless; one I am happy to have
in my arsenal.

MongoDB will NOT solve your scalability problems. Old news. It will even add
some of its own problems on top of it. But man, is it nice to just fire that
data into your database and forget about DB-level schemas... And when you need
that data, it is just there. True, I have built an ORM on top of MongoDB so it
manages the DB for me; but it was easy to do and is incredibly useful. I would
have done it with MySQL too (actually, I did - and it was a PITA to build
because of relational databases' rigidness).

So please, stop bashing MongoDB for wrong reasons. It is an excellent and easy
to use storage - when used for the right kind of problems. Nothing more,
nothing less.

~~~
chris_wot
How did you build an ORM on top of MongoDB? And why?

~~~
annnnd
Sorry, poor choice of words... I have build an ORM on application level above
MongoDB.

This level lets me specify data model in a simple JSON and the system then
automatically performs all (high-level) data input validations, displays a
proper web form to the user,... There are actually many similar systems to
mine, I just couldn't find one that would offer all the functionalities I
needed.

Note that DB is just a storage for me. It can't know enough to validate for
example e-mails, because for DB they are just strings.

~~~
chris_wot
That's not an ORM, that's a data abstraction layer.

~~~
annnnd
It's actually both. Term "data abstraction layer" describes its function while
term "ORM" describes how it is done. Unless I am misunderstanding these terms?

But we are going a bit off-topic here. :)

~~~
chris_wot
An ORM maps a relational database to objects. Given MongoDB is most definitely
not relational, you can't have implemented an ORM :-)

~~~
annnnd
That's an excellent point! :)

I was so used to thinking of this system as an ORM that I never checked if the
term still applies. So... I guess it is OnoRM now. ;)

~~~
chris_wot
What were you mapping?

------
lucian1900
This isn't really being fair to MySQL. It was pretty terrible when it started
out (corrupted data, no joins, no transactions, silly locking, didn't support
half of SQL, etc.), but we must not forget just how terrible Mongo was and
still is. It shipped with unacknowledged writes as the default for a long
time.

------
smanuel
> The article is about handling MongoDB if it grows above 100GB. It gives me
> the impression that scaling MongoDB to that size is a serious issue.

I don't think so. It gives me the impression that 10gen (MongoDb Inc.) has
made a mistake how to present "handling MongoDb over 100GB".

> example: global write lock up to release 2.2

Why are we still talking about this? It's not global write lock any more,
okay? Stating previous inefficiencies doesn't bring much value to the table.

> At this point it was inevitable to see MongoDB as a popular, yet poor
> representative of it’s species.

Show me the real arguments! Show me the real arguments!

~~~
spamizbad
> Why are we still talking about this? It's not global write lock any more,
> okay? Stating previous inefficiencies doesn't bring much value to the

It's now a db-level lock, which is an improvement but not optimal. And its
locking system in general isn't as sophisticated as, say, a recent version of
Postgres, MSSQL, or Oracle.

Neither is its query planner, where using an $or can cause it to scan all the
documents in a collection despite the fact that you should technically be
hitting indexed fields.

~~~
annnnd
> ... despite the fact that you should technically be hitting indexed fields.

Never had that experience - could you elaborate? Indexes in MongoDB are a bit
different from SQL indexes, so if you are comparing to that, you are in for a
few surprises. :)

------
treskot
This discussion has happened before.

MySQL is to SQL like MongoDB to NoSQL -
[https://news.ycombinator.com/item?id=6481526](https://news.ycombinator.com/item?id=6481526)

------
mcphilip
My guess as to the rise of MongoDB usage is that the rapid application
development needs of the startup world led to people deciding that
representing application data as JSON across all tiers speeds up the early
stages of development. Unfortunately, as soon as data needs to be used
relationally, developers are finding themselves pigeonholed in an
inappropriate persistence format.

In short, developers that skip studying how their data might need to be
queried in the future are to blame, not MongoDB.

------
simlevesque
I've heard that some people use the MongoDB syntax with postgresql using redis
as caching, could someone comment on this idea ?

~~~
chris_wot
I question their sanity.

------
johannh
So he's saying MySQL is bad, and MongoDB (because of a statement on their home
page) is kind of like MySQL, so MongoDB is also bad. Also there was some
article about scaling it to "only" 100GB which means it damages NoSQL as a
whole in the "most harmful way".

Sorry but I don't really get the reasoning.

~~~
goldenkey
MySQL is an awful implementation of SQL. MongoDB is even more pitiful of an
implementation of NoSQL. It's a Fischer price database that had a global write
lock until version 2.2. What exactly don't you understand about the analogous
nature of two crumby data stores?

~~~
johannh
So what exactly makes Mongo such a bad implementation (apart from things that
were already fixed)?

I don't mean to defend MongoDB, i'm genuinely interested in finding a better
NoSQL DB. I just usually get to hear the same "Fisher price" bashing without
any real arguments.

~~~
chris_wot
The problem you have is that there are different types of NoSQL databases. Key
value stores, document stores, graph databases, you name it they have their
own specialty.

NoSQL's name shows just how nebulous the concept is. It was first coined by
someone who built a relational database but without implementing SQL, then it
was later used to describe distributed, non-relational databases that ignored,
downgraded or discarded some form of ACID. Now it can be a retronym for "not
only SQL".

In this space, work out what your actually needs are, then carefully research
the technology and pick whatever is most appropriate.

------
rainmaking
I never understood what Mongo brings to the table that ext4 doesn't.

------
threeseed
Does this offer absolutely anything new ? No.

Is this person objective and well respected ? No.

Does this person understand why MongoDB/MySQL is popular ? No.

Is anyone going to gain anything from this ? No.

~~~
davidw
> Is anyone going to gain anything from this ? No.

Well, if it stops someone from using MongoDB without _really_ thinking about
whether they ought to, maybe it'll save someone some grief in the future.

~~~
threeseed
If this was an intelligent piece analysing the pros/cons of MongoDB and when
it would be an optimal choice then I could understand it. But this is the
equivalent of blog spam from a guy who is selling a SQL Performance book.

~~~
goldenkey
Many articles regarding MongoDBs awful memory mapped simple b-tree data
storage method have popped up on HN. Martin is merely talking about the
politics of MongoDB; to call his links to polyglot methods and his information
blog spam is dishonest to say the least. I thought it was a great post and I
bet many other HNers who up voted it feel the same way.

~~~
annnnd
> MongoDBs awful memory mapped simple b-tree data storage method

You realise that they are using default kernel implementation? Awful indeed.
:)

If you are so anti-MongoDB, would you care to offer an alternative? It must
support: \- document-like storage (I already have schema on application
layer), \- simple use / administration, \- hot backup, \- single node
operation.

While this list is mostly outlining why MongoDB is a great DB for my current
use case, I am also genuinly interested in better solutions (for that case).
So, fire away... :)

~~~
leif
Let's see if I can make your day with a shameless plug.

First of all, using the kernel's paging algorithm for a database is awful. It
has way less information about your access patterns than the database, so it's
going to make a lot of bad decisions, and a bunch of MongoDB's problems with
fragmentation and performance cliffs come from using mmap. It's quick and
dirty.

Here's the alternative, and it supports the exact same document storage as
MongoDB, the same administration interface, actually the same protocol
everywhere, hot backup, and however many nodes you want: TokuMX[1]. It does
all those things because it's actually mostly MongoDB, just with the storage
engine replaced with an engine that works faster, compresses your data, and
has more mature things like document-level locking for writers and better
multi-document isolation semantics on a single node. Give it a whirl and let
us know if you like it.

[1]: [http://www.tokutek.com/products/tokumx-for-
mongodb](http://www.tokutek.com/products/tokumx-for-mongodb)

~~~
chris_wot
Why is it called a "fractal tree"?

~~~
leif
Marketing. No technical reason.

~~~
chris_wot
From what I can tell, this has been patented, but was implemented in part by
Postgres much earlier.

~~~
leif
I promise it hasn't, but I'm curious to see what you're talking about. Link?

~~~
chris_wot
See this thread: [http://www.postgresql.org/message-
id/511BDCAB.2080803@agliod...](http://www.postgresql.org/message-
id/511BDCAB.2080803@agliodbs.com)

~~~
leif
That thread is talking about the possible inclusion of our indexing library
inside Postgres, and was from before we had open sourced the code. IANAL but I
think it would be possible to include the fractal tree library in Postgres now
if someone wanted to do it, but none of it has ever been implemented by
Postgres.

~~~
chris_wot
I stand corrected! Thanks for the info.

------
Kiro
Tired of this. I think MongoDB is the best thing ever!

------
puzanop
Not surprised that a person who gets his salary with SQL work is unhappy with
a competitor that does not use his favourite word...

