Een database zonder integriteit
Wanneer men een grote hoeveelheden gegevens heeft is het niet handig om dit op te slaan in een RDBMS. Vooral als performance belangrijk is; in een RDBMS zitten namelijk koppelingen die voor integriteit zorgen. Men kan bijvoorbeeld denken aan “JOIN” operaties wat in een database engine verwerkt is. Bij noSQL is dit geheel achterwege gelaten.
Horizontaal schalen
Tevens biedt noSQL het voordeel dat er horizontaal geschaald kan worden – wat betekent dat de load gesplitst kan worden tussen diverse servers. Bij een RDBMS kan men alleen verticaal schalen – wat inhoud dat er meer resources in een server geplaatst moet worden om snelheid te vergroten. Wanneer er bij een RDBMS database de resources vergroot moet worden kan dit veel geld kosten. (Denk maar aan een duurdere CPU, meer RAM etc).
Geen Joins
Als er gebruik gemaakt wordt van noSQL dan is meestal de gedachtegang om gegevens op te slaan in een database wat geen koppelingen vereist. Men kan dit zien als een container waarin alle data verwerkt wordt. Deze container heeft geen koppelingen zoals WHERE , INNER JOIN etc nodig; alleen een algemene plek waar de data opgeslagen is. De data kan weer snel opgehaald worden omdat het relationele hieruit is gehaald.
Twitter overgestapt op noSQL
Twitter maakt ook gebruik van een noSQL oplossing. Hiervoor maakte ze gebruik van mySQL maar dit was niet efficient genoeg. Ze besloten een overstap te maken om alle tweets op te slaan in een noSQL database. De tweets verouderen namelijk snel en moet altijd gearchiveerd blijven. Dankzij noSQL kan er horizontaal geschaald worden; dit betekent wanneer er meer resources nodig zijn extra servers geplaatst kunnen worden. Er bestaat dan de mogelijkheid om deze aan elkaar te koppelen.
noSQL en intregiteit
noSQL heeft geen integriteitcheck net zoals innoDB, daar is het namelijk niet voor gebouwd. Het idee van noSQL is om data op te slaan in een algemene container en dit snel te verkrijgen ; zonder relaties. Als je ziet dat consistency en integriteit heel erg belangrijk zijn, zul je toch weer uitkomen bij een relationele database, daarom is het belangrijk waarvoor men noSQL nou daadwerkelijk moet gebruiken.
Hoe communiceert noSQL met applicaties?
noSQL communiceert via webservices met een webapplicatie. Een webservice is een service die wordt aangeboden via het internet. Verschillende systemen kunnen dan gebruik maken van de data of de functionaliteit van de desbetreffende
Hierdoor is het mogelijk dat een applicatie verschillende functionaliteiten en/of gegevens aanroept van externe systemen (systemen die heel anders geprogrammeerd zijn). De kracht van webservices zit hem erin dat de systemen loosly coupled zijn – dit betekent dat ze zeer weinig van elkaar hoeven ‘te weten’ om gebruik te maken van elkaars functionaliteit.
Door middel van REST en JSON kan er gecommuniceerd worden met de noSQL database. Bij de meeste noSQL database engines wordt er gebruik gemaakt van een schema, dit is verwerkt in een XML bestand op de server. In de schema kan men instellen hoe men kan communcieren met de database en op welke velden de webservice mag communcieren. In de praktijk zijn er diverse noSQL engines zoals Cassandra, Mongo etc. Alhoewel de meeste engines anders werken is de basis hetzelfde namelijk; communicatie door middel van een webservice.
Opslagmethodes noSQL
noSQL maakt gebruik van diverse opslag methodes. Bij normale RDBMS systemen zijn we gewent dat alles in een tabel opgeslagen wordt; bij een noSQL engine kan dit wel eens verschillen. Ik zal hier de verschillende opslag methodes opnoemen.
Document
Er zijn een aantal engines die noSQL database document georiënteerd opslaan. Een document georiënteerde manier van opslaan wilt zeggen dat de data gecodeerd wordt naar YAML,XML en JSON. Document georiënteerde databases zijn flexibel; dat wilt zeggen dat de veldnaam dynamisch kan zijn. In elke entry kunnen verschillende soorten informatie worden opgeslagen, zonder dat de tabelstructuur hoeft te worden gewijzigd.
Yup, Mongodb is cool. Maar wij hebben veel hoofdpijn gehad met deze noSQL engine. De server HDD loopt zo over…
Graaf
Een Graaf database maakt gebruik van een graaf om data te tonen en te verwerken. Deze methode is gebruikt vanuit de wiskunde (de graaf theorie)
Een graaf bestaat uit een verzameling punten, knopen genoemd, waarvan sommige verbonden zijn door lijnen, de zijden, kanten of takken. Afhankelijk van de toepassing kunnen de lijnen gericht zijn, dan worden ze ook wel pijlen genoemd, men spreekt dan van een gerichte graaf (of digraaf)..
In vergelijking met relationele database zijn graaf databases sneller, ze kunnen snel naar een bepaalde node verwijzen in de graaf. Een relationele database zou hiervoor een uitgebreide JOIN operatie moeten uitvoeren. Graaf database zijn ook sneller omdat er snel het kortste pad berekend kan worden.
Key-Value
Key-value-opslag is vooral geschikt voor gegevens die heel vaak moeten worden uitgelezen. Het idee van de key value is hetzelfde als een Hashmap.
De werking van een hashtabel berust op een hashfunctie die de sleutel omzet in een hashwaarde die gebruikt wordt om de (sleutel,waarde)-combinatie efficiënt te vinden. Gemiddeld genomen levert een hashtabel de gezochte waarde in een constante tijd, O(1), net zoals voor een normale array maar in uitzonderlijke gevallen kan de tijd evenredig zijn met het aantal elementen in de hashtabel O(n). Door de tijd die benodigd is voor het berekenen van de hashwaarde en het uiteindelijk vinden van de combinatie is een hashtabel het meest geschikt voor gevallen waarbij een groot aantal combinaties worden gebruikt.