
Why I am dropping MongoDB for Mysql... - captaincrunch
http://www.blue74.com/?p=25
======
dmytton
There's been a few of these posts recently and in every case it's the fault of
the author either because they chose the wrong product for their use, because
it's not being used as directed or because the unstable versions are being
used.

\- There are no transactions in databases like MongoDB. That's clear.

\- Reported "corruption" and data loss but no reproduce steps. What version?
Did the server crash? Have you reported to the developers? We've been using
MongoDB for over a year in production having started at v0.9 and now using
only stable releases and have never lost any data when we do 5-8k inserts per
second.

\- No joins. It's a non relational database, what were you expecting?

\- Schemaless. Yes - don't make typos / QA your code.

\- Unstable replication. We've had a few issues with replication but nothing
that can be described as "unstable". Again, a general statement "nothing but
problems" without going into specifics.

\- Not stable. I refer above with our long usage history. It's unstable if you
use the dev versions, as expected.

I don't claim MongoDB is perfect, indeed I've written about several issues
we've had[1], but nothing critical or show stopping. It seems it just isn't a
right fit for what the author wants.

[1] [http://blog.boxedice.com/2010/02/28/notes-from-a-
production-...](http://blog.boxedice.com/2010/02/28/notes-from-a-production-
mongodb-deployment/)

------
epochwolf
So...

\- Lack of Transactions

\- No joins

\- Schema-less

If these are important, you really shouldn't have been using schema-less
document database.

\- Unstable

This is the only real point I can give to you unless you were actually running
the bleed edge version. If you were using the trunk/head version you were just
asking for the problems you were having.

~~~
bad_user
> _If these are important, you really shouldn't have been using schema-less
> document database._

What does that have to do with his complaints?

The "lack of transactions" is a lack of MVCC. This has nothing to do with
NoSQL, RDBMSs, document databases, or schemas. Many NoSQL databases do offer
some transactions support ... like CouchDB or the storage in Google's
AppEngine.

"No joins" ... we've been taught for years the virtues of normalization /
relational data, both in school and throughout the industry, and now we should
let go of everything we've been taught. Great, but where are the best
practices / patterns? Where are the books on data-modelling?

"Schema-less" ... it's not really schema-less, it's just that the schema is
defined at the application layer. Again, where are the best practices for
that?

One advantage of MongoDB in combination with something like Rails is said to
be the lack of migrations ... I view that as a disadvantage as migrations are
a great way of documenting what's changed.

To get back to my point ... don't shout at potential users something akin to
RTFM ... educate them instead.

~~~
dschobel
It isn't RTFM as much as do some research before choosing your data store.

The majority of his enumerated gripes aren't unexpected or hidden attributes
of mongodb but fundamental considerations when deciding on a data store.

~~~
epochwolf
And his data loss issues seem to be related to server reboots according to one
of his later comments. MongoDB's docs clearly state that the database must be
shut down safely or data loss will happen. (MySQL is the same way, it gets
really annoyed at hard reboots)

------
kylemathews
And in a moment of pure irony, I'm seeing an "Error establishing a database
connection" message.

~~~
InclinedPlane
Indeed. At the risk of being overly flippant, I'd say "maybe you should go
back." The page is still loading (after several minutes) for me.

~~~
captaincrunch
I am getting DoS'd. Got admins working on it now, I am guessing someone didn't
like my post lol.

~~~
captaincrunch
And fixed.

------
amock
It sounds like he wanted a SQL database all along, so there's not much insight
in this post.

~~~
smharris65
Really? Then why does he say: "In Mongo’s defense- I really like it, and hope
to use it in the future when it becomes stable."

~~~
mattculbreth
Well if one of his primary reasons for going back was that he doesn't like
schema-less databases, then it's a fair thing to say that Mongo was never the
right choice.

Of course he may have needed to do this project to discover that.

~~~
captaincrunch
I'd bite the bullet on schema-less, if it were stable.

------
lazyant
I can't understand why anyone would start a project with Mysql instead of
Postgress.

~~~
Roboprog
I can: my cheapie hosting service only provides MySql. But beyond that, no. I
certainly prefer PostgreSQL at home, and would use it for other projects when
I could. MySQL was simply too late to the "ACID party", and it's hard to
believe they took data integrity seriously.

E.g. - transactions, isolation, referential integrity and other feature were
too long coming. They did provide a free portable DB that ran on Windows early
on and parsed SELECT statements, though :-)

~~~
jasonlotito
> transactions, isolation, referential integrity and other feature were too
> long coming.

They had that years ago using InnoDB. I remember using it in 2003.

MySQL's big thing over Postgres was replication.

~~~
lazyant
My perception is also that replication was lately the only advantage Mysql had
over Postgres in general.

My main problem with mysql is that I have seen too many data corruptions and I
can't find anyone who has worked with both systems and doesn't recommend in
general pg over mysql.

~~~
moe
FWIW, Dead-simple replication is in the current postgres beta and due to enter
stable soon.

Here are the docs: [http://developer.postgresql.org/pgdocs/postgres/hot-
standby....](http://developer.postgresql.org/pgdocs/postgres/hot-standby.html)

Oh, and unlike the MySQL replication this implementation can not silently lose
or corrupt data.

In fact the above document could also be considered "The missing Manual for
MySQL replication". It tells you all the things that MySQL _doesn't_ take care
of.

------
vlucas
Having spent the past 30 minutes trying to get this guy's web server to even
return _anything_ , I'm thinking he may reconsider...

~~~
captaincrunch
Was getting DoS'd. It's fine now.

------
joubert
Would CouchDB be a viable alternative to MongoDB?

~~~
jchrisa
CouchDB is designed from the ground up for reliability, so there's no chance
you'd have data go missing, even in the case of crashes and system reboots.
CouchDB also offers strong consistency guarantees on a single node, so you can
use it for things like banking. So... yes.

------
jaytee_clone
I remember somewhere in MongoDB documentation that states why you shouldn't
use Mongo for sensitive information (i.e. money related) because of the lack
of transaction. (No reference, but obviously I read it somewhere because I
remembered it.)

Maybe he skipped that part?

------
latchkey
<http://www.mongodb.org/display/DOCS/Durability+and+Repair>

"Of course, some problems require greater durability: we would not recommend
using it for a bond trading system."

~~~
captaincrunch
Indeed we are a trading system :o

------
benologist
Why would records disappear?

~~~
mdirolf
Tried to comment on the post, but so far still "Awaiting Moderation". I have
never heard reports of missing documents w/ a production release of MongoDB
(or a dev release, for that matter). Would love to help debug whatever issue
he saw, but will need more info than that post gives.

~~~
dolinsky
Mike, you must have super ears. Let it be a testament to how much you care
about MongoDB that I see you very often popping up offering to personally lend
a hand helping someone who is having a problem. The handful of production
environments I have either used MongoDB in or know of have never had a problem
of missing documents when using a production release (or even 1.5).

~~~
mdirolf
Thanks! Glad to hear that the effort is appreciated :). We all try pretty hard
to make sure everyone has a good experience with MongoDB.

------
rit
yet again the important question:

Which version was he using? I've never had data loss in a year of production
using the "stable/production" version of MongoDB.

~~~
captaincrunch
Was using 1.4

------
mkramlich
problem: use SQL _or_ NoSQL?

proposed solution: use SQL _or_ (SQL _and_ NoSQL)

