

Using MongoDB as your primary Django database - drikerf
http://staltz.com/djangoconfi-mongoengine/

======
csirac2
I was on a project a few years ago (first PoC with Mongo 1.2, started properly
in 1.4, delivered with 1.8). Have the following things improved?

\- RAM usage was a killer. For some datasets, key names took up more memory
than values. \- Throwing custom JS at mongo nodes was kind of fun, and we
could do interesting stuff with it that we couldn't easily do on the previous
(non-sharded) datastore. But out-of-memory situations in the JS runtime was
less than graceful and caused mysterious replica breakage/hangs. Eventually it
was suggested that we were using MongoDB in a way that wasn't typical or
intended, which was fair enough. \- We had trouble using it as a truly
"schemaless" database (scientist users defining, maintaining, collaborating on
their own data with object-level access controls and versioning): when you
sort the result of a query (needed for paging), you either needed indexes
(exploding RAM usage, finite number of indexes possible per collection) or if
you could tolerate slowness (as we could) then you could use .limit() but it
was hard to get the what-should-the-limit-be heuristic right, our object sizes
varied wildly (sometimes exceeding BSON data size limit at times).

In another project we used MongoDB to back a read-only HTTP API representation
of some 10s GiBs of reasonably stable and predictable external data, in that
case it felt we were fighting it a lot less and it worked reasonably well.

I've also messed with eXist, Neo4j (which was fascinating) and a few other
NoSQL things - at the end of the day I have to believe that for large
sprawling heterogeneous systems (i.e. not the lone django web-app use-case)
you will always want to keep authoritative data in something else and treat
the NoSQL thing as a cache that can be rebuilt at any time.

Curating arbitrarily connected business objects in a graph (or having
different codebases with slightly different understanding of the data mess
with a given mongo collection) is infinitely harder than orderly relational
tables, especially for the traditional DBA people who know how to read
business process from a well-designed relational DB and likewise write such a
thing by understanding those processes themselves quite well (something I
didn't give them much credit for until a few jobs ago).

