So verwenden Sie Django mit MongoDB, indem Sie nur eine Codezeile hinzufügen.

So verwenden Sie Django mit MongoDB, indem Sie nur eine Codezeile hinzufügen.

Um MongoDB als Backend-Datenbank in Ihrem Django-Projekt zu verwenden, fügen Sie einfach diese eine Zeile in Ihre Datei settings.py ein:

DATABASES = { ‘default’: { ‘ENGINE’: ‘djongo’, ‘NAME’: ‘your-db-name’, }}

So einfach ist das!

Melden Sie sich als Nächstes bei Ihrem Administrator zu Hause an (localhost: 8000 / admin /) und fügen Sie über die Admin-GUI „eingebettete Dokumente“ zu MongoDB hinzu:

Im Oktober 2017 beendete MongoDB den letzten Schritt des Börsengangs mit einem Preis von 24 US-Dollar und 192 Millionen US-Dollar. Die Finanzen des Unternehmens sind stetig gewachsen:

MongoDB bietet Open-Source-Datenbanksoftware. Dies ist sehr hilfreich für Startups im Frühstadium, die einen Start anstreben, während sie durch knappe Budgets eingeschränkt sind. Eine Überprüfung der Google-Suchtrends für MongoDB ergab einen stetigen Anstieg des Interesses.

MongoDB hat sich zunehmend zu einer beliebten Datenbanksoftware entwickelt. Datenbanken und Datenbankverwaltungssysteme (DBMS) existieren seit mehr als fünf Jahrzehnten. Sie entstanden in den frühen 1960er Jahren, und die beliebteste Variante war das relationale Datenbanksystem.

Aber MongoDB nennt sich selbst ein "nicht relationales" Datenbanksystem und hat hohe Ansprüche an seinen Ansatz zum Speichern von Daten gestellt. Also, was genau ist der große Deal hier?

MongoDB gegen SQL

Nahezu alle relationalen Datenbanksysteme verwenden SQL (Structured Query Language) (oder eine optimierte Version davon), um mit der Datenverwaltungssoftware zu kommunizieren. Mehrere Universitätskurse widmen sich ausschließlich dem Verständnis und der Beherrschung der SQL-Syntax.

SQL war die De-facto-Sprache für die Arbeit mit jeder Datenbanksoftware (DB), proprietär oder Open Source. Dann kam MongoDB und beschloss, diese alte Sprache der Macht völlig zu missachten und führte eine eigene Abfragesyntax ein.

Die Sprache ist die von Mordor, die ich hier nicht aussprechen werde. In der gemeinsamen Sprache heißt es: „Ein Ring, um sie alle zu regieren. Ein Ring, um sie zu finden. Ein Ring, um sie alle zu bringen und sie in der Dunkelheit zu binden. “- Gandalf ( vom Herrn der Ringe )

MongoDB-Schema gegen SQL-Schema: In einer SQL-Datenbank können keine Daten hinzugefügt werden, bis Sie Tabellen und Feldtypen in einem sogenannten Schema definieren. In einer MongoDB-Datenbank können Daten jederzeit und überall hinzugefügt werden. Es ist nicht erforderlich, ein Dokumentdesign oder eine Sammlung im Voraus anzugeben.

MongoDB-Dokumente im Vergleich zu SQL-Tabellen: SQL-Datenbanken bieten einen Speicher für verwandte Datentabellen. Jede Zeile ist ein anderer Datensatz. Das Design ist starr: Sie können nicht dieselbe Tabelle verwenden, um unterschiedliche Informationen zu speichern oder eine Zeichenfolge einzufügen, in der eine Zahl erwartet wird.

Die MongoDB-Datenbank speichert JSON-ähnliche Feld-Wert-Paar-Dokumente. Ähnliche Dokumente können in einer Sammlung gespeichert werden, die einer SQL-Tabelle entspricht. Sie können jedoch beliebige Daten in jedem Dokument speichern - MongoDB wird sich nicht beschweren. SQL-Tabellen erstellen eine strenge Datenvorlage, sodass es schwierig ist, Fehler zu machen. MongoDB ist flexibler und fehlerverzeihender, aber die Möglichkeit, Daten überall zu speichern, kann zu Konsistenzproblemen führen.

Es gibt eine Vielzahl von Online-Inhalten, die darauf hinweisen, dass MongoDB keine Obermenge von SQL ist. Anwendungen, die unter SQL ausgeführt werden, können nicht auf MongoDB portiert werden. Ich gehe hier auf die Nerven, um zu behaupten, dass MongoDB im Kontext von Django eine Obermenge von SQL ist .

Warum gibt es also zunächst die weit verbreitete Überzeugung, dass MongoDB keine Obermenge von SQL ist?

MongoDB erfordert Denormalisierung von Daten: In MongoDb gibt es keine JOIN-Unterstützung. Dies bedeutet, dass wir unsere Dokumente denormalisieren müssen. Denormalisierte Dokumente führen zu schnelleren Abfragen, die Aktualisierung der Dokumentfeldinformationen in mehreren denormalisierten Dokumenten ist jedoch erheblich langsamer.

Es gibt keine JOINs : SQL-Abfragen bieten eine leistungsstarke JOIN-Klausel. Wir können verwandte Daten in mehreren Tabellen mit einer einzigen SQL-Anweisung erhalten. In nicht relationalen Datenbanken wie MongoDB gibt es keine JOINs wie in relationalen Datenbanken. Dies bedeutet, dass Sie mehrere Abfragen durchführen und die Daten manuell in Ihrem Code verknüpfen müssen.

Keine Transaktionen: In SQL-Datenbanken können zwei oder mehr Aktualisierungen in einer Transaktion ausgeführt werden - ein Alles-oder-Nichts-Wrapper, der Erfolg oder Misserfolg garantiert. Wenn wir zwei Aktualisierungen einzeln ausführen, kann eine erfolgreich sein und die andere fehlschlagen - wodurch unsere Zahlen nicht mehr synchron sind. Durch das Platzieren derselben Aktualisierungen in einer Transaktion wird sichergestellt, dass beide erfolgreich sind oder beide fehlschlagen.

Keine Fremdschlüsseleinschränkungen: In den meisten SQL-Datenbanken können Sie Datenintegritätsregeln mithilfe von Fremdschlüsseleinschränkungen durchsetzen. Dadurch wird sichergestellt, dass alle Zeilen einen gültigen Fremdschlüssel für Code haben, der mit einem Eintrag in der Verknüpfungstabelle übereinstimmt, und dass ein Datensatz aus der Verknüpfungstabelle nicht entfernt wird, wenn eine oder mehrere Zeilen noch auf sie verweisen.

Das Schema erzwingt diese Regeln, damit die Datenbank folgt. Entwickler oder Benutzer können keine Datensätze hinzufügen, bearbeiten oder entfernen, was zu ungültigen Daten oder verwaisten Datensätzen führen kann. Dieselben Datenintegritätsoptionen sind in MongoDB nicht verfügbar. Sie können speichern, was Sie möchten, unabhängig von anderen Dokumenten. Im Idealfall ist ein einzelnes Dokument die einzige Quelle für alle Informationen zu einem Artikel.

Die Notwendigkeit eines Datenbankmodells

Objekte sind Pythons Abstraktion für Daten. Alle Daten in einem Python-Programm werden durch Objekte oder durch Beziehungen zwischen Objekten dargestellt. Während Objekte eine gute Möglichkeit sind, Daten darzustellen, tritt ein Problem auf, wenn wir die Daten persistent machen möchten . Die Datenmenge kann sehr groß sein und muss schnell und effizient aus dem persistenten Speicher abgerufen werden. Diese Datenbanksoftware muss zum Speichern der Objekte verwendet werden. Eine mögliche Datenbanksoftware ist eine relationale, SQL-basierte Datenbanksoftware.

Ein Object-Relational Mapper (ORM) ist eine Codebibliothek, die die Übertragung von Daten, die in relationalen Datenbanktabellen gespeichert sind, in Python-Objekte automatisiert, die in Python-Code verwendet werden. ORMs bieten eine allgemeine Abstraktion für eine relationale Datenbank, mit der ein Entwickler Python-Code anstelle der SQL-Syntax schreiben kann, um Daten und Schemas in seiner Datenbank zu erstellen, zu lesen, zu aktualisieren und zu löschen. Entwickler können die Programmiersprache Python verwenden, mit der sie vertraut sind, anstatt SQL-Anweisungen oder gespeicherte Prozeduren zu schreiben.

Ein Beispiel für ein ORM-Framework für Python ist SQLAlchemy. Das SQLAlchemy ORM bietet eine Methode zum Zuordnen benutzerdefinierter Python-Klassen zu Datenbanktabellen und Instanzen dieser Klassen (Objekte) mit Zeilen in den entsprechenden Tabellen. Es enthält ein System, das alle Statusänderungen zwischen Objekten und den zugehörigen Zeilen transparent synchronisiert. Web-Frameworks wie flask verwenden SQLAlchemy, um Daten dauerhaft zu speichern.

Django ORM: Django wird mit einem eigenen ORM oder Modell geliefert.Das Modell ist die einzige endgültige Informationsquelle für Ihre Daten. Es enthält die wesentlichen Felder und Verhaltensweisen der von Ihnen gespeicherten Daten. Im Allgemeinen wird jedes Modell einer einzelnen Datenbanktabelle zugeordnet. Das Django-Modell ermöglicht auch den Wechsel zwischen verschiedenen relationalen Datenbanken wie Oracle SQL, MySQL oder MSSQL.

Using Django ORM to add documents into MongoDB

Let’s say you want to create a blogging platform using Django with MongoDB as your backend.

In your Blog app/models.py file define the BlogContent model:

from djongo import modelsfrom djongo.models import forms
class BlogContent(models.Model): comment = models.CharField(max_length=100) author = models.CharField(max_length=100) class Meta: abstract = True

To access the model using Django Admin, you will need a Form definition for the above model. Define it as shown below:

class BlogContentForm(forms.ModelForm): class Meta: model = BlogContent fields = ( 'comment', 'author' )

Now “embed” your BlogContent inside a BlogPost using the EmbeddedModelField as below:

class BlogPost(models.Model): h1 = models.CharField(max_length=100) content = models.EmbeddedModelField( model_container=BlogContent, model_form=BlogContentForm ) 

That’s it you are set! Fire up Django Admin on localhost:8000/admin/ and this is what you get:

Next, assume you want to “extend” the author field to contain more than just the name. You need both a name and email. Simply make the author field an “embedded” field instead of a “char” field:

class Author(models.Model): name = models.CharField(max_length=100) email = models.CharField(max_length=100) class Meta: abstract = Trueclass AuthorForm(forms.ModelForm): class Meta: model = Author fields = ( 'name', 'email' )
class BlogContent(models.Model): comment = models.CharField(max_length=100) author = models.EmbeddedModelField( model_container=Author, model_form=AuthorForm ) class Meta: abstract = True

If a blog post has multiple content from multiple authors, define a new model:

class MultipleBlogPosts(models.Model): h1 = models.CharField(max_length=100) content = models.ArrayModelField( model_container=BlogContent, model_form=BlogContentForm )

Fire up Django Admin with the new changes and you have:

Ways to integrate Django and MongoDB.

The Django ORM consists of multiple Abstraction Layers stacked on top of each other.

As a web developer, you can take up the challenge of connecting Django to MongoDB in two ways. Take a look at the Django framework stack above to guess the possible entry points.

Use a MongoDB compatible model

You can completely avoid using the “batteries included” Django models in your project. Instead, use a third party framework like MongoEngine or Ming in you Django projects.

Choosing a different Model means you miss out on:

  • 1500+ core contributors to the project
  • Hourly fixes and ticket resolution

You’d ramp down on the expertise of existing Django models and ramp up on the new model framework. But perhaps the biggest drawback is that your project can’t use any of Django’s contrib models! Forget about using Admin, Sessions, Users, Auth, and other contrib modules for your project.

Some of these disadvantages are offset by forking a new branch of Django itself. Django-nonrel is an independent branch of Django that adds NoSQL database support to Django. Django-nonrel allows for writing portable Django apps. However, the admin interface does not work fully. There is no active development taking place on the Django-nonrel project.

Django MongoDB Engine is another MongoDB backend for Django which is a fork off the MongoEngine ODM.

Django SQL to MongoDB transpiler — Djongo

Another approach is to translate Django SQL query syntax generated by the Django ORM into pymongo commands. Djongo is one such SQL to MongoDB query compiler. It translates every SQL query string into a mongoDB query document. As a result, all Django models and related modules work as is. With this approach, you gain on:

  • Reuse of Django Models: Django is a stable framework with continuous development and enhancements. The Django ORM is quite extensive and feature-rich. Defining a third party ORM to work with MongoDB means reproducing the entire Django ORM again. The new ORM needs to constantly align with the Django ORM. Several Django features will never make it into the third party ORM. The idea with Djongo is to reuse existing Django ORM features by finally translating SQL queries to MongoDB syntax.
  • SQL syntax will never change regardless of future additions to Django. By using Djongo, your project is now future proof!

Making Django work with MongoDB

Emulating Schema in MongoDB: While there is no schema support in MongoDB, this can be emulated. Djongo provides the schema support required in Django by using and defining a combination of MongoDB validator rules and by creating a __schema__ collection. The __schema__ collection stores information for supporting features like the SQL AUTOINCREMENT key.

JOIN support in MongoDB: In version 3.2, MongoDB introduced the $lookup operator. It performs a left outer join to a collection in the same database to filter in documents from the “joined” collection for processing. The $lookup stage does an equality match between a field from the input documents with a field from the documents of the “joined” collection.

To each input document, the $lookup stage adds a new array field whose elements are the matching documents from the “joined” collection. The $lookup stage passes these reshaped documents to the next stage.

Djongo uses the $lookup aggregation operator to perform all Django related JOIN queries. This is how it makes admin and other contrib modules work as is.

Transaction support in MongoDB: Despite the power of single-document atomic operations, there are cases that require multi-document transactions. When executing a transaction composed of sequential operations, certain issues arise, wherein if one operation fails, the previous operation within the transaction must “rollback” to the previous state — that is, the “all or nothing.”

For situations that require multi-document transactions, Djongo implements the two-phase commit pattern to provide support for these kinds of multi-document updates. Using two-phase commit ensures that data is consistent and, in case of an error, the state that preceded the transaction is recoverable.

Djongo comes with its own set of compromises, though. So what are the disadvantages of opting to use Djongo for your Django project?

Performance: The Django ORM does the heavy lifting of converting complex object manipulations to standard SQL query strings. If your backend database was SQL-based, you could pass this query string directly to it with almost no post-processing. With Djongo, however, the query string will now have to be converted into a MongoDB query document.

This is going to require some CPU cycles. But if extra CPU cycles are really such a problem, you probably shouldn’t be using Python in the first place.

Conclusion

I took you through several ways of integrating Django with MongoDB. You will find a multitude of online literature describing the MongoEngine and other variants for doing this.

I focused on Djongo which is a new connector that makes this possible in a different way. It is easy to use and makes the process of migrating from a SQL backend to MongoDB very simple, by adding just one line of code.