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?

Sign up to vote on this title
UsefulNot useful