En NoSQL -databas är någon form av databas som bryter sig bort från den traditionella designen av SQL. NoSQL-databaser som den dokumentbaserade MongoDB har blivit mer populära de senaste åren. Vad handlar all hype om?
Begränsningen av SQL: Skalbarhet
SQL har funnits för alltid — 45 år. Det håller förvånansvärt bra, och moderna implementeringar av SQL är mycket snabba. Men i takt med att webben har vuxit så har behovet av kraftfulla databaser som kan skala upp för att möta efterfrågan ökat.
Det enklaste sättet att skala en SQL -databas är att köra den på en mer kraftfull dator. SQL -databaser kan replikeras för att minska regional belastning på en enskild instans, men att dela upp en tabell (ofta kallad sharding) är mycket svårare för SQL.
Dokumentbaserade NoSQL-databaser löser detta problem genom design. Varje dokument är oberoende av andra dokument i samlingen, så samlingarna kan delas upp på flera servrar mycket enklare. Många dokumentdatabaser innehåller inbyggda verktyg för att dela data över olika servrar.
Men skalbarhetsproblemet är inte ett problem förrän du har mycket data. Du kan enkelt köra en SQL -databas med hundratusentals användare och har inga problem, förutsatt att din struktur är sund och dina frågor är snabba.
Annonsering
Både MySQL och MongoDB kommer sannolikt att få jobbet gjort för din applikation, så valet mellan de två beror på vilken struktur och syntax du föredrar. Lätt att utveckla är viktigt, och du kan tycka att dokumentmodellen och syntaxen för den mycket nyare MongoDB är lättare att arbeta med än SQL.
NoSQL vs . SQL -struktur
Traditionella SQL -databaser kallas ofta relationsdatabaser på grund av hur de är uppbyggda. I en SQL -databas har du flera tabeller, var och en innehållande flera rader (kallade poster), som själva har flera olika kolumner eller attribut. Varje separat tabell är länkad till den andra genom en primärnyckel, som bildar en relation.
Tänk dig till exempel att du har en tabell med varje post som representerar ett inlägg från en användare. Den primära nyckeln här är användarnamnet, som kan användas för att länka inläggstabellen till användartabellen. Om du ville hitta e -postmeddelandet till den som gjorde inlägget skulle du söka efter “ Jon1996 ” i användartabellen och välj “ E -post ” fält.
Men den här datastrukturen kanske inte fungerar för alla . SQL -databaser har ett starkt definierat schema som kan komma i vägen om du behöver göra ändringar eller bara föredrar att ha en annan layout. Med komplexa datamängder kan relationerna mellan allt bli mer komplicerade än själva data.
Den huvudsakliga typen av NoSQL -databas är en JSON -dokumentdatabas, som MongoDB. Istället för att lagra rader och kolumner lagras all data i enskilda dokument. Dessa dokument lagras i samlingar (t.ex. ett “ användar ” dokument skulle lagras i en “ alla användares samling) och behöver inte ha samma struktur som andra dokument i samlingen.
Till exempel en “ användare ” dokument kan se ut ungefär så här:
{“användarnamn”: “Jon1996”, “email”: “jon1996@gmail.com”, “posts”: [{“id”: 1}, {“id”: 2}, {“id”: 3}, ]} Annons
Användarnamn och e-postfält är bara nyckel-värdepar, liknande kolumner i SQL, men “ inläggen ” fältet innehåller en matris, vilket inte är något du hittar i SQL -databaser. Säg nu att vi hade en inläggssamling med dokument som:
{“id”: 1, “title”: “First Post”, “content”: “Hello, World!”, “Madeby”: “Jon1996”}
När någon nu besöker Jon's sida kan din ansökan hämta tre inlägg med ID: n 1, 2 och 3, vilket vanligtvis är en snabb fråga. Jämfört med SQL, där du kan behöva hämta alla inlägg som matchar Jon's användar -ID. Fortfarande ganska snabbt, men MongoDB-frågan är mer direkt och mer vettig.
Vad är NoSQL-databaser bra för?
NoSQL är en bred kategori och innehåller många olika typer av databaser byggda med olika mål. Varje databas är ett verktyg, och ditt jobb kan kräva en specifik typ av verktyg, eller till och med flera olika verktyg.
SQL -databaser som MySQL, Oracle och PostgreSQL har funnits sedan dess före internet. De är mycket stabila, har mycket stöd och kan i allmänhet göra jobbet för de flesta. Om din data är värdefull för dig och du vill ha en etablerad och konsekvent lösning, håll dig till SQL.
JSON -dokumentdatabaser , som MongoDB och Couchbase, är populära för webbapplikationer med ändrade datamodeller och för lagring av komplexa dokument. Till exempel kan en webbplats som Amazon ofta behöva ändra datamodellen för lagring av produkter på webbplatsen, så en dokumentbaserad databas kan fungera bra för dem.
Dokumentdatabaser är avsedda att vara en generisk ersättning för SQL, och är förmodligen det du tänker på när du hör “ NoSQL. ” De är också mer intuitiva att lära sig än SQL, eftersom du inte kommer att behöva hantera relationer mellan tabeller eller komplexa frågor.
Annonsering
RethinkDB är en JSON -databas för realtidsapplikationer. I en databas som MongoDB behöver du hämta uppdateringar med några sekunders mellanrum eller implementera något API för att spåra uppdateringar i realtid, vilket blir tungt snabbt. RethinkDB löser det här problemet genom att automatiskt skicka uppdateringar över websocket -strömmar som klienter kan ansluta till.
Redis är en extremt effektiv nyckelvärdesdatabas som lagrar små nycklar och strängar helt i RAM, vilket är mycket snabbare att läsa och skriva till än till och med de snabbaste SSD: erna. Den används ofta tillsammans med andra databaser som en cache i minnet för små data som skrivs till och läses från ofta. Till exempel kan en meddelande -app använda Redis för att lagra användarens meddelanden (och till och med skicka uppdateringar i realtid med sina Pub/Sub -metoder). Att lagra många små meddelanden på det här sättet kan orsaka prestandaproblem med andra typer av databaser.
Grafdatabaser är byggda för att lagra anslutningar mellan data. Ett vanligt förekommande fall är sociala nätverk, där användare är anslutna till varandra och interagerar med annan data, till exempel inlägg de har gjort.
I det här exemplet är George vänner med två personer, Jon och Jane. Om en annan typ av databas ville förstå Georges koppling till Sarah, skulle de behöva fråga alla Jon's vänner och alla Jane's vänner. Men grafdatabaser förstår denna anslutning intuitivt; för vänernas vänner -fråga är den populära grafdatabasen Neo4J 60% snabbare än MySQL. För vänner till vänner till vänner (3 nivåer djupt) är Neo4J 180 gånger snabbare.
Wide column -databaser som Cassandra och Hbase, används för lagring av massiva mängder data. De är byggda för datamängder som är så stora att du behöver flera datorer för att lagra allt, och de är mycket snabbare än SQL och andra NoSQL -databaser när de sprids över flera noder.