Django and mongodb - Daniel Greenfeld and Audrey Roy

Tags: django, djangocon

(They gave the talk with the two of them, a format that works really well. The nicest talk last year was also done by two people. Nicely executed.)

Mongodb is the big kid on the block in the NoSQL world. Schemaless. It stores data in BSON (a bit like JSON). Javascript is used internally for scripting. And it’s got a load of bindings for all languages.

Documents in mongo-speak are like SQL rows, collections are like tables. When you look at it very minimalistically, a document is like a python dict, a collection like a list.

There are a couple of python bindings for mongodb, in rising order of complexity and functionality. Most of them are useable outside of Django.

  • pymongo is the official binding. Querying looks like for review in db.reviews.find({'rating': 3}).

    The good thing is that it is really fast. You can go completely crazy with the schemalessness of mongodb.

    The bad things? The introspection is hard. Very low-level. It takes schemalessness to the max, so you lose most django form/model goodness, logically.

  • mongoengine pretty much looks a bit like django models and django queries. Cleaner than pymongo.

    It looks like django, so you can get up to speed quickly. You can use it with django-mongonaut for introspection (it is pretty new, but it gives you something like the django admin for mongo). There’s a little bit of schema support, but it isn’t enforced by the database.

    If you want to go schema-crazy, mongoengine will restrict you too much. And if you use it with Django you won’t get your usual great django admin interface.

  • mongokit is pretty fast to learn, but not as easy as mongoengine. The queries are identical to pymongo.

    You can go all-out schemaless. But you also can use a light schema. Speed is good. Types are partially python, which is nice.

    Bad: no introspection. And again no django models/forms integration.

  • django-nonrel is a patch/fork of Django that adds NoSQL support. So watch out. Forks are dangerous.

    The big plus is that you can use django as you normally would. It mirrors the ORM functionality.

    Bad: it is a fork of the whole Django project. They’re still at django 1.3. Multi-db usage is confusing.

The official talk title mentioned “square pegs and round holes”. Django and mongodb don’t fit completely. Mongodb isn’t a first-class citizen like mysql and postgres.

Some separate thoughts:

  • But… what about a single third-party app that lets you combine critical django apps and mongodb? A simple bridge? Could that work?

  • And… why add schemas to a schema-less database? If you have a schema, why not get yourself a fast postgres plus a cache? Works fast.

  • And… an introspection tool. Why not treat introspection like a query?

  • A schemaless db promisses speed. The trade-of is ACID compliance, especially for distributed systems. (In response to a question, they said the risk of actually losing data seems very low to them).

  • A schemaless database is probably an ACID non-compliant database. OK when performance is more important than being consistent 100% of the time.

There are still big hurdles for using mongodb with django. ORM, admin, modelforms, auth. But the situation is improving rapidly. Introspection tools are important. Will there be a drop-in django auth replacement in django 1.5?

They plugged django-mongonaut again at the end. They’ve got lots of ideas for that.

During the questions Andreas Jung’s recent goodbye mongodb article was mentioned. Worth a read!

Photo & Video Sharing by SmugMug
 
vanrees.org logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):