Як використовувати Django з MongoDB, додавши лише один рядок коду.

Як використовувати Django з MongoDB, додавши лише один рядок коду.

Щоб використовувати MongoDB як базову базу даних у своєму проекті Django, просто додайте цей один рядок у файл settings.py:

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

Це так просто!

Далі увійдіть у свій адміністратор (localhost: 8000 / admin /) і почніть додавати “вбудовані документи” в MongoDB за допомогою графічного інтерфейсу адміністратора:

У жовтні 2017 року MongoDB завершив останній крок до виходу на біржу, оцінивши IPO в розмірі 24 долари та залучивши 192 млн доларів. Фінанси компанії постійно зростали:

MongoDB пропонує програмне забезпечення для баз даних із відкритим кодом. Це дуже корисно для стартапів на ранніх стадіях, які прагнуть до запуску, проте обмежені обмеженим бюджетом. Огляд тенденцій пошуку Google для MongoDB виявив постійне зростання інтересу.

MongoDB все частіше стає популярним програмним забезпеченням для роботи з базами даних. Бази даних та системи управління базами даних (СУБД) існують більше п'яти десятиліть. Вони з’явилися на початку 1960-х, і найпопулярнішим смаком була система реляційних баз даних.

Але MongoDB називає себе "нереляційною" системою баз даних і висловлює великі претензії щодо свого підходу до зберігання даних. Отже, в чому саме полягає ВЕЛИКА угода тут?

MongoDB проти SQL

Практично всі системи реляційних баз даних використовують Структуровану мову запитів (SQL) (або її налаштовану версію) для зв'язку з програмним забезпеченням для управління даними. Кілька університетських курсів присвячені виключно розумінню та засвоєнню синтаксису SQL.

SQL став фактичною мовою для роботи з будь-яким програмним забезпеченням баз даних (БД), власним або відкритим кодом. Потім прийшов 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, немає об'єднань, як у реляційних базах даних. Це означає, що вам потрібно виконати кілька запитів та об’єднати дані вручну в коді.

Відсутність транзакцій: у базах даних SQL у транзакції можуть бути виконані два або більше оновлення - обгортка "все або нічого", що гарантує успіх або невдачу. Якщо ми виконаємо два оновлення окремо, одне може досягти успіху, а друге - не вдавшись - таким чином, наші цифри будуть не синхронізованими. Розміщення одних і тих самих оновлень у транзакції забезпечує або те, і інше, або успіх обох.

Відсутність обмежень зовнішнього ключа: Більшість баз даних SQL дозволяють застосовувати правила цілісності даних, використовуючи обмеження зовнішнього ключа. Це гарантує, що всі рядки мають дійсний зовнішній ключ для коду, який відповідає одному запису в таблиці об’єднання, і гарантує, що запис із таблиці об’єднання не буде видалено, якщо один або кілька рядків все ще посилаються на них.

Схема застосовує ці правила для дотримання базою даних. Розробники та користувачі не можуть додавати, редагувати чи видаляти записи, що може призвести до недійсних даних або записів-сиріт. Ті самі параметри цілісності даних недоступні в MongoDB. Ви можете зберігати те, що хочете, незалежно від будь-яких інших документів. В ідеалі, єдиний документ був би єдиним джерелом усієї інформації про предмет.

Потреба в моделі бази даних

Об'єкти - це абстракція Python для даних. Усі дані програми Python представлені об'єктами або відносинами між об'єктами. Хоча об’єкти є хорошим способом представлення даних, проблема виникає, коли ми хочемо зробити дані стійкими. Обсяг даних може бути величезним, і їх потрібно швидко та ефективно отримувати з постійної пам'яті. Це програмне забезпечення бази даних повинно використовуватися для зберігання об'єктів. Можливе програмне забезпечення для баз даних - це реляційне програмне забезпечення для баз даних на базі SQL.

Об’єктно-реляційний картограф (ORM) - це бібліотека коду, яка автоматизує передачу даних, що зберігаються в таблицях реляційних баз даних, у об’єкти Python, які використовуються в коді Python. ORM забезпечують абстракцію високого рівня на реляційній базі даних, що дозволяє розробнику писати код Python замість синтаксису SQL для створення, читання, оновлення та видалення даних та схем у своїй базі даних. Розробники можуть використовувати мову програмування Python, якою їм комфортно, замість того, щоб писати оператори SQL або збережені процедури.

Прикладом структури ORM для Python є SQLAlchemy. SQLAlchemy ORM представляє метод асоціювання визначених користувачем класів Python з таблицями баз даних та екземплярів цих класів (об'єктів) з рядками у відповідних таблицях. Він включає систему, яка прозоро синхронізує всі зміни стану між об'єктами та пов'язаними з ними рядками. Веб-фреймворки, такі як flask, використовують 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, вам знадобиться визначення форми для наведеної моделі. Визначте його, як показано нижче:

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 новими змінами, і у вас є:

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.