Ik zie veel verwarring over de plaats en het doel van de vele nieuwe database-oplossingen (“NoSQL-databases”) in vergelijking met de relationele databases-oplossingen die al vele jaren bestaan. Laat me daarom proberen de verschillen en de beste use-cases voor elk uit te leggen.
Laten we eerst deze database-oplossingen in twee groepen verdelen:
1) Relationele databases, die ook wel relationele database management systemen (RDBMS) of SQL-databases kunnen worden genoemd. De populairste hiervan zijn Microsoft SQL Server, Oracle Database, MySQL en IBM DB2. Deze RDBMS’en worden meestal gebruikt in grote bedrijfsscenario’s, met uitzondering van MySQL, dat meestal wordt gebruikt om gegevens op te slaan voor webapplicaties, meestal als onderdeel van de populaire LAMP-stack (Linux, Apache, MySQL, PHP/Python/Perl).
2) Niet-relationele databases, ook wel NoSQL-databases genoemd, waarvan de populairste MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis en Neo4j zijn. Deze databases worden meestal ingedeeld in vier categorieën: Key-value stores, Graph stores, Column stores, en Document stores (zie Soorten NoSQL databases).
Alle relationele databases kunnen worden gebruikt om transactiegeoriënteerde toepassingen (OLTP) te beheren, en de meeste niet-relationele databases die in de categorieën Document stores en Column stores vallen, kunnen ook worden gebruikt voor OLTP, wat de verwarring nog groter maakt. OLTP-databanken kunnen worden beschouwd als “operationele” databanken, die worden gekenmerkt door frequente, korte transacties die updates omvatten en die een kleine hoeveelheid gegevens raken en waarbij concurrency van duizenden transacties zeer belangrijk is (voorbeelden zijn banktoepassingen en online reserveringen). Integriteit van de gegevens is zeer belangrijk en daarom ondersteunen zij ACID-transacties (Atomicity, Consistency, Isolation, Durability). Dit in tegenstelling tot data warehouses, die worden beschouwd als “analytische” databases die worden gekenmerkt door lange, complexe query’s die een grote hoeveelheid gegevens raken en veel middelen vereisen. Updates zijn onregelmatig. Een voorbeeld is de analyse van de verkoop in het afgelopen jaar.
Relationele databases werken meestal met gestructureerde gegevens, terwijl niet-relationele databases meestal werken met semi-gestructureerde gegevens (d.w.z. XML, JSON).
Laten we elke groep eens nader bekijken:
Relationele Databases
Een relationele database is georganiseerd op basis van het relationele gegevensmodel, zoals voorgesteld door E.F. Codd in 1970. Dit model organiseert gegevens in een of meer tabellen (of “relaties”) van rijen en kolommen, met een unieke sleutel voor elke rij. In het algemeen heeft elk type entiteit dat in een database wordt beschreven zijn eigen tabel, waarbij de rijen instanties van dat type entiteit voorstellen en de kolommen waarden voorstellen die aan die instantie worden toegekend. Aangezien elke rij in een tabel zijn eigen unieke sleutel heeft, kunnen rijen in een tabel worden gekoppeld aan rijen in andere tabellen door de unieke sleutel op te slaan van de rij waaraan de rij moet worden gekoppeld (waarbij een dergelijke unieke sleutel bekend staat als een “foreign key”). Codd toonde aan dat gegevensrelaties van willekeurige complexiteit kunnen worden gerepresenteerd met behulp van deze eenvoudige reeks concepten.
Virtueel alle relationele databasesystemen gebruiken SQL (Structured Query Language) als de taal voor het bevragen en onderhouden van de database.
De redenen voor de dominantie van relationele databases zijn: eenvoud, robuustheid, flexibiliteit, prestaties, schaalbaarheid en compatibiliteit bij het beheer van generieke gegevens.
Maar om dit alles te bieden, moeten relationele databases intern ongelooflijk complex zijn. Een relatief eenvoudige SELECT-opdracht kan bijvoorbeeld tientallen mogelijke paden voor de uitvoering van een query hebben, die een query-optimalisator tijdens de uitvoering evalueert. Dit alles is verborgen voor gebruikers, maar onder de motorkap bepaalt het RDBMS het beste “uitvoeringsplan” om verzoeken te beantwoorden door gebruik te maken van zaken als op kosten gebaseerde algoritmen.
Voor grote databases, vooral die welke voor webapplicaties worden gebruikt, is schaalbaarheid het belangrijkste punt van zorg. Naarmate meer en meer toepassingen worden gemaakt in omgevingen met een enorme werklast (zoals Amazon), kunnen hun schaalbaarheidseisen zeer snel veranderen en zeer groot worden. Relationele databases schalen goed, maar meestal alleen wanneer dat op een enkele server gebeurt (“scale-up”). Wanneer de capaciteit van die ene server is bereikt, moet u “opschalen” en de belasting over meerdere servers verdelen, waarbij u overgaat op zogenaamde gedistribueerde gegevensverwerking. Dit is het moment waarop de complexiteit van relationele databases problemen begint op te leveren met hun schaalbaarheid. Als je probeert op te schalen naar honderden of duizenden servers, wordt de complexiteit overweldigend. De kenmerken die relationele databases zo aantrekkelijk maken, zijn precies dezelfde die ook hun levensvatbaarheid als platform voor grote gedistribueerde systemen drastisch verminderen.
Niet-relationele databases
Een NoSQL database biedt een mechanisme voor het opslaan en opvragen van gegevens dat is gemodelleerd op andere manieren dan de tabelrelaties die in relationele databases worden gebruikt.
Motivaties voor deze aanpak zijn:
- Eenvoud van ontwerp. Niet te maken hebben met de “impedantie mismatch” tussen de object-georiënteerde benadering van het schrijven van toepassingen en de schema-gebaseerde tabellen en rijen van een relationele database. Bijvoorbeeld, het opslaan van alle klantbestellingsinformatie in één document in tegenstelling tot het moeten samenvoegen van vele tabellen, wat resulteert in minder code om te schrijven, te debuggen en te onderhouden
- Betere “horizontale” schaalbaarheid naar clusters van machines, wat het probleem oplost wanneer het aantal gelijktijdige gebruikers omhoog schiet voor toepassingen die toegankelijk zijn via het web en mobiele apparaten. Het gebruik van documenten maakt het veel gemakkelijker om uit te schalen, omdat alle informatie voor die klantorder op één plaats staat in plaats van verspreid over meerdere tabellen. NoSQL databases verspreiden gegevens automatisch over servers zonder dat de applicatie hoeft te worden aangepast (auto-sharding), wat betekent dat ze van nature en automatisch gegevens verspreiden over een willekeurig aantal servers, zonder dat de applicatie zelfs maar op de hoogte hoeft te zijn van de samenstelling van de serverpool. Gegevens en query belasting worden automatisch gebalanceerd over servers, en wanneer een server uitvalt, kan deze snel en transparant worden vervangen zonder verstoring van de applicatie
- Betere controle over beschikbaarheid. Servers kunnen worden toegevoegd of verwijderd zonder applicatie downtime. De meeste NoSQL databases ondersteunen datareplicatie, waarbij meerdere kopieën van gegevens over het cluster of zelfs over datacenters worden opgeslagen, om een hoge beschikbaarheid en noodherstel te garanderen
- Om gemakkelijk alle soorten gegevens “Big Data” te kunnen vastleggen, waaronder ongestructureerde en semi-gestructureerde gegevens. Een flexibele database mogelijk te maken die gemakkelijk en snel elk nieuw type gegevens kan bevatten en niet wordt verstoord door veranderingen in de inhoudsstructuur. Dit komt doordat documentdatabases schemaloos zijn, waardoor je vrij velden kunt toevoegen aan JSON-documenten zonder eerst wijzigingen te moeten definiëren (schema-on-read in plaats van schema-on-write). Je kunt documenten hebben met een ander aantal velden dan andere documenten. Bijvoorbeeld, een patiëntendossier dat al dan niet velden kan bevatten met allergieën
- Snelheid. De datastructuren die door NoSQL databases worden gebruikt (d.w.z. JSON-documenten) verschillen van die welke standaard in relationele databases worden gebruikt, waardoor veel bewerkingen in NoSQL sneller zijn dan in relationele databases omdat tabellen niet hoeven te worden samengevoegd (ten koste van meer opslagruimte door duplicatie van gegevens – maar opslagruimte is tegenwoordig zo goedkoop dat dit meestal geen probleem is). In feite ondersteunen de meeste NoSQL databases niet eens joins
- Kosten. NoSQL databases gebruiken meestal clusters van goedkope commodity servers, terwijl RDBMS de neiging hebben om dure proprietaire servers en opslagsystemen te gebruiken. Ook kunnen de licenties voor RDBMS-systemen vrij duur zijn, terwijl veel NoSQL databases open source en dus gratis zijn
De specifieke geschiktheid van een bepaalde NoSQL database hangt af van het probleem dat het moet oplossen.
NoSQL databases worden steeds meer gebruikt in big data en real-time webapplicaties. Ze werden populair met de introductie van het web, toen databases van een maximum van een paar honderd gebruikers op een interne bedrijfsapplicatie naar duizenden of miljoenen gebruikers op een webapplicatie gingen. NoSQL systemen worden ook wel “Not only SQL” genoemd om te benadrukken dat ze ook SQL-achtige query talen kunnen ondersteunen.
Veel NoSQL winkels compromitteren consistentie (in de zin van het CAP theorema) ten gunste van beschikbaarheid en partitietolerantie. Enkele redenen die de adoptie van NoSQL winkels blokkeren zijn het gebruik van low-level query talen, het ontbreken van gestandaardiseerde interfaces, en enorme investeringen in bestaande SQL. Ook hebben de meeste NoSQL winkels geen echte ACID transacties of ondersteunen alleen transacties in bepaalde omstandigheden en op bepaalde niveaus (b.v. document niveau). Tenslotte zijn RDBMS’en meestal veel eenvoudiger in gebruik omdat ze GUI’s hebben, terwijl veel NoSQL oplossingen een command-line interface gebruiken.
Vergelijking van de twee
Een van de ernstigste beperkingen van relationele databases is dat elk item slechts één attribuut kan bevatten. Als we een voorbeeld nemen van een bank, wordt elk aspect van de relatie van een klant met een bank opgeslagen als afzonderlijke rij-items in afzonderlijke tabellen. De stamgegevens van de klant staan dus in de ene tabel, de rekeninggegevens in een andere tabel, de leninggegevens in weer een andere, beleggingen in een andere tabel, enzovoort. Al deze tabellen zijn met elkaar verbonden door het gebruik van relaties zoals primaire sleutels en vreemde sleutels.
Niet-relationele databases, in het bijzonder de sleutel-waarde opslag van een database of sleutel-waarde paren, zijn radicaal verschillend van dit model. Sleutel-waarde paren staan u toe om verscheidene verwante punten in één “rij” van gegevens in dezelfde tabel op te slaan. We plaatsen het woord “rij” tussen aanhalingstekens omdat een rij hier niet echt hetzelfde is als de rij van een relationele tabel. Bijvoorbeeld, in een niet-relationele tabel voor dezelfde bank zou elke rij de gegevens van de klant bevatten, alsook zijn rekening-, lening- en beleggingsgegevens. Alle gegevens met betrekking tot één klant zouden handig samen worden opgeslagen als één record.
Dit lijkt een duidelijk superieure methode om gegevens op te slaan, maar het heeft een groot nadeel: key-value stores kunnen, in tegenstelling tot relationele databases, geen relaties afdwingen tussen data-items. Bijvoorbeeld, in onze key-value database, zouden de details van de klant (naam, sociale zekerheid, adres, rekeningnummer, leningnummer, enz.) allemaal worden opgeslagen als één gegevensrecord (in plaats van te worden opgeslagen in verschillende tabellen, zoals in het relationele model). ) zouden allemaal als één gegevensrecord worden opgeslagen (in plaats van in verschillende tabellen, zoals in het relationele model). De transacties van de klant (opnames, stortingen, aflossingen, bankkosten, enz.) zouden ook als één gegevensrecord worden opgeslagen.
In het relationele model is er een ingebouwde en waterdichte methode om de bedrijfslogica en -regels op de databaselaag te waarborgen en af te dwingen, bijvoorbeeld dat een opname ten laste komt van de juiste bankrekening, door middel van primaire sleutels en vreemde sleutels. In key-value stores ligt deze verantwoordelijkheid volledig bij de applicatielogica en veel mensen voelen zich erg ongemakkelijk om deze cruciale verantwoordelijkheid alleen aan de applicatie over te laten. Dit is een van de redenen waarom relationele databases gebruikt zullen blijven worden.
Wanneer het echter gaat om web-gebaseerde applicaties die gebruik maken van databases, heeft het aspect van het rigoureus afdwingen van bedrijfslogica vaak niet de hoogste prioriteit. De hoogste prioriteit is de mogelijkheid om grote aantallen gebruikersverzoeken af te handelen, waarbij het meestal gaat om alleen-lezen-verzoeken. Op een site als eBay bijvoorbeeld, kijkt het merendeel van de gebruikers alleen maar naar geplaatste objecten (alleen-lezen operaties). Slechts een fractie van deze gebruikers brengt daadwerkelijk een bod uit of reserveert de objecten (read-write operaties). En vergeet niet, we hebben het over miljoenen, soms miljarden, pageviews per dag. De beheerders van de eBay-site zijn meer geïnteresseerd in een snelle reactietijd om ervoor te zorgen dat de pagina’s sneller worden geladen voor de gebruikers van de site, dan in de traditionele prioriteiten van het handhaven van bedrijfsregels of het zorgen voor een evenwicht tussen lezen en schrijven.
Relationeel gemodelleerde databases kunnen worden aangepast en opgezet om grootschalige read-only bewerkingen uit te voeren via datawarehousing, en zo potentieel een groot aantal gebruikers te bedienen die een grote hoeveelheid gegevens bevragen, vooral wanneer relationele MPP-architecturen worden gebruikt zoals Analytics Platform System, Teradata, Oracle Exadata of IBM Netezza, die allemaal schaalbaarheid ondersteunen. Zoals gezegd onderscheiden data warehouses zich van typische databases doordat ze worden gebruikt voor complexere analyse van gegevens. Dit verschilt van de transactionele (OLTP) database, die hoofdzakelijk wordt gebruikt ter ondersteuning van operationele systemen en voor dagelijkse, kleinschalige rapportage.
De echte uitdaging is echter het gebrek aan schaalbaarheid van het relationele model bij OLTP-toepassingen, of bij elke oplossing met veel individuele schrijfacties, wat het domein is van relationele SMP-architecturen. Dit is waar niet-relationele modellen echt kunnen uitblinken. Zij kunnen hun gegevens gemakkelijk verdelen over tientallen, honderden en in extreme gevallen (denk aan Google search) zelfs duizenden servers. Aangezien elke server slechts een klein percentage van de totale verzoeken van gebruikers afhandelt, is de responstijd voor elke individuele gebruiker zeer goed. Hoewel dit gedistribueerde computermodel kan worden gebouwd voor relationele databases, is het een echte pijn om te implementeren, vooral wanneer er veel wordt geschreven (d.w.z. OLTP), waarbij technieken als sharding nodig zijn die meestal aanzienlijke codering buiten de bedrijfslogica van de applicatie vereisen. Dit komt omdat het relationele model aandringt op gegevensintegriteit op alle niveaus, die moet worden gehandhaafd, zelfs wanneer de gegevens door verscheidene verschillende servers worden opgevraagd en gewijzigd. Dit is de reden voor het niet-relationele model als de architectuur van keuze voor web applicaties zoals cloud-computing en social networking.
Dus samengevat, RDBMS’s lijden aan geen horizontale schaling voor hoge transactie belastingen (miljoenen read-writes), terwijl NoSQL databases hoge transactie belastingen oplossen, maar ten koste van data integriteit en joins.
Bedenk dat veel oplossingen een combinatie van relationele en niet-relationele databases zullen gebruiken (zie Wat is Polyglot Persistence?).
Bedenk ook dat u misschien niet de prestaties van een niet-relationele database nodig hebt en in plaats daarvan kunt volstaan met het opslaan van bestanden in HDFS en het gebruik van Apache Hive (Apache Hive is een datawarehouse-infrastructuur die bovenop Hadoop is gebouwd om gegevens samen te vatten, query’s uit te voeren en te analyseren via een SQL-achtige taal die HiveQL wordt genoemd).
En om te eindigen met een opmerking die bijdraagt aan de verwarring, hebben we een andere categorie die NewSQL wordt genoemd: NewSQL is een klasse van moderne RDBMS’en die trachten dezelfde schaalbare prestaties te leveren als NoSQL systemen voor OLTP read-write workloads, terwijl ze toch de ACID garanties van een traditioneel relationeel databasesysteem behouden. De nadelen zijn dat zij niet geschikt zijn voor OLAP-stijl queries, en dat zij ongeschikt zijn voor databases van meer dan enkele terabytes. Voorbeelden zijn VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix, en Altibase.
Een afbeelding die de categorieën laat zien waarin veel van de producten passen:
Een uitstekende afbeelding die laat zien hoe alle technologieën in de Azure-cloud passen, komt uit Understanding NoSQL on Microsoft Azure:
Het gebruik van een NoSQL-oplossing is vooral zinvol als u een OLTP-toepassing hebt met duizenden gebruikers en een zeer grote database waarvoor een scale-out oplossing nodig is en/of als u JSON-gegevens gebruikt, met name als deze JSON-gegevens verschillende structuren hebben. U krijgt ook het voordeel van hoge beschikbaarheid omdat NoSQL oplossingen meerdere kopieën van de gegevens opslaan. Houd alleen in gedachten dat u voor de prestaties van de gegevensconsistentie opofferen kunt, evenals de mogelijkheid om gegevens samen te voegen, SQL te gebruiken, en om snelle massa-updates te doen.
Meer info:
MySQL vs MongoDB
MySQL vs. MongoDB: Relationele en Niet-Relationele Databases
10 dingen die u moet weten over NoSQL databases
Inleiding tot Databases
Verschil tussen SQL en NoSQL : Vergelijking
SQL vs NoSQL Database Verschillen Uitgelegd met Enkele Voorbeeld DB
NoSQL, NewSQL, of RDBMS: How To Choose
NewSQL – RDBMS on Steroids
NoSQL vs NewSQL Databases Kies het juiste gereedschap voor de juiste klus
SQL vs NoSQL: je wilt wel standaard een relationele opslag hebben
Oracle verdedigt Relationele DB’s tegen NoSQL Concurrenten
Uitleg NoSQL op Microsoft Azure
Maak kennis met de Avant-Garde van Nieuwe Relationele Databases
Naar SQL of NoSQL? Dat is de database vraag
CAP Theorem: Revisited
Wat is er echt nieuw aan NewSQL?
MongoDB vs MySQL: A Comparative Study on Databases
SQL and NoSQL Database Features and Differences