Een NoSQL-database is elke soort database die afwijkt van het traditionele ontwerp van SQL. NoSQL-databases zoals de op documenten gebaseerde MongoDB zijn de afgelopen jaren populairder geworden. Waar gaat de hype over?
De beperking van SQL: schaalbaarheid
SQL bestaat altijd al— 45 jaar. Het houdt verrassend goed stand en moderne implementaties van SQL zijn erg snel. Maar naarmate het web is gegroeid, is er ook behoefte aan krachtige databases die kunnen worden opgeschaald om aan de vraag te voldoen.
De eenvoudigste manier om een SQL-database te schalen, is door deze op een krachtigere computer uit te voeren. SQL-databases kunnen worden gerepliceerd om de regionale belasting van een afzonderlijke instantie te verminderen, maar het opsplitsen van een tabel (vaak sharding genoemd) is veel moeilijker voor SQL.
Documentgebaseerde NoSQL-databases lossen dit probleem door ontwerp op. Elk document is onafhankelijk van andere documenten in de collectie, waardoor de collecties veel gemakkelijker over meerdere servers kunnen worden verdeeld. Veel documentdatabases bevatten ingebouwde tools voor het sharden van de gegevens over verschillende servers.
Maar het schaalbaarheidsprobleem is pas echt een probleem als u veel gegevens heeft. U kunt eenvoudig een SQL-database uitvoeren met honderdduizenden gebruikers en geen problemen hebben, ervan uitgaande dat uw structuur goed is en uw zoekopdrachten snel zijn.
Advertentie
Zowel MySQL als MongoDB zullen waarschijnlijk de klus klaren voor uw toepassing, dus de keuze tussen de twee komt neer op welke structuur en syntaxis u verkiest. Gemak van ontwikkeling is belangrijk, en u zult merken dat het documentmodel en de syntaxis van de veel nieuwere MongoDB gemakkelijker is om mee te werken dan SQL.
NoSQL vs. SQL-structuur
Traditionele SQL-databases worden vaak relationele databases genoemd vanwege de manier waarop ze zijn gestructureerd. In een SQL-database heb je meerdere tabellen, elk met meerdere rijen (records genoemd), die zelf meerdere verschillende kolommen of attributen hebben. Elke afzonderlijke tabel is aan de andere gekoppeld via een primaire sleutel, die een relatie vormt.
Stel je bijvoorbeeld voor dat je een tabel hebt waarin elke record een bericht van een gebruiker vertegenwoordigt. De primaire sleutel hier is de gebruikersnaam, die kan worden gebruikt om de berichtentabel te koppelen aan de gebruikerstabel. Als je de e-mail wilt vinden van degene die het bericht heeft geplaatst, voer je een zoekopdracht uit naar “Jon1996” in de gebruikerstabel en selecteer de “E-mail” veld.
Maar deze gegevensstructuur werkt mogelijk niet voor iedereen . SQL-databases hebben een strak gedefinieerd schema, wat in de weg kan staan als u wijzigingen moet aanbrengen of gewoon een andere lay-out wilt hebben. Met complexe datasets kunnen de relaties tussen alles ingewikkelder worden dan de data zelf.
Het belangrijkste type NoSQL-database is een JSON-documentdatabase, zoals MongoDB. In plaats van rijen en kolommen op te slaan, worden alle gegevens opgeslagen in afzonderlijke documenten. Deze documenten worden opgeslagen in verzamelingen (een 'gebruikersdocument' wordt bijvoorbeeld opgeslagen in een verzameling 'alle gebruikers') en hoeven niet dezelfde structuur te hebben als andere documenten in de collectie.
Bijvoorbeeld een “gebruiker” document kan er ongeveer zo uitzien:
{ “username”:”Jon1996″, “email”:”jon1996@gmail.com”, “posts”: [ {“id”:1}, {“id”:2}, {“id”:3}, ] } Advertentie
De gebruikersnaam- en e-mailvelden zijn slechts sleutel-waardeparen, vergelijkbaar met kolommen in SQL, maar de “posts” veld bevat een array, wat u niet in SQL-databases zult vinden. Stel nu dat we een verzameling berichten hadden met documenten als:
{ “id”:1, “title”:”First Post”, “content”:”Hallo wereld!”, “madeby”:”Jon1996″ }
Nu, wanneer iemand Jon's pagina bezoekt, kan uw toepassing drie berichten ophalen met de ID's van 1, 2 en 3, wat meestal een snelle zoekopdracht is. Vergeleken met SQL, waar je mogelijk alle berichten moet ophalen die overeenkomen met Jon’s gebruikers-ID. Nog steeds vrij snel, maar de MongoDB-query is directer en logischer.
Waar zijn NoSQL-databases goed voor?
NoSQL is een brede categorie en omvat veel verschillende soorten databases die met verschillende doelen zijn gebouwd. Elke database is een hulpmiddel en voor uw werk kan een specifiek soort hulpmiddel nodig zijn, of zelfs meerdere verschillende hulpmiddelen.
SQL-databases zoals MySQL, Oracle en PostgreSQL bestaan al sinds die tijd. vóór het internet. Ze zijn erg stabiel, hebben veel steun en kunnen over het algemeen het werk voor de meeste mensen doen. Als uw gegevens waardevol voor u zijn en u een gevestigde, consistente oplossing wilt, blijf dan bij SQL.
JSON-documentdatabases, zoals MongoDB en Couchbase, zijn populair voor webapplicaties met veranderende datamodellen en voor het opslaan van complexe documenten. Een site als Amazon moet bijvoorbeeld vaak het gegevensmodel wijzigen voor het opslaan van producten op de site, dus een op documenten gebaseerde database kan goed voor hen werken.
Documentdatabases zijn bedoeld als generieke vervanging voor SQL, en daar denk je waarschijnlijk aan als je “NoSQL.” Ze zijn ook intuïtiever om te leren dan SQL, omdat u geen relaties tussen tabellen of complexe zoekopdrachten hoeft te beheren.
Advertentie
RethinkDBis een JSON-documentdatabase die is gebouwd voor realtime toepassingen. In een database als MongoDB zou je om de paar seconden moeten peilen naar updates, of daarbovenop een API implementeren om realtime updates bij te houden, wat snel zwaar wordt. RethinkDB lost dit probleem op door updates automatisch te pushen via websocket-streams waarmee clients verbinding kunnen maken.
Redisis een uiterst performante key-value-database die kleine sleutels en strings volledig in RAM opslaat, wat veel sneller is om naar te lezen en te schrijven dan zelfs de snelste SSD's. Het wordt vaak samen met andere databases gebruikt als een in-memory cache voor kleine gegevens waarnaar vaak wordt geschreven en gelezen. Een berichten-app wil bijvoorbeeld Redis gebruiken om berichten van gebruikers op te slaan (en zelfs updates in realtime te pushen met hun Pub/Sub-methoden). Het op deze manier opslaan van veel kleine berichten kan prestatieproblemen veroorzaken bij andere typen databases.
Grafische databaseszijn gebouwd voor het opslaan van verbindingen tussen gegevens. Een veelvoorkomend gebruik zijn sociale netwerken, waar gebruikers met elkaar verbonden zijn en interactie hebben met andere gegevens, zoals berichten die ze hebben geplaatst.
In dit voorbeeld is George bevriend met twee mensen, Jon en Jane. Als een ander soort database de connectie van George met Sarah wilde begrijpen, zouden ze alle vrienden van Jon en alle vrienden van Jane moeten ondervragen. Maar grafiekendatabases begrijpen deze verbinding intuïtief; voor de vrienden van vrienden-query is de populaire grafiekdatabase Neo4J 60% sneller dan MySQL. Voor vrienden van vrienden van vrienden (3 niveaus diep) is Neo4J 180 keer sneller.
Brede kolomdatabases zoals Cassandra en Hbase, worden gebruikt voor het opslaan van enorme hoeveelheden gegevens. Ze zijn gebouwd voor datasets die zo groot zijn dat je meerdere computers nodig hebt om alles op te slaan, en ze zijn veel sneller dan SQL en andere NoSQL-databases wanneer ze over meerdere knooppunten zijn verspreid.