Kuidas kasutada Djangot koos MongoDB-ga, lisades ainult ühe koodirea.

Kuidas kasutada Djangot koos MongoDB-ga, lisades ainult ühe koodirea.

MongoDB kasutamiseks Django projektis oma taustaprogrammi andmebaasina lisage oma seadete.py faili see üks rida :

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

Nii lihtne see ongi!

Järgmisena logige sisse oma administraatori koju (localhost: 8000 / admin /) ja alustage administraatori graafilise kasutajaliidese abil MongoDB-sse manustatud dokumentide lisamist:

2017. aasta oktoobris lõpetas MongoDB börsile mineku viimase sammu, hinnates oma IPO-d 24 dollarile ja kogudes 192 miljonit dollarit. Ettevõtte rahandus on pidevalt kasvanud:

MongoDB pakub avatud lähtekoodiga andmebaasitarkvara. See on väga kasulik varajases staadiumis alustavatele alustavatele ettevõtetele, kes soovivad käivitada, olles samal ajal piiratud eelarvega piiratud. MongoDB Google'i otsingutrendide ülevaatamine näitas huvi pidevat kasvu.

MongoDB on muutunud üha populaarsemaks andmebaasitarkvaraks, millega töötada. Andmebaasid ja andmebaaside haldussüsteemid (DBMS) on eksisteerinud enam kui viis aastakümmet. Need ilmusid 1960. aastate alguses ja kõige populaarsem maitse oli relatsioonide andmebaasisüsteem.

Kuid MongoDB nimetab ennast "mittesuhteliseks" andmebaasisüsteemiks ja on esitanud suuri väiteid andmete säilitamise lähenemisviisi kohta. Mis täpselt on siin SUUR tehing?

MongoDB vs SQL

Peaaegu kõik relatsioonilised andmebaasisüsteemid kasutavad andmehaldustarkvaraga suhtlemiseks struktureeritud päringukeelt (SQL) (või selle muudetud versiooni). Mitmed ülikoolikursused on pühendatud ainult SQL-i süntaksist arusaamisele ja valdamisele.

SQL-ist on saanud de-facto keel mis tahes andmebaasi (DB) tarkvara, varalise või avatud lähtekoodiga töötamiseks. Siis tuli kaasa MongoDB, kes otsustas seda iidset võimukeelt täielikult ignoreerida, ja tutvustas oma päringusüntaksit.

Keel on Mordori keel, mida ma siin ei ütle. Ühiskeeles öeldakse: „Üks rõngas nende kõigi valitsemiseks. Nende leidmiseks üks sõrmus. Üks tsükkel tuua kõiki neid ja pimeduses nendevaheliste. "- Gandalf ( alates Herrasta tsüklid )

MongoDB Schemaless vs SQL Schema: SQL-i andmebaasis pole andmeid võimalik lisada enne, kui olete skeemina määratletud tabelid ja väljatüübid. MongoDB andmebaasis saab andmeid lisada ükskõik kuhu ja igal ajal. Dokumendi kujundust ega isegi kogu pole vaja eelnevalt täpsustada.

MongoDB-dokumendid vs SQL-tabelid: SQL-i andmebaasid pakuvad seotud andmetabelite salvestust. Iga rida on erinev rekord. Kujundus on jäik: te ei saa kasutada sama tabelit erineva teabe salvestamiseks ega stringi sisestamiseks sinna, kus eeldatav arv on.

MongoDB andmebaas salvestab JSON-laadseid väliväärtuste paaridokumente. Sarnaseid dokumente saab salvestada kogumisse, mis on analoogne SQL-tabeliga. Kuid võite salvestada mis tahes andmed, mis teile meeldivad, igasse dokumenti - MongoDB ei kaebagi. SQL-tabelid loovad range andmemalli, nii et vigu on raske teha. MongoDB on paindlikum ja andestavam, kuid andmete salvestamine kuhugi võib põhjustada järjepidevuse probleeme.

Saadaval on palju veebisisusid, mis väidavad, et MongoDB ei ole SQL-i ülihulk. SQL-is töötavaid rakendusi ei saa MongoDB-sse portida. Ma lähen siin välja, väites, et Django kontekstis on MongoDB SQL-i ülihulk .

Miks on siis alustuseks levinud arvamus, et MongoDB ei ole SQL-i ülihulk?

MongoDB nõuab andmete denormaliseerimist : MongoDb-s puudub JOIN-tugi. See tähendab, et peame oma dokumendid denormaliseerima. Denormaliseeritud dokumendid põhjustavad kiiremaid päringuid, kuid dokumendivälja teabe värskendamine mitmes denormaliseeritud dokumendis on oluliselt aeglasem.

JOIN-e pole : SQL-päringud pakuvad võimsat JOIN-klauslit. Saame seotud andmeid saada mitmes tabelis, kasutades ühte SQL-i lauset. Mitte-relatsioonilistes andmebaasides nagu MongoDB pole JOIN-e, nagu oleks relatsioonilistes andmebaasides. See tähendab, et peate tegema mitu päringut ja ühendama andmed oma koodis käsitsi.

Tehinguid pole: SQL-i andmebaasides saab tehingus käivitada kaks või enam värskendust - kõik või mitte miski ümbris, mis tagab edu või ebaõnnestumise. Kui teostame kaks värskendust eraldi, võib üks õnnestuda ja teine ​​ebaõnnestuda - jättes meie arvud sünkroonist välja. Tehingu sees samade värskenduste paigutamine tagab, et mõlemad õnnestuvad või mõlemad ebaõnnestuvad.

Välisvõtme piiranguid pole: enamik SQL-i andmebaasidest võimaldab teil andmete terviklikkuse reegleid jõustada välisvõtme piirangute abil. See tagab, et kõigil ridadel on kehtiv välisvõti koodi jaoks, mis ühtib ühinemistabeli ühe kirjega, ja tagab, et liitumistabeli kirjet ei eemaldata, kui üks või mitu rida neile ikkagi viitavad.

Skeem jõustab need reeglid andmebaasi järgimiseks. Arendajatel või kasutajatel on võimatu kirjeid lisada, muuta või eemaldada, mis võib põhjustada kehtetuid andmeid või harvaesinevaid kirjeid. Samad andmete terviklikkuse valikud pole MongoDB-s saadaval. Saate salvestada seda, mida soovite, olenemata muudest dokumentidest. Ideaalis oleks kogu dokumendi kohta kogu teabe ainus allikas üks dokument.

Vajadus andmebaasimudeli järele

Objektid on Pythoni andmete abstraktsioon. Kõiki Pythoni programmi andmeid esindavad objektid või objektidevahelised suhted. Kuigi objektid on hea viis andmete esitamiseks, tekib probleem siis, kui tahame andmed püsivaks muuta. Andmemaht võib olla tohutu ning see tuleb püsimälust kiiresti ja tõhusalt kätte saada. Seda andmebaasitarkvara tuleb kasutada objektide salvestamiseks. Võimalik andmebaasitarkvara on relatsiooniline, SQL-põhine andmebaasitarkvara.

Objekt-relatsiooniline kaardistaja (ORM) on koodikogu, mis automatiseerib relatsiooniliste andmebaaside tabelitesse salvestatud andmete edastamise Pythoni objektidesse, mida kasutatakse Pythoni koodis. ORM-id pakuvad relatsioonide andmebaasil kõrgetasemelist abstraktsiooni, mis võimaldab arendajal kirjutada SQL-i süntaksile Python-koodi, et oma andmebaasis andmeid ja skeeme luua, lugeda, värskendada ja kustutada. Arendajad saavad SQL-käskude või salvestatud protseduuride kirjutamise asemel kasutada Pythoni programmeerimiskeelt, millega nad on rahul.

ORM-i raamistiku näide Pythoni kohta on SQLAlchemy. SQLAlchemy ORM esitab meetodi kasutaja määratletud Pythoni klasside seostamiseks andmebaasitabelitega ja nende klasside (objektide) eksemplarid nende vastavate tabelite ridadega. See sisaldab süsteemi, mis sünkroonib läbipaistvalt kõik oleku muutused objektide ja nendega seotud ridade vahel. Veebiraamistikud nagu kolb kasutavad SQLAlchemyt andmete püsivaks salvestamiseks.

Django ORM: Djangol on lühidalt oma ORM või mudel.Mudel on ainus, lõplik teabeallikas teie andmete kohta. See sisaldab teie salvestatavate andmete olulisi välju ja käitumist. Üldiselt kaardistab iga mudel ühe andmebaasi tabeli. Django mudel võimaldab vahetada ka mitmesuguseid relatsiooniandmebaase nagu Oracle SQL, MySQL või MSSQL.

Django ORM-i kasutamine dokumentide lisamiseks MongoDB-sse

Oletame, et soovite luua ajaveebiplatvormi, kasutades Djangot koos taustaprogrammiga MongoDB.

Teie Blog app/models.pyfaili määratleda BlogContentmudel:

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 Admini abil mudeli juurde pääsemiseks vajate ülaltoodud mudeli jaoks vormi definitsiooni. Määratlege see järgmiselt:

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

Now "kinnistada" oma BlogContentsees BlogPostkasutades EmbeddedModelFieldalljärgnevalt:

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

See on see, et olete seatud! Käivitage Django administraator localhostis: 8000 / admin / ja see on see, mida saate:

Järgmisena oletame, et soovite autorivälja laiendada nii, et see sisaldaks mitte ainult nime. Teil on vaja nii nime kui ka e-posti aadressi. Tehke autori väljast lihtsalt süvivälja asemel manustatud väli:

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

Kui ajaveebipostitusel on mitu sisu mitmelt autorilt, määrake uus mudel:

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

Käivitage Django administraator uute muudatustega ja teil on:

Django ja MongoDB integreerimise viisid.

Django ORM koosneb mitmest teineteise peale laotud abstraktsioonikihist.

Veebiarendajana saate väljakutse ühendada Django MongoDB-ga kahel viisil. Võimalike sisestuspunktide aimamiseks heitke pilk ülaltoodud Django raamistiku virnale.

Kasutage MongoDB-ga ühilduvat mudelit

Võite täielikult vältida „kaasasolevate patareide“ Django mudelite kasutamist oma projektis. Selle asemel kasutage oma Django projektides kolmanda osapoole raamistikku, näiteks MongoEngine või Ming.

Erineva mudeli valimine tähendab, et jätate ilma:

  • 1500+ projekti peamist panustajat
  • Tunniparandused ja piletite eraldusvõime

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.

Selleks on vaja mõnda protsessori tsüklit. Aga kui lisaprotsessorite tsüklid on tõesti selline probleem, ei tohiks te ilmselt Pythoni kasutada.

Järeldus

Tutvustasin teid mitmel viisil Django integreerimiseks MongoDB-ga. Siit leiate hulgaliselt veebikirjandust, mis kirjeldab MongoEngine'i ja muid selle tegemise variante.

Keskendusin Djongole, mis on uus pistik, mis võimaldab seda teistmoodi. Seda on lihtne kasutada ja see muudab SQL-i taustaprogrammist MongoDB-sse üleviimise protsessi väga lihtsaks, lisades ainult ühe koodirea .