Django MongoDB Backend

Using Django and Non-relational for Web Development

Flavio Percoco Premoli

flaper87@flaper87.org

Research & Development, The Net Planet Europe

October 04th, 2010

Django MongoDB Backend
Introduction
Disclaimer

Before starting with mongodb specific topics it’s important to know that we don’t
dislike relational databases, we know they are good for many things but we also know
that web applications success is mainly based on their performance and speed so
that’s what we’re running after and that’s why we’re all here.
Django MongoDB Backend
Existing Technologies

MongoKit (Nicolas Clairon)

mongoengine (Harry Marr)
django-mongodb-engine (Flavio Percoco Premoli and Alberto Paro)
Django MongoDB Backend
Existing Technologies

MongoKit (Nicolas Clairon)

mongoengine (Harry Marr)
django-mongodb-engine (Flavio Percoco Premoli and Alberto Paro)
Django MongoDB Backend
Existing Technologies

MongoKit (Nicolas Clairon)

mongoengine (Harry Marr)
django-mongodb-engine (Flavio Percoco Premoli and Alberto Paro)
Django MongoDB Backend
Moving Forward
SQL to MongoDB Query Translation. . .

”What matters is who adapts faster to the changing conditions” - Charles Darwin
Joins: The best thing you can do here is forget about JOINS
ForeignKeys: We have DBRef but, do we really need them?
M2M?: What about dicionaries/maps and lists/arrays?
And last but not least, If you really need to do a query that joins 2 collections
based on a field reference that should handle a many to many relation then you
have map/reduce.
Django MongoDB Backend
Moving Forward
SQL to MongoDB Query Translation. . .

”What matters is who adapts faster to the changing conditions” - Charles Darwin
Joins: The best thing you can do here is forget about JOINS
ForeignKeys: We have DBRef but, do we really need them?
M2M?: What about dicionaries/maps and lists/arrays?
And last but not least, If you really need to do a query that joins 2 collections
based on a field reference that should handle a many to many relation then you
have map/reduce.
Django MongoDB Backend
Moving Forward
SQL to MongoDB Query Translation. . .

”What matters is who adapts faster to the changing conditions” - Charles Darwin
Joins: The best thing you can do here is forget about JOINS
ForeignKeys: We have DBRef but, do we really need them?
M2M?: What about dicionaries/maps and lists/arrays?
And last but not least, If you really need to do a query that joins 2 collections
based on a field reference that should handle a many to many relation then you
have map/reduce.
Django MongoDB Backend
Moving Forward
SQL to MongoDB Query Translation. . .

”What matters is who adapts faster to the changing conditions” - Charles Darwin
Joins: The best thing you can do here is forget about JOINS
ForeignKeys: We have DBRef but, do we really need them?
M2M?: What about dicionaries/maps and lists/arrays?
And last but not least, If you really need to do a query that joins 2 collections
based on a field reference that should handle a many to many relation then you
have map/reduce.
Django MongoDB Backend
Moving Forward
Keeping things lazy

Yes, because we’re lazy people so we do lazy things. . .

It is important when getting orms to work with mongodb that we keep things lazy to
avoid bottle necks in our web applications. Mongodb doesn’t have many to many
relations but it has lists and dictionaries. For example
class User(models.Model):
nickname = models.CharField(max length=255)
full name = models.CharField(max length=255)
friends = ListField()
groups = ListField()
Django MongoDB Backend
Moving Forward
Keeping things lazy

Yes, because we’re lazy people so we do lazy things. . .

It is important when getting orms to work with mongodb that we keep things lazy to
avoid bottle necks in our web applications. Mongodb doesn’t have many to many
relations but it has lists and dictionaries. For example
class User(models.Model):
nickname = models.CharField(max length=255)
full name = models.CharField(max length=255)
friends = ListField()
groups = ListField()
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

This is a common question when moving from relational databases to non-rel ones.
Should we keep our models related or embed smallest ones into the biggest ones?. The
answer is NO, you shouldn’t keep them related. For Example, A common situation (or
commonly used to show how mongodb works) is a blog engine with posts and
comments. Lets see how we could handle comments (not threaded) in our blog engine:
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

Using References

class Comment(models.Model):
post = models.ForeignKey(Post)
user = models.ForeignKey(User)
text = models.CharField(max_length=255)

kwargs = { ’post’ : my post,

’user’ : my user,
’text’ : my text,
’defaults’ : {}}

my comment = Comment.objects.get_or_create(**kwargs)[0]
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

Without References

class Post(models.Model):
...
comments = ListField()

post.comments.append({ ’user’ : user,

’text’ : text }
post.save()

Embedded? Not a good idea.

ForeignKey? If we’re using RDBMs.
Dictionary? Good idea but slow.
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

Without References

class Post(models.Model):
...
comments = ListField()

post.comments.append({ ’user’ : user,

’text’ : text }
post.save()

Embedded? Not a good idea.

ForeignKey? If we’re using RDBMs.
Dictionary? Good idea but slow.
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

Without References

class Post(models.Model):
...
comments = ListField()

post.comments.append({ ’user’ : user,

’text’ : text }
post.save()

Embedded? Not a good idea.

ForeignKey? If we’re using RDBMs.
Dictionary? Good idea but slow.
Django MongoDB Backend
Moving Forward
Keeping Relations or Embedding?

Without References

class Post(models.Model):
...
comments = ListField()

post.comments.append({ ’user’ : user,

’text’ : text }
post.save()

Embedded? Not a good idea.

ForeignKey? If we’re using RDBMs.
Dictionary? Good idea but slow.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Schema-less databases do have a structure

Dynamic
Not typed
Most of then are json-like maps.
Great for web development
No Migrations needed.
No IntegrityErrors.
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Let’s improve our Comment model (in case we decided to have some relations).
class Comment(models.Model):
post = models.ForeignKey(Post)
user = GenericField()
text = models.CharField(max_length=255)

my user = "FlaPer87" #Known User

my user = { ’username’ : ’FlaPer87’,
’email’ : ’flaper87@flaper87.org’,
’url’ :’http://blog.flaper87.org/’}#Anonymous

kwargs = { ’post’ : my post,

’user’ : my user,
’text’ : my text,
’defaults’ : {}}

my comment = Comment.objects.get_or_create(**kwargs)[0]
Django MongoDB Backend
Moving Forward
Taking Advantage from schema-less

Let’s improve our Comment model (in case we decided to have some relations).
class Comment(models.Model):
post = models.ForeignKey(Post)
user = GenericField()
text = models.CharField(max_length=255)

my user = "FlaPer87" #Known User

my user = { ’username’ : ’FlaPer87’,
’email’ : ’flaper87@flaper87.org’,
’url’ :’http://blog.flaper87.org/’}#Anonymous

kwargs = { ’post’ : my post,

’user’ : my user,
’text’ : my text,
’defaults’ : {}}

my comment = Comment.objects.get_or_create(**kwargs)[0]
Django MongoDB Backend
Summary
What we’ve learned. . .

Re-model your models

Be Lazy to be faster
Forget about relations, they will slow you down
Remember that dynamism is better than restrictions
Django MongoDB Backend
Summary
What we’ve learned. . .

Re-model your models

Be Lazy to be faster
Forget about relations, they will slow you down
Remember that dynamism is better than restrictions
Django MongoDB Backend
Summary
What we’ve learned. . .

Re-model your models

Be Lazy to be faster
Forget about relations, they will slow you down
Remember that dynamism is better than restrictions
Django MongoDB Backend
Summary
What we’ve learned. . .

Re-model your models

Be Lazy to be faster
Forget about relations, they will slow you down
Remember that dynamism is better than restrictions
Django MongoDB Backend
The End
A little bit about me

Full Name: Flavio Percoco Premoli

IRC: FlaPer87 at irc.freenode.net
Twitter: FlaPer87
blog: http://www.flaper87.org
e-mail: flaper87@flaper87.org
Anywhere else: FlaPer87
Short Background:
GNOME a11y and Open a11y Contributor (MouseTrap
[http://live.gnome.org/MouseTrap]).
Open Source Developer/Contributor (Web and Desktop).
MongoDB Community Member and Contributor.
R&D Developer at The Net Planet Europe.
Knowledge Management Systems
Search Engines
Indexing Engines
Cloud Computing
NoSQL Technologies
Linux Lover/User and Mac user too
Django MongoDB Backend
The End
Interaction

Thanks!

Questions?