Share
NoSQL databases zijn de laatste jaren enorm ontstaan dankzij hun minder beperkte structuur, schaalbaar schemabeeld en snellere toegang in vergelijking met traditionele relationele databases (RDBMS / SQL). MongoDB is een open source documentgeoriënteerde NoSQL-database die gegevens opslaat in de vorm van JSON-achtige objecten. Het is naar voren gekomen als een van de toonaangevende databases vanwege zijn dynamische schema, hoge schaalbaarheid, optimale queryprestaties, snellere indexering en een actieve gebruikersgemeenschap.
Als u afkomstig bent van een RDBMS / SQL-achtergrond, kan het begrijpen van NoSQL- en MongoDB-concepten een beetje moeilijk zijn tijdens het starten, omdat beide technologieën een zeer verschillende manier van gegevensrepresentatie hebben. Dit artikel zal u ertoe aanzetten om te begrijpen hoe het RDBMS / SQL-domein, de functionaliteiten, termen en query-taal toewijzen aan de MongoDB-database. Met mapping bedoel ik dat als we een concept in RDBMS / SQL hebben, we zullen zien wat het equivalente concept in MongoDB is..
We beginnen met het in kaart brengen van de elementaire relationele concepten zoals tabel, rij, kolom, enz. En verplaatsen om indexering en joins te bespreken. We zullen dan de SQL-query's bekijken en hun overeenkomstige MongoDB databasequery's bespreken. In het artikel wordt ervan uitgegaan dat u op de hoogte bent van de elementaire relationele databaseconcepten en SQL, omdat in het artikel meer nadruk zal worden gelegd op het begrip van hoe deze concepten in MongoDB in kaart worden gebracht. Laten we beginnen.
Elke database in MongoDB bestaat uit verzamelingen die gelijkwaardig zijn aan een RDBMS-database die bestaat uit SQL-tabellen. Elke verzameling slaat gegevens op in de vorm van documenten, wat overeenkomt met tabellen die gegevens in rijen opslaan. Terwijl een rij gegevens in zijn reeks kolommen opslaat, heeft een document een JSON-achtige structuur (bekend als BSON in MongoDB). Als laatste, de manier waarop we rijen in een SQL-rij hebben, hebben we velden in MongoDB. Het volgende is een voorbeeld van een document (lees rij) met enkele velden (lees kolommen) die gebruikersgegevens opslaan:
Accentsconagua
"_id": ObjectId ("5146bb52d8524270060001f3"), "age": 25, "city": "Los Angeles", "email": "[email protected]", "user_name": "Mark Hanks" Dit document is equivalent aan één rij in RDBMS. Een verzameling bestaat uit veel van dergelijke documenten, net zoals een tabel uit veel rijen bestaat. Merk op dat elk document in een verzameling een uniek karakter heeft _ID kaart veld, een veld van 12 bytes dat als primaire sleutel voor de documenten fungeert. Het veld wordt automatisch gegenereerd bij het maken van het document en wordt gebruikt voor het uniek identificeren van elk document.
Als u de toewijzingen beter wilt begrijpen, nemen we een voorbeeld van een SQL-tabel gebruikers en de bijbehorende structuur in MongoDB. Zoals weergegeven in figuur 1, transformeert elke rij in de SQL-tabel naar een document en elke kolom naar een veld in MongoDB.
Een interessant ding om te focussen is dat verschillende documenten binnen een verzameling verschillende schema's kunnen hebben. Het is dus mogelijk in MongoDB dat één document vijf velden heeft en het andere document zeven velden. De velden kunnen op elk moment eenvoudig worden toegevoegd, verwijderd en aangepast. Er is ook geen beperking voor gegevenstypen van de velden. Zo kan in een bepaald geval een veld behouden blijven int typ gegevens en bij de volgende instantie kan het een rangschikking.
Deze concepten moeten erg verschillen van de lezers die afkomstig zijn van de RDBMS-achtergrond, waarbij de tabelstructuren, hun kolommen, gegevenstypen en relaties vooraf zijn gedefinieerd. Met deze functionaliteit om dynamisch schema te gebruiken, kunnen we tijdens runtime dynamische documenten genereren.
Beschouw bijvoorbeeld de volgende twee documenten in dezelfde verzameling maar met verschillende schema's (Afb. 2):
Het eerste document bevat de velden adres en dob die niet aanwezig zijn in het tweede document terwijl het tweede document velden bevat geslacht en bezetting die niet aanwezig zijn in de eerste. Stel je voor dat we dit ding in SQL zouden hebben ontworpen, dan hadden we er vier extra kolommen voor bewaard adres, dob, geslacht en bezetting, sommige zouden lege (of nul) waarden opslaan en daardoor onnodige ruimte innemen.
Dit model van dynamisch schema is de reden waarom NosSQL-databases zeer schaalbaar zijn in termen van ontwerp. Verschillende complexe schema's (hiërarchisch, met een boomstructuur gestructureerd enz.) Waarvoor een aantal RDBMS-tabellen nodig is, kunnen efficiënt worden ontworpen met behulp van dergelijke documenten. Een typisch voorbeeld is het opslaan van gebruikersberichten, hun vind-ik-leuks, opmerkingen en andere bijbehorende informatie in de vorm van documenten. Een SQL-implementatie voor hetzelfde zou idealiter aparte tabellen hebben voor het opslaan van berichten, opmerkingen en likes, terwijl een MongoDB-document al deze informatie in één document kan opslaan.
Relaties in RDBMS worden bereikt met behulp van primaire en externe sleutelrelaties en query's met behulp van joins. Er bestaat geen eenduidige toewijzing in MongoDB, maar de relaties hier worden ontworpen met behulp van ingesloten en gekoppelde documenten.
Overweeg een voorbeeld waarin we gebruikersinformatie en bijbehorende contactgegevens moeten opslaan. Een ideaal SQL-ontwerp zou bijvoorbeeld twee tabellen hebben gebruikers informatie en contactgegevens, met primaire sleutels ID kaart en contact_id zoals getoond in Fig. 3. De contactgegevens tabel zou ook een kolom bevatten gebruikersnaam wat de externe sleutel zou zijn die linkt naar de ID kaart veld van de gebruikers informatie tafel.
Nu zullen we zien hoe we dergelijke relaties in MongoDB zouden ontwerpen met behulp van benaderingen voor het koppelen van documenten en ingesloten documenten. Merk op dat we in het SQL-schema meestal een kolom toevoegen (zoals ID kaart en contact_id in ons geval), die fungeert als een primaire kolom voor die tabel. In MongoDB gebruiken we meestal de automatisch gegenereerde _ID kaart veld als de primaire sleutel om de documenten eenduidig te identificeren.
Deze aanpak maakt gebruik van twee collecties, gebruikers informatie en contactgegevens beide hebben hun unieke _ID kaart velden. We zullen een veld hebben gebruikersnaam in de contactgegevens document dat betrekking heeft op de _ID kaart veld van de gebruikers informatie document dat laat zien met welke gebruiker het contact overeenkomt. (Zie Afb. 4) Merk op dat in MongoDB de relaties en de bijbehorende bewerkingen handmatig moeten worden aangepakt (bijvoorbeeld door middel van code), omdat er geen beperkingen voor buitenlandse sleutels zijn en regels van toepassing zijn.
De gebruikersnaam veld in ons document is eenvoudigweg een veld dat enkele gegevens bevat en alle logica die eraan verbonden is, moet door ons worden geïmplementeerd. Bijvoorbeeld, zelfs als u wat invoegt gebruikersnaam in de contactgegevens document dat niet bestaat in de gebruikers informatie verzameling, MongoDB zal geen fouten melden door te zeggen dat dit overeenkomt gebruikersnaam werd niet gevonden in de gebruikers informatie verzameling (in tegenstelling tot SQL waarbij dit een ongeldige externe-sleutelbeperking zou zijn).
De tweede benadering is om het contactgegevens document in de gebruikers informatie document zoals dit (Fig 5):
In het bovenstaande voorbeeld hebben we een klein document met contactgegevens in de gebruikersinformatie ingesloten. Op dezelfde manier kunnen grote complexe documenten en hiërarchische gegevens op deze manier worden ingebed om entiteiten te relateren.
Ook is de benadering die wordt gehanteerd bij Linking en Embedded-benadering afhankelijk van het specifieke scenario. Als wordt verwacht dat de in te voegen gegevens groter worden, is het beter om de methode Linking te gebruiken in plaats van de Embedded-aanpak om te voorkomen dat het document te groot wordt. Ingebedde benadering wordt over het algemeen gebruikt in gevallen waarin een beperkte hoeveelheid informatie (zoals adres in ons voorbeeld) moet worden ingebed.
Samenvattend, de volgende grafiek (Fig. 6) geeft de gemeenschappelijke co-relaties weer die we hebben besproken:
Nu we ons vertrouwd zijn met de basistoewijzingen tussen RDBMS en MongoDB, zullen we bespreken hoe de querytaal die wordt gebruikt om met de database te communiceren, tussen hen verschilt.
Laten we voor MongoDB-zoekopdrachten een verzameling aannemen gebruikers met documentstructuur als volgt:
"_id": ObjectId ("5146bb52d8524270060001f3"), "post_text": "Dit is een voorbeeldbericht", "user_name": "mark", "post_privacy": "public", "post_likes_count": 0 Voor SQL-query's nemen we de tabel aan gebruikers met vijf kolommen met de volgende structuur:
We bespreken vragen gerelateerd aan het maken en wijzigen van collecties (of tabellen), invoegen, lezen, bijwerken en verwijderen van documenten (of rijen). Er zijn twee query's voor elk punt, één voor SQL en een andere voor MongoDB. Ik zal de MongoDB-query's alleen uitleggen omdat we goed bekend zijn met de SQL-query's. De MongoDB-query's die hier worden weergegeven, zijn geschreven in de Mongo JavaScript-shell terwijl de SQL-query's zijn geschreven in MySQL.
In MongoDB is het niet nodig om de verzamelstructuur expliciet te maken (zoals we doen voor tabellen met een CREËER TAFEL vraag). De structuur van het document wordt automatisch gemaakt wanneer de eerste insert in de verzameling voorkomt. U kunt echter een lege verzameling maken met createCollection commando.
SQL: MAAK TABLE 'posts' ('id' int (11) NOT NULL AUTO_INCREMENT, 'post_text' varchar (500) NOT NULL, 'user_name' varchar (20) NOT NULL, 'post_privacy' varchar (10) NOT NULL, ' post_likes_count 'int (11) NOT NULL, PRIMARY KEY (' id ')) MongoDB: db.createCollection ("berichten") Om een document in MongoDB in te voegen, gebruiken we de invoegen methode waarbij een object met sleutelwaardeparen als invoer wordt gebruikt. Het ingevoegde document bevat de automatisch gegenereerde _ID kaart veld. U kunt echter ook expliciet een 12-byte-waarde opgeven als _ID kaart samen met de andere velden.
SQL: INSERT INTO 'posts' ('id', 'post_text', 'user_name', 'post_privacy', 'post_likes_count') VALUES (NULL, 'Dit is een voorbeeldpost', 'markeren', 'openbaar', '0 '); MongoDB: db.posts.insert (user_name: "mark", post_text: "This is a sample post", post_privacy: "public", post_likes_count: 0) Er is geen Tabel wijzigen functie in MongoDB om de documentstructuur te wijzigen. Omdat de documenten dynamisch van schema zijn, verandert het schema naarmate een update in het document plaatsvindt.
MongoDB gebruikt de vind methode die gelijk is aan de SELECT opdracht in SQL. De volgende verklaringen lezen eenvoudigweg alle documenten van de posts verzameling.
SQL: SELECT * FROM 'posts' MongoDB: db.posts.find ()
De volgende query doet een voorwaardelijke zoekopdracht naar documenten met user_name veld als Mark. Alle criteria voor het ophalen van de documenten moeten in de eerste accolades worden geplaatst gescheiden door komma's.
SQL: SELECT * FROM 'posts' WHERE 'user_name' = 'markeer' MongoDB: db.posts.find (user_name: "mark")
De volgende query haalt specifieke kolommen op, post_text en post_likes_count zoals opgegeven in de tweede set accolades .
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posts' MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1)
Merk op dat MongoDB standaard de _ID kaart veld met elke zoekzin. Als we niet willen dat dit veld in onze resultatenset staat, moeten we het _ID kaart sleutel met een 0 waarde in de lijst met kolommen die moeten worden opgehaald. De 0 waarde van de sleutel geeft aan dat we dit veld willen uitsluiten van de resultatenset.
MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1, _id: 0)
De volgende query haalt specifieke velden op op basis van de criteria die user_name is Mark.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posts' WHERE 'user_name' = 'markeer' MongoDB: db.posts.find (user_name: "mark", post_text: 1, post_likes_count: 1)
We voegen nu nog een criterium toe om de berichten met het privacypakket als openbaar te kunnen ophalen. De criteriumvelden die zijn opgegeven met behulp van komma's vertegenwoordigen de logische EN staat. Deze verklaring zoekt dus naar documenten met beide user_name zoals Mark en post_privacy zoals openbaar.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posts' WHERE 'user_name' = 'mark' AND 'post_privacy' = 'public' MongoDB: db.posts.find (user_name: "mark", post_privacy: "public" , post_text: 1, post_likes_count: 1)
Logisch gebruiken OF tussen de criteria in de vind methode gebruiken we de $ of operator.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posts' WHERE 'user_name' = 'mark' OR 'post_privacy' = 'public' MongoDB: db.posts.find ($ or: [user_name: "mark" , post_privacy: "public"], post_text: 1, post_likes_count: 1)
Vervolgens gebruiken we de soort methode die het resultaat in oplopende volgorde sorteert post_likes_count(aangegeven door 1).
SQL: SELECT * FROM 'posts' WHERE 'user_name' = 'markeer' volgorde door post_likes_count ASC MongoDB: db.posts.find (user_name: "mark"). Sort (post_likes_count: 1)
Om de resultaten in aflopende volgorde te sorteren, geven we aan -1 als de waarde van het veld.
SQL: SELECT * FROM 'posts' WHERE 'user_name' = 'markeer' volgorde door post_likes_count DESC MongoDB: db.posts.find (user_name: "mark"). Sort (post_likes_count: -1)
Om het aantal te retourneren documenten te beperken, gebruiken we de begrenzing methode die het aantal documenten specificeert.
SQL: SELECT * FROM 'posts' LIMIT 10 MongoDB: db.posts.find (). Limit (10)
De manier waarop we gebruiken compenseren in SQL om een aantal records over te slaan, gebruiken we overspringen functie in MongoDB. De volgende instructie zou bijvoorbeeld tien berichten halen die de eerste vijf overslaan.
SQL: SELECT * FROM 'posts' LIMIT 10 OFFSET 5 MongoDB: db.posts.find (). Limit (10) .skip (5)
De eerste parameter voor de bijwerken methode specificeert de criteria om de documenten te selecteren. De tweede parameter geeft de actuele updateprocedure aan die moet worden uitgevoerd. De volgende query selecteert bijvoorbeeld alle documenten met user_name zoals Mark en zet hun post_privacy zoals privaat.
Een verschil is hier standaard MongoDB bijwerken query-updates slechts één (en het eerste overeenkomende) document. Om alle overeenkomende documenten bij te werken, moeten we een derde parameter specificeren multi zoals waar geeft aan dat we meerdere documenten willen bijwerken.
SQL: UPDATE posts SET post_privacy = "private" WHERE user_name = "mark" MongoDB: db.posts.update (user_name: "mark", $ set: post_privacy: "private", multi: true )
Het verwijderen van documenten is vrij eenvoudig en vergelijkbaar met SQL.
SQL: DELETE FROM berichten WHERE user_name = "mark" MongoDB: db.posts.remove (user_name: "mark")
MongoDB heeft een standaardindex aangemaakt op de _ID kaart gebied van elke verzameling. Om nieuwe indexen over de velden te maken, gebruiken we ensureIndex methode die de velden en de bijbehorende sorteervolgorde aangeeft aangegeven door 1 of -1(oplopend of aflopend).
SQL: CREATE INDEX index_posts ON posts (gebruikersnaam, post_likes_count DESC) MongoDB: db.posts.ensureIndex (user_name: 1, post_likes_count: -1)
Om alle indexen te bekijken die in een verzameling aanwezig zijn, gebruiken we getIndexes methode op dezelfde regels van TOON INDEX query van SQL.
SQL: SHOW INDEX FROM berichten MongoDB: db.posts.getIndexes ()
In dit artikel hebben we begrepen hoe de elementaire concepten en termen van RDBMS / SQL betrekking hebben op MongoDB. We hebben gekeken naar het ontwerpen van relaties in MongoDB en hebben geleerd hoe de functionaliteit van de standaard SQL-query's in MongoDB in kaart is gebracht.
Nadat u een voorsprong hebt genomen met dit artikel, kunt u beginnen met het uitproberen van complexe query's, waaronder aggregatie, kaartvermindering en zoekopdrachten met meerdere collecties. U kunt in het begin ook enkele onlinetools gebruiken om SQL-query's naar MongoDB-query's te converteren. U kunt zelf een voorbeeld van een MongoDB-databaseschema ontwerpen. Een van de beste voorbeelden om dit te doen is een database voor het opslaan van gebruikersberichten, hun vind-ik-leuks, reacties en reacties op reacties. Dit zou u een praktisch beeld geven van het flexibele schemabeeld dat MongoDB biedt.
Reageer gerust op suggesties, vragen of ideeën die u graag verder wilt bekijken.
