Django decided long time ago that Ruby on Rails cannot be the only framework where people can have fun integrating with all NoSQL databases. During this year DjangoCon Europe there were several session dedicated to Django and NoSQL databases:

• Alex Gaynor: What NoSQL support in the Django ORM looks like, and how do we get there
• Peter Bengtsson: Using MongoDB in your app
• Benoît Chesneau: Relax your project with CouchDB
• Tobias Ivarsson: Django and Neo4j: Domain Modeling that Kicks Ass
• Django and NoSQL Panel

What NoSQL support in the Django ORM looks like, and how do we get there

Alex Gaynor speaks about what needs to change in Django ORM to make it more NoSQL friendly:

Reinout van Rees has a summary of the talk ☞ here.

Using MongoDB in your app

Peter Bengtsson talks about his experience of passing from using ZODB for the last 10 years to MongoDB

Some notes from the talk are available ☞ here.

Relax your project with CouchDB

Benoît Chesneau talks about what makes CouchDB appealing to python developers. He also covers the CouchDBkit python framework.

Django and Neo4j: Domain Modeling that Kicks Ass

Not coming from DjangoCon, but still about Django and Neo4j, is Tobias Ivarsson’s presentation: “Django and Neo4j - Domain modeling that kicks ass”:

Derek Stainer summarizes the slide deck ☞ here.

Django and NoSQL Panel

A fantastic panel on the future of Django and NoSQL databases that you can watch over ☞ blip.tv. Reinout van Rees published a transcript of the panel ☞ here.

All in all a lot of NoSQL excitement in the Django world! Or should it be the opposite?

Update: Here is the latest Django and NoSQL Databases status update

Django and NoSQL Databases Revisited originally posted on the NoSQL blog: myNoSQL

Even if a bit hidden behind the Rails code, the slides embedded below and these ☞ code snippets are using the RESTful access to Neo4j to build a recommendation engine in a network of StarWars heroes:

Probably obvious, but graph databases are definitely a good tool for building recommendation engines.

After triggering our quick review of graph databases, Pere Urbón came up with a nice comparison of these — Neo4j, HyperGraphDB, DEX, InfoGrid, Sones, VertexDB — in terms of License, Schema, Querying, Storage implementation, Utilities, Language and Operating system support.

Pere has made this very interesting NoSQL graph database matrix available as a ☞ PDF on his blog.

One of the problems mentioned when discussing relational databases scalability is that handling storage enforced relationships, ACID and scale do not play well together. In the NoSQL space there is a category of storage solutions that uses highly interconnected data: graph databases. (note also that some of these graph databases are also transactional).

Lately there have been quite a few interesting discussions related to scaling graph databases. Alex Averbuch is working on a sharding Neo4j thesis and his recent ☞ post presents some of the possible solutions. Alex’s article is a very good starting point for anyone interesting in scaling graph databases.

Then there is also this ☞ article on InfoGrid‘s blog that is presenting a different web-like solution based on a custom protocol: ☞ XPRISO: eXtensible Protocol for the Replication, Integration and Synchronization of distributed Objects. While I haven’t had the chance to dig deeper into InfoGrid suggested approach there was one thing that caught my attention right away: while the association with web-scale is definitely an interesting idea, having specific knowledge of the nodes location and having to use custom API for it doesn’t seem to be the best solution. Basically the web addressed this by having URIs for each reachable resource (InfoGrid should try a similar idea, get rid of the different API for accessing local vs remote nodes, etc.)

Update: make sure you check the comment thread for more details about InfoGrid perspective on scaling graph databases.

Oren Eini concludes in ☞ his post:

After spending some time thinking about it, I came to the conclusion that I can’t envision any general way to solve the problem. Oh, I can think of several ways of reduce the problem:

• Batching cross machine queries so we only perform them at the close of each breadth first step.
• Storing multiple levels of associations (So “users/ayende” would store its relations but also “users/ayende”’s relation and “users/arik”’s relations).

While I haven’t had enough time to think about this topic, my gut feeling is that possible solutions are to be found in the space of a combination of using unique identifiers for distributed nodes and a mapreduce-like approach. I cannot stop wondering if this is not what Google’s ☞ Pregel is doing (nb I should have read the ☞ paper (pdf) firstly).