Share
NoSQL databaser har uppstått enormt under de senaste åren på grund av sin mindre begränsade struktur, skalbar schema design och snabbare åtkomst jämfört med traditionella relationsdatabaser (RDBMS / SQL). MongoDB är en öppen källdokumentorienterad NoSQL-databas som lagrar data i form av JSON-liknande objekt. Det har uppstått som en av de ledande databaserna på grund av dess dynamiska schema, hög skalbarhet, optimal sökprestanda, snabbare indexering och en aktiv användargrupp.
Om du kommer från en RDBMS / SQL-bakgrund kan förståelse NoSQL och MongoDB-koncept vara lite svårt när du startar eftersom båda teknikerna har ett mycket annorlunda sätt att representera data. Den här artikeln kommer att driva dig för att förstå hur RDBMS / SQL-domänen, dess funktionaliteter, termer och frågeformulär till MongoDB-databasen. Genom kartläggning menar jag att om vi har ett koncept i RDBMS / SQL, ser vi vad dess ekvivalenta koncept i MongoDB är.
Vi börjar med att kartlägga de grundläggande relationella koncepten som tabell, rad, kolumn mm och flytta för att diskutera indexering och anslutning. Vi ska sedan titta på SQL-frågorna och diskutera deras motsvarande MongoDB-databasfrågor. Artikeln förutsätter att du är medveten om de grundläggande relationella databaskoncepten och SQL, eftersom hela artikeln kommer att läggas mer på att förstå hur dessa begrepp kartlägger i MongoDB. Låt oss börja.
Varje databas i MongoDB består av samlingar som motsvarar en RDBMS-databas som består av SQL-tabeller. Varje samling lagrar data i form av dokument som motsvarar tabeller som lagrar data i rader. Medan en rad lagrar data i sin uppsättning kolumner har ett dokument en JSON-liknande struktur (känd som BSON i MongoDB). Slutligen, hur vi har rader i en SQL-rad, vi har fält i MongoDB. Följande är ett exempel på ett dokument (läs rad) med några fält (läs kolumner) som lagrar användardata:
Accentsconagua
"_id": ObjectId ("5146bb52d8524270060001f3"), "ålder": 25, "stad": "Los Angeles", "email": "[email protected]", "användarnamn": "Mark Hanks" Detta dokument motsvarar en enda rad i RDBMS. En samling består av många sådana dokument precis som ett bord består av många rader. Observera att varje dokument i en samling har en unik _id fält, vilket är ett 12-bytefält som fungerar som en primär nyckel för dokumenten. Fältet genereras automatiskt vid skapandet av dokumentet och används för att identifiera varje dokument unikt.
För att förstå mappningarna bättre, låt oss ta ett exempel på ett SQL-bord användare och dess motsvarande struktur i MongoDB. Som visas i Fig 1, omvandlas varje rad i SQL-tabellen till ett dokument och varje kolumn till ett fält i MongoDB.
En intressant sak att fokusera här är att olika dokument inom en samling kan ha olika scheman. Så det är möjligt i MongoDB att ett dokument har fem fält och det andra dokumentet har sju fält. Fälten kan enkelt läggas till, tas bort och ändras när som helst. Det finns inte heller några begränsningar för datatyperna i fälten. Således kan i ett fall ett fält hålla int skriv data och i nästa fall kan det innehålla en array.
Dessa begrepp måste verka väldigt olika för läsarna som kommer från RDBMS-bakgrunden där tabellstrukturerna, deras kolumner, datatyper och relationer är fördefinierade. Denna funktion att använda dynamiskt schema låter oss generera dynamiska dokument vid körtiden.
Tänk på följande två dokument i samma samling men med olika scheman (Fig 2):
Det första dokumentet innehåller fälten adress och dob som inte finns i det andra dokumentet medan det andra dokumentet innehåller fält kön och ockupation som inte är närvarande i den första. Tänk om vi skulle ha utformat den här saken i SQL, skulle vi ha hållit fyra extra kolumner för adress, dob, kön och ockupation, Vissa av dem skulle lagra tomma (eller noll) värden och därmed uppta onödigt utrymme.
Denna modell av dynamiskt schema är anledningen till att NosSQL-databaser är mycket skalbara när det gäller design. Olika komplexa scheman (hierarkiska, trädstrukturerad etc) som skulle kräva antal RDBMS-tabeller kan utformas effektivt med hjälp av sådana dokument. Ett typiskt exempel skulle vara att lagra användarinlägg, deras gillar, kommentarer och annan tillhörande information i form av dokument. En SQL-implementering för samma skulle helst ha separata tabeller för att lagra inlägg, kommentarer och liknande medan ett MongoDB-dokument kan lagra all denna information i ett enda dokument.
Förhållanden i RDBMS uppnås genom att använda primära och utländska nyckelrelationer och fråga dem som ansluter sig. Det finns ingen sådan enkel kartläggning i MongoDB men relationerna här är utformade med hjälp av inbäddade och länkande dokument.
Tänk på ett exempel där vi behöver lagra användarinformation och motsvarande kontaktinformation. En idealisk SQL-design skulle ha två tabeller, säger användar information och kontakt information, med primära nycklar id och contact_id som visas i Fig. 3 kontakt information bordet skulle också innehålla en kolumn användar ID vilken skulle vara den främmande nyckeln som länkar till id fält av användar information tabell.
Nu ser vi hur vi skulle utforma sådana relationer i MongoDB med hjälp av metoder för länkande dokument och inbäddade dokument. Observera att i SQL-schemat lägger vi i allmänhet en kolumn (som id och contact_id i vårt fall) som fungerar som en primär kolumn för den tabellen. Men i MongoDB brukar vi generellt generera auto _id fält som den primära nyckeln för att unikt identifiera dokumenten.
Detta tillvägagångssätt kommer att använda två samlingar, användar information och kontakt information båda har sina unika _id fält. Vi kommer att ha ett fält användar ID i kontakt information dokument som hänför sig till _id fält av användar information dokument som visar vilken användare kontakten motsvarar. (Se Fig 4) Observera att i MongoDB måste relationerna och deras motsvarande operationer tas hand om manuellt (till exempel genom kod) eftersom inga främmande nyckelbegränsningar och regler gäller.
De användar ID fältet i vårt dokument är helt enkelt ett fält som innehåller vissa data och all logik som är kopplad till den måste genomföras av oss. Till exempel, även om du lägger in några användar ID i kontakt information dokument som inte finns i användar information samling, MongoDB kommer inte att kasta något fel som säger att motsvarande användar ID hittades inte i användar information samling (till skillnad från SQL där detta skulle vara en ogiltig främmande nyckelbegränsning).
Det andra tillvägagångssättet är att bädda in kontakt information dokument inuti användar information dokumentera så här (fig 5):
I ovanstående exempel har vi inbäddat ett litet dokument av kontaktinformation inuti användarinformationen. På liknande sätt kan stora komplexa dokument och hierarkiska data inbäddas så här för att relatera enheter.
Vilket sätt att använda bland Linking och Embedded-tillvägagångssättet beror också på det specifika scenariot. Om data som ska inbäddas förväntas bli större i storlek, är det bättre att använda Linking approach snarare än Embedded approach för att undvika att dokumentet blir för stort. Inbäddad tillvägagångssätt används generellt i de fall då en begränsad mängd information (som adress i vårt exempel) måste inbäddas.
Sammanfattningsvis representerar följande diagram (Fig 6) de gemensamma samförbindelserna som vi har diskuterat:
Nu när vi är bekväma med de grundläggande kartläggningarna mellan RDBMS och MongoDB, kommer vi att diskutera hur frågespråket som används för att interagera med databasen skiljer sig åt mellan dem.
För MongoDB-frågor, låt oss anta en samling användare med dokumentstruktur enligt följande:
"_id": ObjectId ("5146bb52d8524270060001f3"), "post_text": "Detta är ett provpost", "användarnamn": "mark", "post_privacy": "public", "post_likes_count": 0 För SQL-frågor antar vi tabellen användare med fem kolumner med följande struktur:
Vi kommer att diskutera frågor relaterade till att skapa och ändra samlingar (eller tabeller), infoga, läsa, uppdatera och ta bort dokument (eller rader). Det finns två frågor för varje punkt, en för SQL och en annan för MongoDB. Jag kommer bara att förklara MongoDB-frågorna eftersom vi är ganska bekanta med SQL-frågorna. MongoDB-frågorna som presenteras här är skrivna i Mongo JavaScript-skalet medan SQL-frågorna är skrivna i MySQL.
I MongoDB är det inte nödvändigt att uttryckligen skapa samlingsstrukturen (som vi gör för tabeller med hjälp av a SKAPA BORD fråga). Dokumentets struktur skapas automatiskt när den första insatsen uppträder i samlingen. Du kan dock skapa en tom samling med createCollection kommando.
SQL: CREATE TABLE 'inlägg' ('id' int (11) INTE NULL AUTO_INCREMENT, 'post_text' varchar (500) INTE NULL, 'användarnamn' varchar (20) INTE NULL, 'post_privacy' varchar (10) INTE NULL, ' post_likes_count 'int (11) INTE NULL, PRIMÄR KEY (' id ')) MongoDB: db.createCollection ("inlägg") För att infoga ett dokument i MongoDB använder vi Föra in metod som tar ett objekt med nyckelvärdespar som ingång. Det infogade dokumentet innehåller autogenererade _id fält. Du kan dock också uttryckligen ge ett 12 byte värde som _id tillsammans med de andra fälten.
SQL: INSERT INTO 'inlägg' ('id', 'post_text', 'användarnamn', 'post_privacy', 'post_likes_count') VÄRDEN (NULL, 'Detta är ett provpost', 'mark', 'offentligt', '0 '); MongoDB: db.posts.insert (user_name: "mark", post_text: "Detta är ett provpost", post_privacy: "public", post_likes_count: 0) Det finns inget Ändra tabell funktion i MongoDB för att ändra dokumentstrukturen. Eftersom dokumenten är dynamiska i schema ändras schemat när och när någon uppdatering händer på dokumentet.
MongoDB använder hitta metod som motsvarar VÄLJ kommando i SQL. Följande uttalanden läser helt enkelt alla dokument från inlägg samling.
SQL: VÄLJ * FRÅN 'inlägg' MongoDB: db.posts.find ()
Följande fråga gör en villkorlig sökning efter dokument som har Användarnamn fält som markera. Alla kriterier för att hämta dokumenten måste placeras i de första häftarna separerade med kommatecken.
SQL: SELECT * FRÅN "inlägg" VAR "användarnamn" = "markera" MongoDB: db.posts.find (user_name: "mark")
Följande fråga hämtar specifika kolumner, POST_TEXT och post_likes_count som anges i den andra uppsättningen hängslen .
SQL: SELECT 'post_text', 'post_likes_count' FRÅN 'inlägg' MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1)
Observera att MongoDB som standard returnerar _id fält med varje hittadeklaration. Om vi inte vill ha det här fältet i vår resultatuppsättning måste vi ange _id nyckel med a 0 värde i listan över kolumner som ska hämtas. De 0 Värdet på nyckeln indikerar att vi vill utesluta detta fält från resultatuppsättningen.
MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1, _id: 0)
Följande fråga hämtar specifika fält baserat på de kriterier som Användarnamn är markera.
SQL: SELECT 'post_text', 'post_likes_count' FRÅN 'inlägg' WHERE 'user_name' = 'markera' MongoDB: db.posts.find (user_name: "mark", post_text: 1, post_likes_count: 1)
Vi lägger nu till ytterligare ett kriterium för att hämta inlägg med privatlivstyp som offentligt. De kriterier som anges med kommatecken representerar det logiska OCH tillstånd. Således kommer detta uttalande att söka efter dokument som har båda Användarnamn som markera och post_privacy som offentlig.
SQL: SELECT 'post_text', 'post_likes_count' FRÅN 'inlägg' WHERE 'user_name' = 'mark' och 'post_privacy' = 'offentliga' MongoDB: db.posts.find (user_name: "mark", post_privacy: "public" , POST_TEXT: 1, post_likes_count: 1)
Att använda logiskt ELLER mellan kriterierna i hitta metod använder vi $ eller operatör.
SQL: SELECT 'post_text', 'post_likes_count' FRÅN 'inlägg' WHERE 'user_name' = 'mark' ELLER 'post_privacy' = 'public' MongoDB: db.posts.find ($ eller: [användarnamn: "mark" , post_privacy: "offentliga"], POST_TEXT: 1, post_likes_count: 1)
Därefter kommer vi att använda sortera metod som sorterar resultatet i stigande ordning av post_likes_count(indikerat av 1).
SQL: VÄLJ * FRÅN 'inlägg' VAR 'användarnamn' = 'markera' ordning med post_likes_count ASC MongoDB: db.posts.find (användarnamn: "mark"). Sort (post_likes_count: 1)
För att sortera resultaten i fallande ordning anger vi -1 som värdet av fältet.
SQL: SELECT * FRÅN 'inlägg' VAR 'användarnamn' = 'markera' ordning efter post_likes_count DESC MongoDB: db.posts.find (användarnamn: "mark"). Sort (post_likes_count: -1)
För att begränsa antalet dokument som ska returneras använder vi begränsa metod som anger antalet dokument.
SQL: SELECT * FRÅN "inlägg" LIMIT 10 MongoDB: db.posts.find (). Limit (10)
Sättet vi använder offset i SQL för att hoppa över ett antal poster, använder vi hoppa funktion i MongoDB. Till exempel skulle följande uttalande hämta tio poster som hoppar över de första fem.
SQL: SELECT * FRÅN 'inlägg' LIMIT 10 OFFSET 5 MongoDB: db.posts.find () .gräns (10) .skip (5)
Den första parametern till uppdatering Metod anger kriterierna för att välja dokumenten. Den andra parametern specificerar den faktiska uppdateringsoperationen som ska utföras. Till exempel väljer följande fråga alla dokument med Användarnamn som markera och sätter deras post_privacy som privat.
En skillnad här är det som standard, MongoDB uppdatering Fråga uppdateringar endast ett (och det första matchade) dokumentet. För att uppdatera alla matchande dokument måste vi tillhandahålla en tredje parameter som specificerar mång som Sann vilket indikerar att vi vill uppdatera flera dokument.
SQL: UPDATE inlägg SET post_privacy = "privat" VAR användarnamn = "markera" MongoDB: db.posts.update (user_name: "mark", $ set: post_privacy: "private", multi: true )
Att ta bort dokument är ganska enkelt och liknar SQL.
SQL: DELETE FROM inlägg VAR användarnamn = "markera" MongoDB: db.posts.remove (user_name: "mark")
MongoDB har ett standardindex skapat på _id fält för varje samling. För att skapa nya index på fälten använder vi ensureIndex metod som anger fälten och tillhörande sorteringsordning som anges av 1 eller -1(stigande eller nedåtgående).
SQL: CREATE INDEX index_posts PÅ inlägg (användarnamn, post_likes_count DESC) MongoDB: db.posts.ensureIndex (användarnamn: 1, post_likes_count: -1)
För att se alla index som finns i någon samling använder vi getIndexes metod på samma sätt som VIS INDEX fråga om SQL.
SQL: VIS INDEX från inlägg MongoDB: db.posts.getIndexes ()
I den här artikeln förstod vi hur de grundläggande begreppen och termerna för RDBMS / SQL är relaterade till MongoDB. Vi tittade på att utforma relationer i MongoDB och lärde oss hur funktionaliteten för grundläggande SQL-frågor kartlägger i MongoDB.
Efter att ha tagit en början med den här artikeln kan du fortsätta pröva komplexa frågor, inklusive aggregering, kortminskning och frågor som rör flera samlingar. Du kan också ta hjälp av några onlineverktyg för att konvertera SQL-frågor till MongoDB-frågor i början. Du kan spela på egen hand ett MongoDB-databasschema. Ett av de bästa exemplen på att göra det skulle vara en databas för att lagra användarinlägg, deras kommentarer, kommentarer och kommentarer. Detta skulle ge dig en praktisk bild av den flexibla schemankonstruktionen som MongoDB erbjuder.
Gärna kommentera några förslag, frågor eller idéer som du vill se vidare.
