Wat is NoSQL? Databases voor een toekomst op cloudschaal

Een van de meest fundamentele keuzes die u moet maken bij het ontwikkelen van een applicatie, is of u een SQL- of NoSQL-database wilt gebruiken om de gegevens op te slaan. Conventionele SQL (dwz relationele) databases zijn het product van decennia van technologische evolutie, goede praktijken en real-world stresstests. Ze zijn ontworpen voor betrouwbare transacties en ad-hocvragen, de hoofdbestanddelen van branchetoepassingen. Maar ze worden ook belast met beperkingen, zoals een rigide schema, waardoor ze minder geschikt zijn voor andere soorten apps.

NoSQL-databases zijn ontstaan ​​als reactie op die beperkingen. NoSQL-systemen slaan gegevens op en beheren deze op manieren die een hoge operationele snelheid en grote flexibiliteit van de kant van de ontwikkelaars mogelijk maken. Velen zijn ontwikkeld door bedrijven als Google, Amazon, Yahoo en Facebook die betere manieren zochten om inhoud op te slaan of gegevens te verwerken voor enorme websites. In tegenstelling tot SQL-databases, kunnen veel NoSQL-databases horizontaal worden geschaald over honderden of duizenden servers.

De voordelen van NoSQL komen echter niet zonder kosten. NoSQL-systemen bieden over het algemeen niet hetzelfde niveau van gegevensconsistentie als SQL-databases. In feite, terwijl SQL-databases traditioneel de prestaties en schaalbaarheid hebben opgeofferd voor de ACID-eigenschappen achter betrouwbare transacties, hebben NoSQL-databases die ACID-garanties voor snelheid en schaalbaarheid grotendeels verlaten.

Kortom, SQL- en NoSQL-databases bieden verschillende afwegingen. Hoewel ze kunnen concurreren in de context van een specifiek project - zoals in welke ze moeten kiezen voor deze applicatie of die applicatie - zijn ze complementair in het grotere geheel. Elk is geschikt voor verschillende gebruikssituaties. De beslissing is niet zozeer een kwestie van of / of als het gaat om de vraag welke tool geschikt is voor de klus.

NoSQL versus SQL

Het fundamentele verschil tussen SQL en NoSQL is niet zo ingewikkeld. Elk heeft een andere filosofie over hoe gegevens moeten worden opgeslagen en opgehaald.

Met SQL-databases hebben alle gegevens een inherente structuur. Een conventionele database zoals Microsoft SQL Server, MySQL of Oracle Database gebruikt een schema - een formele definitie van hoe gegevens die in de database worden ingevoegd, worden samengesteld. Een bepaalde kolom in een tabel kan bijvoorbeeld beperkt zijn tot alleen gehele getallen. Als gevolg hiervan zullen de gegevens die in de kolom zijn geregistreerd een hoge mate van normalisatie hebben. Het rigide schema van een SQL-database maakt het ook relatief eenvoudig om aggregaties op de gegevens uit te voeren, bijvoorbeeld via JOIN's.

Met NoSQL kunnen gegevens worden opgeslagen in een schemaloze of vrije vorm. Alle gegevens kunnen in elk record worden opgeslagen. Onder de NoSQL-databases vindt u vier veelgebruikte modellen voor het opslaan van gegevens, die leiden tot vier veelvoorkomende typen NoSQL-systemen:

  1. Documentdatabases (bijv. CouchDB, MongoDB). Ingevoegde gegevens worden opgeslagen in de vorm van vrije JSON-structuren of "documenten", waarbij de gegevens van alles kunnen zijn, van gehele getallen tot strings tot vrije tekst. Het is niet inherent nodig om te specificeren welke velden, indien aanwezig, een document zal bevatten.
  2. Sleutelwaarde-winkels (bijv. Redis, Riak). Vrije waarden - van eenvoudige gehele getallen of strings tot complexe JSON-documenten - worden in de database benaderd door middel van sleutels.
  3. Opslag met brede kolommen (bijv. HBase, Cassandra). Gegevens worden opgeslagen in kolommen in plaats van rijen zoals in een conventioneel SQL-systeem. Elk aantal kolommen (en dus veel verschillende soorten gegevens) kan naar behoefte worden gegroepeerd of geaggregeerd voor query's of gegevensweergaven.
  4. Grafische databases (bijv. Neo4j). Gegevens worden weergegeven als een netwerk of grafiek van entiteiten en hun relaties, waarbij elk knooppunt in de grafiek een vrije vorm van gegevens is.

Gegevensopslag zonder schema is handig in de volgende scenario's:

  1. U wilt snelle toegang tot de gegevens en u maakt zich meer zorgen over snelheid en eenvoud van toegang dan over betrouwbare transacties of consistentie.
  2. U slaat een grote hoeveelheid gegevens op en u wilt uzelf niet in een schema opsluiten, aangezien het later veranderen van het schema traag en pijnlijk kan zijn.
  3. U neemt ongestructureerde gegevens op uit een of meer bronnen die deze produceren, en u wilt de gegevens in hun oorspronkelijke vorm behouden voor maximale flexibiliteit.
  4. U wilt gegevens in een hiërarchische structuur opslaan, maar u wilt dat die hiërarchieën worden beschreven door de gegevens zelf, niet door een extern schema. Met NoSQL kunnen gegevens terloops naar zichzelf verwijzen op manieren die complexer zijn voor SQL-databases om te emuleren.

NoSQL-databases opvragen

De Structured Query Language die door traditionele databases wordt gebruikt, biedt een uniforme manier om met de server te communiceren bij het opslaan en ophalen van gegevens. SQL-syntaxis is sterk gestandaardiseerd, dus hoewel individuele databases bepaalde bewerkingen anders kunnen behandelen (bijv. Vensterfuncties), blijft de basis hetzelfde.

Daarentegen heeft elke NoSQL-database de neiging om zijn eigen syntaxis te hebben voor het opvragen en beheren van de gegevens. CouchDB gebruikt bijvoorbeeld verzoeken in de vorm van JSON, verzonden via HTTP, om documenten aan te maken of op te halen uit zijn database. MongoDB verzendt JSON-objecten via een binair protocol, via een opdrachtregelinterface of een taalbibliotheek.

Sommige NoSQL-producten kunnen SQL-achtige syntaxis gebruiken om met gegevens te werken, maar slechts in beperkte mate. Apache Cassandra, een column store-database, heeft bijvoorbeeld zijn eigen SQL-achtige taal, de Cassandra Query Language of CQL. Een deel van de CQL-syntaxis komt rechtstreeks uit het SQL-playbook, zoals de trefwoorden SELECT of INSERT. Maar er is geen manier om een ​​JOIN of subquery uit te voeren in Cassandra, en daarom bestaan ​​de gerelateerde trefwoorden niet in CQL.

Shared-nothing-architectuur

Een ontwerpkeuze die veel voorkomt bij NoSQL-systemen is een "niets-gedeelde" -architectuur. In een shared-nothing-ontwerp werkt elk serverknooppunt in het cluster onafhankelijk van elk ander knooppunt. Het systeem hoeft niet van elk afzonderlijk knooppunt consensus te krijgen om een ​​stukje gegevens naar een client te retourneren. Query's zijn snel omdat ze kunnen worden geretourneerd vanaf het knooppunt dat het dichtst in de buurt is of het handigst is.

Een ander voordeel van shared-nothing is veerkracht en schaalvergroting. Het opschalen van het cluster is net zo eenvoudig als het opstarten van nieuwe knooppunten in het cluster en wachten tot ze zijn gesynchroniseerd met de andere. Als een NoSQL-knooppunt uitvalt, blijven de andere servers in het cluster meesleuren. Alle gegevens blijven beschikbaar, zelfs als er minder knooppunten beschikbaar zijn om verzoeken te behandelen.

Merk op dat een shared-nothing-ontwerp niet exclusief is voor NoSQL-databases. Veel conventionele SQL-systemen kunnen op een 'shared-nothing'-manier worden opgezet, hoewel dat doorgaans inhoudt dat de consistentie binnen het cluster moet worden opgeofferd voor prestaties.

NoSQL-beperkingen

Als NoSQL zoveel vrijheid en flexibiliteit biedt, waarom zou u SQL dan niet helemaal verlaten? Het simpele antwoord: veel toepassingen vragen nog steeds om de soorten beperkingen, consistentie en waarborgen die SQL-databases bieden. In die gevallen kunnen sommige "voordelen" van NoSQL in nadelen veranderen. Andere beperkingen vloeien voort uit het feit dat NoSQL-systemen relatief nieuw zijn. 

Geen schema

Zelfs als u vrije gegevens opneemt, moet u er bijna altijd beperkingen aan opleggen om ze bruikbaar te maken. Bij NoSQL houdt het opleggen van beperkingen het verschuiven van de verantwoordelijkheid in van de database naar de applicatieontwikkelaar. De ontwikkelaar zou bijvoorbeeld structuur kunnen opleggen via een object-relationeel mapping-systeem, of ORM. Maar als u wilt dat het schema met de gegevens zelf samenleeft, doet NoSQL dat doorgaans niet.

Sommige NoSQL-oplossingen bieden optionele mechanismen voor het typen van gegevens en validatie van gegevens. Apache Cassandra heeft bijvoorbeeld een hele reeks native gegevenstypen die doen denken aan die in conventionele SQL.

Eventuele consistentie

NoSQL-systemen verhandelen sterke of onmiddellijke consistentie voor betere beschikbaarheid en prestaties. Conventionele databases zorgen ervoor dat de bewerkingen atomair zijn (alle delen van een transactie slagen of niet), consistent (alle gebruikers hebben dezelfde weergave van de gegevens), geïsoleerd (transacties concurreren niet) en duurzaam (zodra ze zijn voltooid, zullen ze overleven) een serverfout).

Deze vier eigenschappen, gezamenlijk ACID genoemd, worden in de meeste NoSQL-systemen anders behandeld. In plaats van onmiddellijke consistentie binnen het cluster, heb je uiteindelijke consistentie, vanwege de tijd die nodig is om updates naar andere knooppunten in het cluster te kopiëren. Gegevens die in het cluster worden ingevoegd, zijn uiteindelijk overal beschikbaar, maar u kunt niet garanderen wanneer.

Transactiesemantiek, die in een SQL-systeem garandeert dat alle stappen in een transactie (bijv. Het uitvoeren van een verkoop en het verkleinen van de voorraad) worden voltooid of teruggedraaid, zijn doorgaans niet beschikbaar in NoSQL. Voor elk systeem waar er een "enkele bron van waarheid" moet zijn, zoals een bank, zal de NoSQL-benadering niet goed werken. U wilt niet dat uw banksaldo anders is, afhankelijk van naar welke geldautomaat u gaat; u wilt dat het overal als hetzelfde wordt gerapporteerd.

Sommige NoSQL-databases hebben gedeeltelijke mechanismen om dit te omzeilen. MongoDB heeft bijvoorbeeld consistentiegaranties voor individuele bewerkingen, maar niet voor de database als geheel. Met Microsoft Azure CosmosDB kunt u een niveau van consistentie per verzoek selecteren, zodat u het gedrag kunt kiezen dat bij uw gebruikssituatie past. Maar verwacht met NoSQL de uiteindelijke consistentie als het standaardgedrag.

NoSQL-vergrendeling

De meeste NoSQL-systemen lijken conceptueel op elkaar, maar worden heel anders geïmplementeerd . Elk heeft de neiging om zijn eigen metaforen en mechanismen te hebben voor de manier waarop gegevens worden opgevraagd en beheerd.

Een neveneffect daarvan is een potentieel hoge mate van koppeling tussen de applicatielogica en de database. Dit is niet zo erg als je een NoSQL-systeem kiest en je eraan houdt, maar het kan een struikelblok worden als je later van systeem verandert.

Als u migreert van bijvoorbeeld MongoDB naar CouchDB (of vice versa), moet u meer doen dan alleen gegevens migreren. U moet ook navigeren door de verschillen in gegevenstoegang en programmatische metaforen - met andere woorden, u moet de delen van uw toepassing die toegang hebben tot de database, herschrijven.

NoSQL-vaardigheden

Een ander nadeel van NoSQL is het relatieve gebrek aan expertise. Waar de markt voor conventioneel SQL-talent nog vrij groot is, is de markt voor NoSQL-skills in opkomst.

Ter referentie: Indeed.com meldt dat vanaf eind 2017 het aantal vacatures voor conventionele SQL-databases - MySQL, Microsoft SQL Server, Oracle Database, enzovoort - de afgelopen drie jaar hoger is dan het aantal vacatures voor MongoDB, Couchbase en Cassandra. De vraag naar NoSQL-expertise groeit, maar het is nog steeds een fractie van de markt voor conventionele SQL.

SQL en NoSQL samenvoegen

We kunnen verwachten dat enkele verschillen tussen SQL- en NoSQL-systemen na verloop van tijd zullen verdwijnen. Veel SQL-databases accepteren nu al JSON-documenten als een native gegevenstype en kunnen query's uitvoeren op die gegevens. Sommige hebben zelfs native manieren om beperkingen op te leggen aan JSON-gegevens, zodat deze met dezelfde nauwkeurigheid worden afgehandeld als conventionele rij-en-kolomgegevens.

Aan de andere kant voegen NoSQL-databases niet alleen SQL-achtige zoektalen toe, maar ook andere mogelijkheden van traditionele SQL-databases. Zo beloven ten minste twee documentdatabases - MarkLogic en RavenDB - ACID-compatibel te zijn.

Hier en daar zijn tekenen dat toekomstige generaties databases de paradigma's zullen overschrijden en zowel NoSQL- als SQL-functionaliteit zullen bieden. Microsoft's Azure Cosmos DB gebruikt bijvoorbeeld een reeks primitieven onder de motorkap om het gedrag van beide soorten systemen onderling uitwisselbaar te reproduceren. Google Cloud Spanner is een SQL-database die een sterke consistentie combineert met de horizontale schaalbaarheid van NoSQL-systemen.

Toch zullen pure SQL en pure NoSQL-systemen nog vele jaren hun plaats hebben. Gebruik NoSQL voor snelle, zeer schaalbare toegang tot vrije gegevens. Dit brengt een paar kosten met zich mee, zoals de consistentie van leesbewerkingen en andere voorzorgsmaatregelen die gemeenschappelijk zijn voor SQL-databases. Maar voor veel toepassingen kunnen die waarborgen de moeite waard zijn om te ruilen voor wat NoSQL biedt.