MongoDB. Lots of discussions about this at EuroPython today—it’s a document database, very similar to CouchDB but significantly faster and suggested for production use. Best of all, trying it out on OS X is as easy as extracting the tarball and running “bin/mongod --dbpath /tmp/test-mongo-db run”.
Sign in with 
OpenID
How difficult do you think it'd be to get Django's ORM to work with MongoDB?
Erik Vorhes - 30th June 2009 22:59 - #
It should be the same difficulty as getting CouchDB working - and there's a stab at doing that over here.
That said, personally I remain sceptical of projects that attempt to map Django's extremely relational ORM to non-relational backends. Why would you want to do this in the first place? Presumably because you want to use parts of the Django ecosystem - in particular the admin, generic views and pagination - with a different persistent store.
I would argue that you don't want a ORM backend for MongoDB - instead, you want the admin, generic views and pagination to work with alternative storage mechanisms. Instead of depending directly on the ORM, they should make use of an abstract interface which can be mapped to the ORM but can also map to other types of persistent store.
We've been in the RDBMS mindset for decades, it's going to take a long time to transition and I'm not sure it's worth it. Structure has inherit value. I see more value in dual systems which are accessed similarly or via abstraction but shoehorning relational data into a document system or vice versa is counter productive.
Dave K - 1st July 2009 07:05 - #
Too bad, the license make it unusable in enterprise environments. However thanks for the pointer.
g - 1st July 2009 13:51 - #
"significantly faster and suggested for production use"
Sounds like you have some sort of grudge against CouchDB :)
Robert Schultz - 1st July 2009 16:58 - #
No grudge at all - it's just CouchDB make it abundantly clear that they haven't done any optimisation work yet and you should use it at your own risk. The MongoDB team appear to be encouraging people to trust them with their data.
Erik Vorhes - 1st July 2009 22:04 - #
"it's just CouchDB make it abundantly clear that they haven't done any optimisation work yet and you should use it at your own risk."
We haven't done any heavy duty optimisation, but it's an ongoing focus. There is an important difference between making this known, and CouchDB being "significantly" and quantitatively slower than MongoDB.
Do you have any benchmarking results?
The Erlang version of CouchDB is three and a half years old, and is used often used in production. We're still advising people to be careful because until we hit 1.0, CouchDB is considered alpha software.
As far as I can tell, MongoDB is less than six months old and they are claiming it's ready for rock solid production use? Sounds pretty optimistic! Heh.
Noah Slater - 1st July 2009 23:35 - #
@noah: MongoDB has been publicly available for less than six months, but it's been being used in production environments for almost two years now.
Also, MongoDB is significantly and quantitatively faster than CouchDB :) (one example: http://www.snailinaturtleneck.com/blog/?p=74)
Noah: to be completely honest, my impression of MongoDB as compared to CouchDB came from a conversation with a developer behind a large, well-known site who told me they had previously used Couch but were using Mongo on their latest project, for performance reasons based on their own benchmarks.
MongoDB hasn't been around for nearly as long (the first open source release was only in July last year) but the team behind look very impressive - ex DoubleClick engineers and Geir Magnusson from the ASF. I've been very impressed with it during initial experiments on my laptop.
Mike Dirolf - 2nd July 2009 11:33 - #
Kristina: Thanks for the clarification. I think it is misleading for you to claim that MongoDB is unilaterally faster without also specifying the nature of the benchmarking used. While MongoDB might out-perform CouchDB for one specific test, the opposite may be true for another test.
Simon: Hopefully you'll understand my scepticism of any secret benchmarking results, or hearsay. Heh. The main point here is that different databases perform differently in different usage scenarios. Performance is all about trade-offs. Saying that X performs better than Y is meaningless without clarification.
One of our developers has proposed a standard benchmarking suite that we can use as a community to "objectively measure performance for easy comparison."
Noah Slater - 4th July 2009 01:37 - #