Как да използвате Django с MongoDB, като добавите само един ред код.

Как да използвате Django с MongoDB, като добавите само един ред код.

За да използвате MongoDB като база данни във вашия проект на Django, просто добавете този ред във вашия файл settings.py:

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

Това е толкова просто!

След това влезте в администраторския си дом (localhost: 8000 / admin /) и започнете да добавяте „вградени документи“ в MongoDB с помощта на администраторския GUI:

През октомври 2017 г. MongoDB завърши последната стъпка в публичното публикуване, като оцени IPO на $ 24 и събра $ 192 млн. Финансите на компанията непрекъснато растат:

MongoDB предоставя софтуер за бази данни с отворен код. Това е много полезно за стартиращи компании на ранен етап, които искат да стартират, но са ограничени от тесните бюджети. Преглед на тенденциите в търсенето с Google за MongoDB разкрива постоянно нарастване на интереса.

MongoDB все повече се превръща в популярен софтуер за бази данни, с който да работите. Базите данни и системите за управление на бази данни (СУБД) съществуват повече от пет десетилетия. Те се появиха в началото на 60-те години на миналия век, а най-популярният вкус беше релационната система от бази данни.

Но MongoDB се нарича, че се нарича „нерелационна“ система от бази данни и прави големи претенции относно подхода си за съхраняване на данни. И така, каква точно е голямата сделка тук?

MongoDB срещу SQL

Почти всички системи за релационни бази данни използват езика на структурираните заявки (SQL) (или неговата доработена версия) за комуникация със софтуера за управление на данни. Няколко университетски курса са посветени единствено на разбирането и овладяването на SQL синтаксиса.

SQL се превърна в де факто език за работа с всякакъв софтуер за бази данни (DB), собствен или с отворен код. Тогава MongoDB дойде и реши да прояви пълно пренебрежение към този древен език на властта и въведе собствен синтаксис на заявките.

Езикът е този на Мордор, който тук няма да произнася. На общия език се казва: „Един пръстен, който да ги управлява всички. Един пръстен, за да ги намери. Един пръстен, за да ги заведе всички и в тъмнината да ги върже. “- Гандалф ( от Властелина на пръстените )

MongoDB Schemaless срещу SQL Schema: В SQL база данни е невъзможно да се добавят данни, докато не дефинирате таблици и типове полета в това, което се нарича схема. В база данни MongoDB данните могат да се добавят навсякъде и по всяко време. Не е необходимо предварително да се посочва дизайн на документ или дори колекция.

MongoDB Документи срещу SQL таблици: SQL базите данни предоставят хранилище на свързани таблици с данни. Всеки ред е различен запис. Дизайнът е твърд: не можете да използвате една и съща таблица, за да съхранявате различна информация или да вмъкнете низ, където се очаква число.

Базата данни MongoDB съхранява JSON-подобни документи на двойка поле-стойност. Подобни документи могат да се съхраняват в колекция, която е аналогична на SQL таблица. Можете обаче да съхранявате всякакви данни, които харесвате, във всеки документ - MongoDB няма да се оплаква. SQL таблиците създават строг шаблон за данни, така че е трудно да се правят грешки. MongoDB е по-гъвкав и опрощаващ, но възможността да съхранявате всякакви данни навсякъде може да доведе до проблеми с последователността.

Налице е множество онлайн съдържание, което твърди, че MongoDB не е надмножество на SQL. Приложенията, които се изпълняват на SQL, не могат да бъдат пренесени в MongoDB. Излизам тук, за да твърдя, че в контекста на Django MongoDB е супермножество на SQL .

И така, защо популярното убеждение, че MongoDB не е надмножество на SQL, съществува отначало?

MongoDB изисква денормализиране на данни: В MongoDb няма поддръжка на JOIN. Това означава, че ще трябва да денормализираме документите си. Денормализираните документи водят до по-бързи заявки, но актуализирането на информацията за полето на документа в множество денормализирани документи ще бъде значително по-бавно.

Няма JOIN : SQL заявките предлагат мощна клауза JOIN. Можем да получим свързани данни в множество таблици, използвайки един SQL оператор. В нерелационни бази данни като MongoDB няма JOIN, както би имало в релационни бази данни. Това означава, че трябва да извършите множество запитвания и да присъедините данните ръчно в кода си.

Без транзакции: В SQL бази данни, две или повече актуализации могат да бъдат изпълнени в транзакция - обвивка „всичко или нищо“, която гарантира успех или неуспех. Ако изпълним две актуализации поотделно, едната може да успее, а другата да се провали - като по този начин нашите цифри не се синхронизират. Поставянето на едни и същи актуализации в рамките на транзакция гарантира или успех, и двете неуспешни.

Няма ограничения за външен ключ: Повечето бази данни на SQL ви позволяват да налагате правила за целостта на данните, като използвате ограничения за външен ключ. Това гарантира, че всички редове имат валиден външен ключ за код, който съвпада с един запис в таблицата за присъединяване, и гарантира, че запис от таблицата за присъединяване не е премахнат, ако един или повече редове все още се отнасят към тях.

Схемата налага тези правила, които базата данни да следва. Невъзможно е за разработчици или потребители да добавят, редактират или премахват записи, което може да доведе до невалидни данни или записи сираци. Същите опции за целостта на данните не са налични в MongoDB. Можете да съхранявате това, което искате, независимо от други документи. В идеалния случай един документ би бил единственият източник на цялата информация за даден артикул.

Необходимостта от модел на база данни

Обектите са абстракцията на Python за данни. Всички данни в програма на Python са представени от обекти или от връзки между обекти. Докато обектите са добър начин за представяне на данни, възниква проблем, когато искаме да направим данните постоянни. Количеството данни може да бъде огромно и трябва да бъде извлечено от постоянната памет бързо и ефективно. Този софтуер за база данни трябва да се използва за съхраняване на обектите. Възможен софтуер за бази данни е релационен, базиран на SQL софтуер за бази данни.

Обектно-релационният картограф (ORM) е библиотека с кодове, която автоматизира прехвърлянето на данни, съхранявани в релационни таблици на база данни, в обекти на Python, които се използват в кода на Python. ORM осигуряват абстракция на високо ниво върху релационна база данни, която позволява на разработчика да пише Python код вместо SQL синтаксис, за да създава, чете, актуализира и изтрива данни и схеми в своята база данни. Разработчиците могат да използват езика за програмиране Python, с който им е удобно, вместо да пишат SQL изрази или съхранени процедури.

Пример за ORM рамка за Python е SQLAlchemy. SQLAlchemy ORM представя метод за свързване на дефинирани от потребителя класове Python с таблици на база данни и екземпляри на тези класове (обекти) с редове в съответните им таблици. Той включва система, която прозрачно синхронизира всички промени в състоянието между обектите и свързаните с тях редове. Уеб рамки като колба използват SQLAlchemy за постоянно съхранение на данни.

Django ORM: Django се предлага със собствен ORM или модел за кратко.Моделът е единственият окончателен източник на информация за вашите данни. Той съдържа основните полета и поведение на данните, които съхранявате. По принцип всеки модел се съпоставя в една таблица на базата данни. Моделът Django също така дава възможност за превключване между различни релационни бази данни като Oracle SQL, MySQL или MSSQL.

Използване на Django ORM за добавяне на документи в MongoDB

Да предположим, че искате да създадете платформа за блогове, използвайки Django с MongoDB като ваш бекенд.

Във вашия app/models.pyфайл в блога дефинирайте BlogContentмодела:

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

За достъп до модела с помощта на Django Admin ще ви е необходима дефиниция на формуляр за горния модел. Определете го, както е показано по-долу:

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

Сега „вградете“ BlogContentвътрешността си, като BlogPostизползвате EmbeddedModelFieldследното:

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

Това сте готови! Задействайте администратора на Django на localhost: 8000 / admin / и ето какво получавате:

След това приемете, че искате да „разширите“ полето на автора, за да съдържа повече от само името. Нуждаете се от име и имейл. Просто направете полето за автор "вградено" поле вместо полето "char":

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

Ако публикация в блог има множество съдържание от множество автори, дефинирайте нов модел:

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

Задействайте администратора на Django с новите промени и имате:

Начини за интегриране на Django и MongoDB.

Django ORM се състои от множество слоеве за абстракция, подредени един върху друг.

Като уеб разработчик можете да приемете предизвикателството да свържете Django с MongoDB по два начина. Разгледайте стека на рамката на Django по-горе, за да познаете възможните входни точки.

Използвайте MongoDB съвместим модел

Можете напълно да избегнете използването на моделите Django с включени батерии във вашия проект. Вместо това използвайте рамка на трета страна като MongoEngine или Ming във вашите Django проекти.

Изборът на различен модел означава, че пропускате:

  • 1500+ основни участници в проекта
  • Поправки на час и разрешаване на билети

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.