Share
NoSQL databaser har vist seg enormt de siste årene på grunn av deres mindre begrensede struktur, skalerbar skjemadesign og raskere tilgang i forhold til tradisjonelle relasjonsdatabaser (RDBMS / SQL). MongoDB er en åpen kildekode-dokumentert NoSQL-database som lagrer data i form av JSON-lignende objekter. Den har oppstått som en av de ledende databasene på grunn av det dynamiske skjemaet, høy skalerbarhet, optimal søkeytelse, raskere indeksering og en aktiv brukergruppe.
Hvis du kommer fra en RDBMS / SQL-bakgrunn, kan forståelse av NoSQL og MongoDB-konseptene være litt vanskelig når du starter fordi begge teknologiene har svært forskjellige måter å representere data på. Denne artikkelen vil drive deg til å forstå hvordan RDBMS / SQL-domenet, dets funksjonalitet, vilkår og spørrespråkskart til MongoDB-databasen. Ved kartlegging mener jeg at hvis vi har et konsept i RDBMS / SQL, vil vi se hva tilsvarende konsept i MongoDB er.
Vi vil begynne med å kartlegge de grunnleggende relasjonelle konseptene som tabell, rad, kolonne, etc og flytte for å diskutere indeksering og bli med. Vi vil da se over SQL-spørringene og diskutere deres tilsvarende MongoDB-databasespørsmål. Artikkelen antar at du er klar over de grunnleggende relasjonelle databasekonseptene og SQL, fordi hele artikkelen legger mer vekt på å forstå hvordan disse begrepene kartlegger MongoDB. La oss begynne.
Hver database i MongoDB består av samlinger som tilsvarer en RDBMS-database som består av SQL-tabeller. Hver samling lagrer data i form av dokumenter som tilsvarer tabeller som lagrer data i rader. Mens en rad lagrer data i sitt sett med kolonner, har et dokument en JSON-lignende struktur (kjent som BSON i MongoDB). Til slutt, måten vi har rader i en SQL-rad, har vi felt i MongoDB. Følgende er et eksempel på et dokument (lese rad) med noen felt (les kolonner) lagre brukerdata:
Accentsconagua
"_id": ObjectId ("5146bb52d8524270060001f3"), "alder": 25, "by": "Los Angeles", "email": "[email protected]", "user_name": "Mark Hanks" Dette dokumentet tilsvarer en enkelt rad i RDBMS. En samling består av mange slike dokumenter, akkurat som et bord består av mange rader. Merk at hvert dokument i en samling har en unik _id feltet, som er et 12-byte-felt som tjener som en primærnøkkel for dokumentene. Feltet er automatisk generert ved opprettelse av dokumentet og brukes til unikt identifisering av hvert dokument.
For å forstå mappingene bedre, la oss ta et eksempel på et SQL-bord brukere og den tilhørende strukturen i MongoDB. Som vist i figur 1, omformer hver rad i SQL-tabellen til et dokument og hver kolonne til et felt i MongoDB.
En interessant ting å fokusere her er at forskjellige dokumenter i en samling kan ha forskjellige skjemaer. Så det er mulig i MongoDB at ett dokument har fem felt og det andre dokumentet har syv felt. Feltene kan enkelt legges til, fjernes og endres når som helst. Det er heller ingen begrensning på datatyper av feltene. Dermed kan et felt i ett tilfelle holde int skriv data og i det neste tilfelle kan det inneholde en matrise.
Disse konseptene må virke svært forskjellige for leserne som kommer fra RDBMS-bakgrunnen der tabellstrukturer, deres kolonner, datatyper og relasjoner er forhåndsdefinerte. Denne funksjonaliteten for å bruke dynamisk skjema gjør at vi kan generere dynamiske dokumenter ved kjøretid.
For eksempel, vurder følgende to dokumenter i samme samling, men har forskjellige skjemaer (figur 2):
Det første dokumentet inneholder feltene adresse og Dob som ikke er til stede i det andre dokumentet mens det andre dokumentet inneholder felt kjønn og okkupasjon som ikke er til stede i den første. Tenk deg om vi ville ha designet denne tingen i SQL, ville vi ha holdt fire ekstra kolonner for adresse, Dob, kjønn og okkupasjon, hvorav noen vil lagre tomme (eller null) verdier, og dermed okkupere unødvendig plass.
Denne modellen med dynamisk skjema er grunnen til at NosSQL-databaser er svært skalerbare når det gjelder design. Ulike komplekse skjemaer (hierarkisk, trestrukturert osv.) Som ville kreve antall RDBMS-tabeller, kan utformes effektivt ved hjelp av slike dokumenter. Et typisk eksempel ville være å lagre brukerinnlegg, deres liker, kommentarer og annen tilknyttet informasjon i form av dokumenter. En SQL-implementering for det samme ville ideelt sett ha separate tabeller for lagring av innlegg, kommentarer og liker mens et MongoDB-dokument kan lagre all denne informasjonen i et enkelt dokument.
Forhold i RDBMS oppnås ved å bruke primære og utenlandske nøkkelrelasjoner og spørre de som bruker tilkoblinger. Det er ikke så enkelt kartlegging i MongoDB, men forholdene her er utformet ved hjelp av innebygde og lenke dokumenter.
Tenk på et eksempel der vi må lagre brukerinformasjon og tilsvarende kontaktinformasjon. Et ideelt SQL-design ville ha to bord, si brukerinformasjon og kontaktinformasjon, med primære nøkler id og contact_id som vist i fig. 3 kontaktinformasjon Tabellen vil også inneholde en kolonne bruker-ID som ville være den utenlandske nøkkelen som knytter til id feltet av brukerinformasjon bord.
Nå vil vi se hvordan vi vil utforme slike relasjoner i MongoDB ved hjelp av tilnærminger til Koble dokumenter og Embedded dokumenter. Vær oppmerksom på at i SQL-skjemaet legger vi vanligvis til en kolonne (som id og contact_id i vårt tilfelle) som fungerer som en primær kolonne for den tabellen. Men i MongoDB bruker vi vanligvis den genererte autoen _id feltet som primærnøkkel for å identifisere dokumentene unikt.
Denne tilnærmingen vil bruke to samlinger, brukerinformasjon og kontaktinformasjon begge har sin unike _id Enger. Vi vil ha et felt bruker-ID i kontaktinformasjon dokument som vedrører _id feltet av brukerinformasjon dokument som viser hvilken bruker kontakten tilsvarer. (Se Fig. 4). Merk at i MongoDB, må forholdene og deres tilsvarende operasjoner håndteres manuelt (for eksempel gjennom kode), da ingen utenlandske nøkkelbegrensninger og regler gjelder.
De bruker-ID feltet i dokumentet vårt er ganske enkelt et felt som inneholder noen data, og all logikken som er knyttet til den må implementeres av oss. For eksempel, selv om du vil sette inn noen bruker-ID i kontaktinformasjon dokument som ikke finnes i brukerinformasjon samling, MongoDB kommer ikke til å kaste noen feil som sier det tilsvarende bruker-ID ble ikke funnet i brukerinformasjon samling (i motsetning til SQL hvor dette ville være en ugyldig utenlandsk nøkkelbegrensning).
Den andre tilnærmingen er å legge inn kontaktinformasjon dokument inni brukerinformasjon dokument som dette (fig 5):
I eksempelet ovenfor har vi innebygd et lite dokument med kontaktinformasjon inne i brukerinformasjonen. På lignende måte kan store komplekse dokumenter og hierarkiske data bli integrert som dette for å forholde seg til enheter.
Også hvilken tilnærming til bruk mellom Linking og Embedded tilnærming avhenger av det spesifikke scenariet. Hvis dataene som skal legges inn, forventes å bli større i størrelse, er det bedre å bruke Linking approach snarere enn Embedded tilnærming for å unngå at dokumentet blir for stort. Embedded tilnærming brukes vanligvis i tilfeller der en begrenset mengde informasjon (som adresse i vårt eksempel) må legges inn.
For å oppsummere representerer følgende diagram (figur 6) de felles samforbindelsene vi har diskutert:
Nå som vi er komfortable med de grunnleggende kartleggingene mellom RDBMS og MongoDB, vil vi diskutere hvordan spørrespråket som brukes til å samhandle med databasen, er forskjellig mellom dem.
For MongoDB-spørringer, la oss anta en samling brukere med dokumentstruktur som følger:
"_id": ObjectId ("5146bb52d8524270060001f3"), "post_text": "Dette er en prøvepost", "brukernavn": "mark", "post_privacy": "offentlig", "post_likes_count": 0 For SQL-spørringer antar vi tabellen brukere å ha fem kolonner med følgende struktur:
Vi diskuterer spørringer relatert til å opprette og endre samlinger (eller tabeller), sette inn, lese, oppdatere og fjerne dokumenter (eller rader). Det er to spørringer for hvert punkt, en for SQL og en annen for MongoDB. Jeg vil bare forklare MongoDB-spørringene fordi vi er ganske kjent med SQL-spørringene. MongoDB-spørringene som presenteres her er skrevet i Mongo JavaScript-skalet mens SQL-spørringene er skrevet i MySQL.
I MongoDB er det ikke nødvendig å eksplisitt opprette samlingsstrukturen (som vi gjør for tabeller ved hjelp av en CREATE TABLE spørsmål). Dokumentets struktur opprettes automatisk når den første innsatsen oppstår i samlingen. Du kan imidlertid opprette en tom samling ved hjelp av createCollection kommando.
SQL: CREATE TABLE 'innlegg' ('id' int (11) IKKE NULL AUTO_INCREMENT, 'post_text' varchar (500) IKKE NULL, 'brukernavn' varchar (20) IKKE NULL, 'post_privacy' varchar (10) IKKE NULL, ' post_likes_count 'int (11) IKKE NULL, PRIMARY KEY (' id ')) MongoDB: db.createCollection ("innlegg") For å sette inn et dokument i MongoDB bruker vi sett inn metode som tar et objekt med nøkkelverdepar som inngang. Det innsatte dokumentet vil inneholde autogenerert _id felt. Du kan imidlertid også eksplisitt gi en 12 byte verdi som _id sammen med de andre feltene.
SQL: INSERT INTO 'innlegg' ('id', 'post_text', 'brukernavn', 'post_privacy', 'post_likes_count') VÆRDIER (NULL, 'Dette er et eksempel innlegg', 'mark', 'offentlig', '0 '); MongoDB: db.posts.insert (user_name: "mark", post_text: "Dette er et utvalg innlegg", post_privacy: "public", post_likes_count: 0) Det er ingen Endre tabell Funger i MongoDB for å endre dokumentstrukturen. Da dokumentene er dynamiske i skjema, endres skjemaet når og når noen oppdatering skjer på dokumentet.
MongoDB bruker finne metode som tilsvarer Å VELGE kommando i SQL. Følgende uttalelser leser bare alle dokumentene fra innlegg samling.
SQL: VELG * FRA 'innlegg' MongoDB: db.posts.find ()
Følgende spørring krever et betinget søk etter dokumenter som har brukernavn feltet som merke. Alle kriteriene for å hente dokumentene må plasseres i de første braces atskilt med kommaer.
SQL: SELECT * FRA 'innlegg' hvor 'user_name' = 'mark' MongoDB: db.posts.find (user_name: "mark")
Følgende spørring henter bestemte kolonner, POST_TEXT og post_likes_count som angitt i det andre settet av braces .
SQL: SELECT 'post_text', 'post_likes_count' FRA 'innlegg' MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1)
Legg merke til at MongoDB som standard returnerer _id felt med hver finner setning. Hvis vi ikke vil ha dette feltet i resultatlisten, må vi spesifisere _id nøkkel med a 0 verdi i listen over kolonner som skal hentes. De 0 verdien av nøkkelen indikerer at vi vil ekskludere dette feltet fra resultatsettet.
MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1, _id: 0)
Følgende søk henter bestemte felt basert på kriteriene som brukernavn er merke.
SQL: SELECT 'post_text', 'post_likes_count' FRA 'innlegg' WHERE 'user_name' = 'mark' MongoDB: db.posts.find (user_name: "mark", post_text: 1, post_likes_count: 1)
Vi legger nå til ytterligere et kriterium for å hente innleggene med privatlivstype som offentlig. Kriteriene som er angitt ved hjelp av komma, representerer det logiske OG tilstand. Dermed vil denne setningen se etter dokumenter som har begge brukernavn som merke og post_privacy som offentlig.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'innlegg' WHERE 'user_name' = 'mark' og 'post_privacy' = 'offentlig' MongoDB: db.posts.find (user_name: "mark", post_privacy: "public" , POST_TEXT: 1, post_likes_count: 1)
Å bruke logisk ELLER mellom kriteriene i finne metode, bruker vi $ eller operatør.
SQL: SELECT 'post_text', 'post_likes_count' FRA 'innlegg' WHERE 'user_name' = 'mark' ELLER 'post_privacy' = 'offentlig' MongoDB: db.posts.find ($ eller: [user_name: "mark" , post_privacy: "offentlige"], POST_TEXT: 1, post_likes_count: 1)
Deretter skal vi bruke sortere metode som sorterer resultatet i stigende rekkefølge av post_likes_count(indikert av 1).
SQL: SELECT * FRA 'innlegg' WHERE 'user_name' = 'mark' rekkefølge etter post_likes_count ASC MongoDB: db.posts.find (user_name: "mark"). Sorter (post_likes_count: 1)
For å sortere resultatene i synkende rekkefølge, spesifiserer vi -1 som verdien av feltet.
SQL: SELECT * FRA 'innlegg' WHERE 'user_name' = 'mark' rekkefølge av post_likes_count DESC MongoDB: db.posts.find (user_name: "mark"). Sort (post_likes_count: -1)
For å begrense antall dokumenter som skal returneres bruker vi grense Metode som angir antall dokumenter.
SQL: SELECT * FRA 'innlegg' LIMIT 10 MongoDB: db.posts.find () .grense (10)
Måten vi bruker offset i SQL for å hoppe over et antall poster, bruker vi hoppe fungere i MongoDB. For eksempel vil følgende setning hente ti innlegg som hopper over de første fem.
SQL: SELECT * FRA 'innlegg' LIMIT 10 OFFSET 5 MongoDB: db.posts.find () .grense (10) .skip (5)
Den første parameteren til Oppdater Metoden spesifiserer kriteriene for å velge dokumentene. Den andre parameteren angir den faktiske oppdateringsoperasjonen som skal utføres. For eksempel velger følgende spørring alle dokumentene med brukernavn som merke og setter deres post_privacy som privat.
En forskjell her er det som standard, MongoDB Oppdater Søkeoppdateringer bare ett (og det første samsvarende) dokumentet. For å oppdatere alle de samsvarende dokumentene må vi oppgi en tredje parameter som spesifiserer multi som ekte som indikerer at vi vil oppdatere flere dokumenter.
SQL: UPDATE innlegg SET post_privacy = "private" WHERE user_name = "mark" MongoDB: db.posts.update (user_name: "mark", $ sett: post_privacy: "private", multi: true )
Fjerne dokumenter er ganske enkelt og ligner på SQL.
SQL: DELETE FROM innlegg WHERE user_name = "mark" MongoDB: db.posts.remove (user_name: "mark")
MongoDB har en standardindeks opprettet på _id felt i hver samling. For å lage nye indekser på feltene, bruker vi ensureIndex metode som angir feltene og tilhørende sorteringsordre angitt av 1 eller -1(stigende eller synkende).
SQL: CREATE INDEX index_posts PÅ innlegg (brukernavn, post_likes_count DESC) MongoDB: db.posts.ensureIndex (user_name: 1, post_likes_count: -1)
For å se alle indeksene som er tilstede i en samling, bruker vi getIndexes metode på samme linje av VIS INDEX spørring av SQL.
SQL: VIS INDEKS FRA innlegg MongoDB: db.posts.getIndexes ()
I denne artikkelen forsto vi hvordan de grunnleggende konseptene og betingelsene for RDBMS / SQL er relatert til MongoDB. Vi så på å designe relasjoner i MongoDB og lærte hvordan funksjonaliteten til grunnleggende SQL-spørringer kart i MongoDB.
Etter å ha fått en start med denne artikkelen, kan du fortsette å utføre komplekse spørringer, inkludert aggregering, kartreduksjon og spørringer som involverer flere samlinger. Du kan også ta hjelp av noen elektroniske verktøy for å konvertere SQL-spørringer til MongoDB-spørringer i begynnelsen. Du kan spille med å designe et sample MongoDB-databaseskema på egen hånd. Et av de beste eksemplene på å gjøre det, ville være en database for å lagre brukerinnlegg, deres kommentarer, kommentarer og kommentarer. Dette gir deg en praktisk oversikt over det fleksible skjematisk designet som MongoDB tilbyr.
Du er velkommen til å kommentere eventuelle forslag, spørsmål eller ideer du vil se videre.
