

Mongo: Mr Right... or Mr Right Now? - jbkring
http://blog.scripted.com/dev/why-mongo/

======
Zak
I had Mongo lose data.

The box it was hosted on was shut down (possibly uncleanly), and when it came
back up, mongod refused to start. I ran mongod --repair and ended up with a
running system, but the data was mangled. There were parts of records inside
other records and a large amount of data that I just couldn't find.
Fortunately, most of it was backed up elsewhere.

I've been told that maybe some other version is more reliable. I've been told
I need to configure it properly by hand before I use it. I don't care. This
was a trivial single-machine installation and there is _one_ thing any sane
database absolutely _must_ do: avoid completely losing all the data that has
been stored in it.

~~~
dmytton
What version was this? 2.0 (which has been out almost a year) has journaling
enabled by default which almost always provides complete single server
durability for these situations.

Any database can suffer corruption if you shut down the server uncleanly - it
depends on the state of the filesystem when it comes back up. That's why you
have replication to protect against failure of a single node.

Having run Mongo in production for over 3 years, I've never lost any data
despite numerous failure scenarios (including unclean shutdown).

~~~
Zak
I believe it was 1.8. I know it wasn't a high-reliability configuration, and
it _could_ be that an unclean shutdown was to blame. I do not claim to know
objectively how reliable MongoDB is.

I am, however _very_ hesitant to rely on it for anything now, much as I would
be hesitant to touch a machine that previously gave me a severe electric shock
even though its creator and other users assure me it's safe now.

~~~
JustinJ70s
I can tell you now that it's _extremely_ reliable - we store a lot of data in
our mongodb - several million documents a day. As mentioned, it would be
because journalling wasn't enabled which would mean possible corruption on
non-clean shutdown. That's history.

~~~
Zak
That makes me willing to consider subjecting a test environment to abuse to
see if it loses data so as to consider it for production use, but only if I
had a compelling use case for it.

------
stuffihavemade
I don't understand how writing migrations takes "weeks (if not months)". I can
see "hours (if not days)". But, you still have a schema and migrations, they
just exist in the application layer instead without a clear upgrade path.

~~~
jbkring
I think you're underestimating just how many times I rethought my schema and
refactored my models :)

------
jbkring
Anyone else have a good story about Mongo as a speccing tool (as opposed to a
long term solution)?

~~~
StavrosK
I did need a schemaless store for a project I was prototyping, but then I
didn't see why I had to install MongoDB just to get a simple schemaless store.
So, I wrote Goatfish:

<https://github.com/stochastic-technologies/goatfish/>

~~~
bravura
Wait, you found it too difficult and time-consuming to _install_ software, so
instead you _wrote_ software?

~~~
kennywinker
I think he mains maintaining a mongodb installation, which is not trivial.

Same reason people use SQLite instead of MySQL or Postgres. Don't want to have
to deal with keeping a database server up.

~~~
StavrosK
Exactly. This way, I get my schemaless datastore without leaving the stdlib,
_and_ it doesn't eat my data at unsuspecting times.

