NoSQL - maar wat is het dan wél?

Inleiding

Vandaag de dag wordt met een database in de praktijk een zogenoemde relationele database bedoeld. Dat is niet altijd zo geweest: ook voordat het relationele model in 1970 werd bedacht, waren er elektronische databases, zoals IMS en IDMS.

Dat uiteindelijk het relationele model toch de standaard is geworden, is niet vreemd: bij dit model stond de opbouw en de organisatie van een database los van de manier van opslag. Gegevens worden op een gestandaardiseerde manier opgeslagen, buiten de applicatie die de gegevens gebruikt. De inhoud van een database is daardoor veel toekomstbestendiger en kan makkelijker op een andere manier worden gebruikt dan waarvoor de gegevens oorspronkelijk zijn opgeslagen.

Toch voldoet het relationele model niet altijd. Relationele databases blinken niet uit in het verwerken van grote hoeveelheden gegevens of het serveren van gegevens onder hoge druk, tenzij fors wordt geïnvesteerd in hardware. Ook is een relationele database soms simpelweg niet nodig, omdat informatie bijvoorbeeld maar op één manier wordt opgeslagen en complexe query's op data niet nodig zijn. In andere gevallen biedt een relationele database te weinig functionaliteit, bijvoorbeeld bij het leggen van een groot aantal verbanden tussen punten.

Voor dit soort doeleinden zijn NoSQL-databases bedoeld. NoSQL is een verwijzing naar SQL, een door IBM ontwikkelde taal voor het werken met gegevens in een relationele database. SQL is de gangbare taal die wordt gebruikt om te werken met relationele databases. Onder andere MySQL, Microsofts SQL Server, Oracle Database en PostgreSQL leunen zwaar op SQL.

Bij de term NoSQL staat 'No' niet voor 'geen', maar voor not only, waarmee wordt bedoeld dat relationele databases niet overal geschikt voor zijn. Een sluitende definitie van NoSQL is bijna niet te geven, al is er één eigenschap die ze verenigt: ze verschillen op een of meer punten van traditionele relationele databases.

Een IMS-database

Relaties

Een relationele database bestaat formeel uit schema's: een logische container voor het opslaan van gegevensstructuren, bijvoorbeeld tabellen. In die tabellen zijn entiteiten opgeslagen. Elke entiteit neemt één tabelrij in beslag en heeft een of meer attributen. In een rij wordt alle informatie over die entiteit opgeslagen; in een kolom zijn gelijkwaardige attributen over verschillende entiteiten opgenomen. Een relationele database bestaat dus uit twee dimensies. Ook kunnen relaties tussen schema's worden gelegd: informatie uit meerdere tabellen kan worden gecombineerd.

De laatste tijd neemt de populariteit van NoSQL snel toe. NoSQL zet alle principes van een relationele database overboord. Een NoSQL-database kan juist eendimensionaal zijn, zoals MemcacheDB en SimpleDB, of juist in meer dan twee dimensies werken, zoals Cassandra en BigTable. Andere NoSQL-databases zijn weer ontworpen voor het leggen van verbanden.

NoSQL-databases hebben vaak geen of beperkte mogelijkheden voor joins: het combineren van twee schema's oftewel tabellen. Bij NoSQL-databases is dat zeer inefficiënt. In plaats daarvan moet de ontwikkelaar dit soort functionaliteit in zijn applicatie verwerken. Het ontbreken van joins kan een nadeel zijn, maar zorgt er ook voor dat veel NoSQL-databases een belangrijk voordeel hebben: horizontale schaalbaarheid.

Flexibel, maar zwaar

Relationele databases zijn flexibel, maar trekken een relatief zware wissel op een server. Wanneer veel dynamische gegevens worden opgevraagd, kan een databaseserver overbelast raken. De oplossing kan zijn om fors te investeren in hardware.

Horizontaal schalen - het bijplaatsen van servers - is met relationele databases echter erg lastig. Een relationele database die onder hoge druk moet presteren, kan alleen verticaal worden opgeschaald: de server zal simpelweg beter moeten presteren. Dat vereist forse investeringen: krachtige databaseservers van Oracle en IBM kosten al snel honderdduizenden of zelfs miljoenen euro's. Horizontaal schalen is relatief goedkoper: er kunnen servers met relatief eenvoudige hardware worden bijgeplaatst, zodat de performancewinst naar verhouding goedkoop is.

Een andere oplossing is gebruik van het intern geheugen voor caching. Zo kan memcached worden gebruikt om vaak opgevraagde informatie in het geheugen te cachen, en zo de beperkingen van software als MySQL op te vangen. In feite wordt met memcached het opvragen van gegevens uit de database omzeild: hoe complex de query ook is, als het antwoord al in het interne geheugen aanwezig is, kan het snel uitgeserveerd worden. In sommige gevallen is dat echter niet genoeg.

BigTable en Cassandra

Zoekmachines moeten op elke mogelijke zoekopdracht voorbereid zijn. Vaak opgevraagde antwoorden kunnen best gecached worden, maar een zoekopdracht naar een zeldzame Zuid-Amerikaanse plant moet net zo snel kunnen worden uitgevoerd. Het gaat niet alleen om de hoeveelheid requests, maar ook om de complexiteit ervan.

Dat wordt nog moeilijker wanneer zoekresultaten zijn gepersonaliseerd en er dus voor elke gebruiker voor elk zoekresultaat aparte pagina's moeten worden gegenereerd. Om die reden heeft zoekgigant Google een eigen database ontwikkeld: BigTable. Deze database-software wordt in verschillende Google-producten gebruikt en werkt zowel vanaf opslaggeheugen als intern geheugen.

BigTable

BigTable is in staat om met petabytes aan informatie te werken. Bovendien is BigTable ontworpen om horizontaal te schalen: de werklast kan over duizenden servers worden verdeeld. Verder is er ondersteuning voor compressie, en dat is nodig ook: een cel kan meer versies van dezelfde informatie bevatten, waarbij met timestamps wordt gewerkt.

BigTable heeft overeenkomsten met relationele databases, maar werkt in tegenstelling tot een relationele database met het uitlezen van kolommen - verzamelingen attributen dus - in plaats van regels. BigTable is closed-source, maar kan worden gebruikt via Googles App Engine-clouddienst. BigTable is beter geoptimaliseerd voor het uitlezen van gegevens dan voor het schrijven ervan.

Er zijn ook opensource-databases die op hetzelfde idee zijn gebaseerd, zoals Apache HBase, dat op het Hadoop-framework draait. Het pakket is geschreven in Java en is net als BigTable bedoeld voor grote hoeveelheden data. HBase wordt onder meer gebruikt door Facebook.

Requests kunnen worden gedaan via Rest en er is integratie met het Hadoop MapReduce-framework, dat ook al voor het verwerken van grote hoeveelheden data bedoeld is. HBase is vooral bruikbaar in applicaties waarbij het nodig is om op elk moment elke willekeurige entry te kunnen lezen en schrijven.

Cassandra

Facebook heeft indertijd ook zelf een NoSQL-database ontwikkeld: Cassandra. De ontwikkeling van deze software is inmiddels overgenomen door de Apache Software Foundation, die onlangs versie 1.0 aankondigde. Deze database wordt onder meer gebruikt door Reddit en Twitter. Cassandra is eveneens in Java geschreven en heeft zowel trekjes van BigTable als van Dynamo, een door Amazon ontwikkeld key-value-opslagsysteem. Cassandra is vooral geschikt voor het opslaan van gegevens: schrijven gaat sneller dan lezen.

BigTable draait bovenop GFS, het bestandssysteem van Google. GFS zorgt voor replicatie en consistentie, net zoals het Hadoop-bestandssysteem dat doet bij HBase. BigTable en HBase bieden verder ondersteuning voor transacties, waarmee kan worden voorkomen dat complexe opdrachten maar ten dele worden uitgevoerd. Hiermee kan inconsistentie in de data worden voorkomen. Deze ondersteuning is echter minder compleet dan bij de relationele databases. Bovendien blinken NoSQL-databases toch al niet uit in consistentie: horizontale schaalbaarheid is belangrijker.

Het Acid-principe

Relationele databases hanteren doorgaans strikte regels voor het invoeren, uitlezen en bijwerken van informatie. Ze werken volgens het acid-principe: atomicity, consistency, isolation en durability. Zulke databasesoftware zorgt ervoor dat bewerkingen op data niet in elkaars vaarwater zitten, dat alleen volledig afgeronde transacties worden doorgevoerd, dat data goed wordt opgeslagen en dat de database consistent wordt geüpdatet: deze moet altijd hetzelfde antwoord teruggeven.

Het acid-principe maakt relationele databases betrouwbaar, maar levert ook problemen op. Om het acid-principe te handhaven, kunnen entiteiten bijvoorbeeld exclusief door een opdracht worden geclaimd, zodat er niet tegelijkertijd meerdere bewerkingen op worden losgelaten. Dat locken levert echter wel schaalbaarheidsproblemen op. NoSQL-databases doen daarom vaak concessies op dit gebied. Eén of meer van de acid-eigenschappen worden dan geofferd voor betere prestaties.

De Cap-stelling

Het is een dilemma dat bekendstaat als de cap-stelling. Cap staat voor consistency, availability en partition tolerance. Consistency vereist dat een transactie overal wordt doorgevoerd, availability zegt dat een transactie altijd kan worden uitgevoerd, en met partition tolerance wordt bedoeld dat de database blijft doorwerken als de communicatie tussen servers wordt verstoord. Volgens de cap-stelling kan bij het ontwerp van de database maar met twee van deze eigenschappen goed rekening worden gehouden. Relationele databases scoren bijvoorbeeld slecht op het gebied van partition tolerance.

Veel NoSQL-databases doen op andere vlakken concessies. Zo is voor BigTable, MongoDB en HBase de beschikbaarheid het kind van de rekening. Cassandra en SimpleDB leveren weer in op het gebied van consistentie. Deze databases hanteren het principe van eventual consistency: uiteindelijk moeten databaserecords op alle locaties gelijk zijn, maar het kan tijdelijk zo zijn dat op één locatie afwijkende gegevens zijn opgeslagen.

Hoewel het gebrek aan consistentie een nadeel van veel NoSQL-databases is, maakt dat het wel makkelijker om vanuit verschillende locaties data te serveren, en daarmee horizontale schaalbaarheid te bieden. Er zijn overigens uitzonderingen: zo hebben Berkeley DB en het daarop gebaseerde Oracle NoSQL volledige acid-ondersteuning, maar deze zijn weer niet bedoeld om horizontaal te schalen.

Sleutels en waardes

Een type NoSQL-database dat makkelijk horizontaal schaalt, meestal ten koste van de consistentie, is key-value-storage. Dit systeem is net als BigTable-achtige opslag bedoeld voor grote hoeveelheden gegevens. Key-value-opslag is vooral geschikt voor gegevens die heel vaak moeten worden uitgelezen.

De Dynamo-database van Amazon is een goed voorbeeld van een key-value-storagesysteem. "Betrouwbaarheid is een van onze belangrijkste behoeften", zo staat in een paper over Dynamo. "Zelfs de kleinste uitval kan grote financiële gevolgen hebben en het vertrouwen van consumenten ondermijnen."

Amazon moet blijven werken als harde schijven, routers, serverracks of zelfs hele datacenters uitvallen. Gegevens moeten op elk moment toegankelijk zijn. Daarvoor is een relationele database volgens Amazon te veel van het goede: data zou in de meeste gevallen alleen via primary keys worden benaderd; complexere query's worden veel minder vaak uitgevoerd. Dynamo doet niets anders dan het opslaan van een waarde bij een primary key, en kan daardoor veel efficiënter zijn dan een complexe relationele database.

Amazon SimpleDB is gebaseerd op Dynamo en wordt via Amazon Web Services als commerciële dienst aangeboden. Er zijn nog veel andere key-value-databases, zoals Membase, MemcacheDB, Riak en Redis. Onlangs introduceerde ook Oracle een NoSQL-database, die is gebaseerd op de Java-implementatie van de Berkeley DB-opensourcedatabase, die vooral in embedded-systemen wordt gebruikt.

Document-DB's

Enigszins verwant aan key-value-storage is de document-oriented database, zoals MongoDB, CouchDB en Terrastore. Een tabel in een document-db bestaat, simpel gezegd, uit een verzameling key-value-eenheden. In elke entry kunnen verschillende soorten informatie worden opgeslagen, zonder dat de tabelstructuur hoeft te worden gewijzigd.

Een populaire document-db is MongoDB, die werkt met opslag van json-documenten. De software is geschreven in C++ en is als binary beschikbaar voor Windows, Linux, OS X en Solaris. MongoDB biedt bepaalde mogelijkheden die SQL ook biedt, zoals dynamische query's en indexen. De query's zijn in feite javascript-expressies.

Apache CouchDB biedt ongeveer dezelfde functionaliteit, maar is trager dan MongoDB. Wel biedt CouchDB, in tegenstelling tot veel andere NoSQL-databases, ondersteuning voor acid-transacties. Ook CouchDB werkt met json-documenten en is hoofdzakelijk geschreven in Erlang, waardoor het onder meer op Linux, Mac OS X en Windows draait.

Graafdatabases

Minder schaalbaar dan andere NoSQL-databases zijn graafdatabases. Zoals de naam wellicht al doet vermoeden, is de structuur van deze databases gebaseerd op grafen. Bij deze databases zijn onderlinge verbanden het uitgangspunt. Er is geen centrale index; in plaats daarvan worden er recursieve verbanden tussen entry's gelegd.

Graafdatabases kunnen bijvoorbeeld worden gebruikt voor sociale-netwerksites of wiki's, waarbij sprake is van een groot aantal onderlinge verbanden. Het is inefficiënt om voor elk mogelijk verband een sql-query uit te voeren, als er ook rechtstreekse verwijzingen naar andere data kunnen worden opgeslagen. Een populaire graafdatabase is de opensource-Java-database Neo4j.

Tot slot

NoSQL-databases zijn er in vele soorten en maten, en in veel gevallen doen ze iets wat met relationele databases minder goed kan. Met name horizontaal schalen is voor de gigantische databases van onder meer zoekmachines een groot pluspunt. Hoewel NoSQL-databases de afgelopen tijd steeds populairder zijn geworden, betekent dat niet dat relationele databases gaan verdwijnen. Voor veel doeleinden voldoen die namelijk prima: het is geen toeval dat ze de afgelopen dertig, veertig jaar tot de facto standaard zijn uitgegroeid.

Door de massaliteit van het internet is er echter een behoefte aan alternatieven ontstaan. De komende tijd zullen we daarom meer van NoSQL-databases gaan horen. Opensourceprojecten als Cassandra, HBase, CouchDB en MongoDB worden steeds stabieler en krijgen steeds meer functionaliteit. Het gevaar bestaat echter ook dat 'NoSQL' tot een buzzword verwordt, net zoals bijvoorbeeld 'cloud computing'. Beide begrippen zijn even uitgebreid als nietszeggend en het is daarom belangrijk in het achterhoofd te houden dat NoSQL-databases niet overal de oplossing voor zijn.

Reacties (76)

[mphilipp]

Interessant verhaal. De conclusie is natuurlijk een open (garage)deur; er is nooit één 'silver bullet'. Je moet altijd beginnen met je eisen te formuleren. Als je ziet dat consistency en integriteit heel erg belangrijk zijn, zul je toch weer uitkomen bij een relationele database. Of misschien een hybride oplossing, waar invoer via de ene gaat, en uitlezen via de ander. Het kan immers zo zijn dat de invoerkant veel minder zwaar belast wordt dan de uitleeskant. Kijk naar iets als Wikipedia, die wordt vele malen meer uitgelezen dan dat er ingevoerd wordt.

Overigens schaalt Oracle prima horizontaal via RAC. Het kost een bak geld, en je moet er in je applicatie-architectuur enigzins rekening mee houden (bepaalde constructies kunnen elkaar in de weg zitten met meerdere instances op 1 db), maar het schaalt wel degelijk goed.

[Niemand_Anders]

Er is inderdaad geen silver bullet. Maar pak een gemiddeld les boek en je zult zien dat een database hoofdstuk altijd gaat over relationele (SQL) databases.

Begin jaren 90 waren relationele databases onbetaalbaar voor veel projecten en opensource zoals MySQL bestonden wel, maar misten een hoop standaard SQL functionaliteit. Zo kreeg MySQL pas in versie 4 ondersteuning voor sub queries.

Mede daarom werden dbase en FoxPro (soort van professionele access database) zo populair in de jaren 90. Tegen het eind van de eeuw wisseling had Inmiddels al met een aangepaste SyBase database de highend DB markt betreden en waren gelukkig alternatieven zoals MySQL en PostgreSQL flink verbeterd.

Maar omdat relationele database synoniem zijn geworden voor databases, kijken veel architecten en managers niet verder dan zij gewend zijn.

Relationele databases kunnen eigenlijk per definitie niet horizontaal worden geschaald althans niet met dezelfde snelheid als een enkele DB benaderd kan worden. Meestal wordt een master-slave opstelling gebruikt waarbij geschreven wordt naar de master, maar gelezen vanaf de slaves. Vaak zijn er director nodes welke als virtuele DB benaderd kunnen worden waardoor de applicatie niet de structuur van de database zelf hoeft te weten. Clustering zoals met RAC kunnen inderdaad een zeer dure oplossingen brengen, maar als je een cluster hebt met 4 servers, moet 4 wel 4 servers constant in sync houden. Daardoor zijn clustered database vaak trager dan master-slave opstellingen..

De meeste master-slave oplossingen houden er een lagere consistency aan. Uiteindelijk zullen alle databases in sync komen, maar tussen de databases onderling kan enig verschil zitten.

Gemakelijker dan een clustered (en vaak ook goedkoper) is gewoon een VMWare oplossing waarbij je meerdere fysieke servers tot 1 virtuele server omvormt. Dat schaalt horizontaal erg goed en is in combinatie met Microsoft, Oracle of IBM databases vaak ook goedkoper.

Overigens mis ik in het artikel de XML databases.

[humbug]

Relationele databases kunnen eigenlijk per definitie niet horizontaal worden geschaald althans niet met dezelfde snelheid als een enkele DB benaderd kan worden.

Tsja dat is niet helemaal waar. Er zijn genoeg voorbeelden van goed presterende multi master relationele databases beschikbaar. Oracle RAC is wel de bekendste maar zelfs voor MySQL zijn er opties in ontwikkeling. En de performance blijkt gewoon erg goed te zijn. Ook heb je al jaren de optie in de meeste databases (alweer, zelfs in MySQL) om je data te partitioneren waarbij data horizon geschaald wordt. Clustering en partitionering is vooral interessant als je veel wilt schrijven. Master/Slave werkt (niet heel raar) beter als je veel wilt lezen. Maar horizontale schaking is dus goed mogelijk en ook efficiënt bij het gebruik van relationele databases.

Gemakelijker dan een clustered (en vaak ook goedkoper) is gewoon een VMWare oplossing waarbij je meerdere fysieke servers tot 1 virtuele server omvormt.

Ik snap eigenlijk niet wat je wilt met VMWare, Binnen de meeste database servers is het goed mogelijk meerdere databases aan te maken die allemaal hun eigen gebruikers en rechten kennen. Daar heb je geen VMWare voor nodig. En failover via VMWare kost een flinke duit en is alsnog geen alternatief voor horizontaal schalen. VMWare heeft (afgezien van het feit dat je virtuele hardware opeens hetzelfde is op je brakke DIY server en op een dure 4 weg Xeon) weinig toegevoegde waarde voor een database server. Microsoft, IBM en Oracle hebben allen hun eigen HA oplossing die gewoon goed functioneert.

NoSQL belooft beter te presteren dan Relationele databases, maar vereist ook eigenlijk een andere manier van omgaan met je data en heeft dus nogal wat impact op je software ontwikkeling. In mijn ogen is NoSQL dan ook zeker interessant, maar wel met de beperkingen rondom het ACID principe en enkel voor zeer grote databases. Voor databases van zeg een paar honderd miljoen rijen heb je het in mijn ervaring namelijk gewoon niet nodig.

[afterburn]

Ik zie niet helemaal hoe jij met VMWare ineens komt tot meerdere databases en gebruikers rechten wanneer @Niemand_Anders het simpelweg heeft over de mogelijkheid om met VMWare makkelijk, snel en goedkoopte capaciteit van je db server uit te breiden door nieuwe doosjes aan toe te voegen.

Je maakt met relatief goedkope fysieke machines 1 grote VMWare virtual server aan, en als je capaciteit te kort komt voeg je simpelweg meer machines toe. Is goedkoop, fault-tolerant en kan on-the-fly en zonder downtime.

[trogdor]

Klinkt interessant.
Hoe heet het product van vmware waarmee dat kan ?

[Marcj]

Een VMWare oplossing waarbij je meerdere fysieke servers tot 1 virtuele server omvormt? En dat schaalt ook nog goed?

Hoe heet dat? Want dat klinkt natuurlijk als de ultieme oplossing...

[Martao]

Het schaalt heel behoorlijk, maar de bottleneck is en blijft je storage. Schrijven naar disk is relatief duur.

Overigens is het schalen binnen een LAN een ding, maar wat als je een dienst wil leveren die fysiek verspreid is over meerdere continenten. Dan gaat latency echt pijn doen als je bijvoorbeeld gaat locken. Dat is voor Google denk ik een groot argument.

[mphilipp]

Relationeel is een goed all-purpose oplossing. Dat zegt eigenlijk al genoeg. Voor veel doeleinden geschikt, maar voor een aantal toepassingen dramatisch ongeschikt. OLAP bijvoorbeeld, daar wordt een heel ander model toegepast. Ik heb wel eens (met hulp van een collega) een hele aardige sales rapportage gemaakt die er welliswaar heel snel uit kwam, maar de code was door alle truukendozen praktisch onleesbaar. Voor die toepassingen is dan een ander model veel geschikter. In Oracle en waarschijnlijk ook andere db's komen wel steeds meer hybride achtige oplossingen waar ze die structuren weten te integreren in hun relationele db. Het is echter verre van optimaal.
Dat lesboeken steevast over relationeel beginnen is logisch. Negen van de tien databases zijn relationeel, als het niet meer is. Maar het is net als C niet dè oplossing voor alles, maar wel voor veel.

Die alternatieven zijn overigens vrijwel alleen geschikt voor die specifieke toepassingen. Als je iets als SAP wilt draaien, zul je een gecertificeerde database moeten hebben en verval je weer in DB2, MS-SQL of Oracle. Dat lijkt me ook het meest verstandige, want consistency en integriteit staat niet hoog op het lijstje van NoSQL.

BTW is een Oracle RAC cluster geen oplossing waarbij je x servers moet syncen. Er is altijd maar 1 database op shared storage en x nodes met een Oracle instance die op die database werken. Of zo'n VMWare oplossing met Oracle net zo goed werkt als een RAC zou ik niet weten, maar je bespaart in principe alleen een RAC licentie uit, want je rekent Oracle af per CPU.

[ACM]

RAC heeft dus shared storage (SAN toch? Of zou elk POSIX cluster-filesystem voldoen, niet dat er daar nou veel van zijn) nodig... Die shared storage moet dus meeschalen met de toenemende belasting door de extra nodes. SAN's die (vrijwel) lineair horizontaal schalen - met relatief lineaire kosten - zijn vziw nog steeds vrij zeldzaam.

Kan je van 10 naar 100 RAC-nodes schalen? En van 100 naar 1000? Met een aantal van de bigdata nosql-systemen kan dat.

[TheekAzzaBreek]

Ja, RAC heeft shared storage (niet noodzakelijk SAN). In theorie voldoet idd ieder cluster filesystem, al zullen ze niet allemaal gecertificeerd worden. RAC kan naar maximaal 100 nodes, maar ik geloof niet dat iemand dat ook echt doet. Omdat het een shared everything architectuur heeft, is er behoorlijk wat inter-node communicatie nodig, en dat loopt op met het aantal nodes. 32 nodes is de grootste RAC implementatie waar ik van gehoord heb, op Exadata, dus op een bloedsnel netwerk.

[Korben]

Gemakelijker dan een clustered (en vaak ook goedkoper) is gewoon een VMWare oplossing waarbij je meerdere fysieke servers tot 1 virtuele server omvormt. Dat schaalt horizontaal erg goed en is in combinatie met Microsoft, Oracle of IBM databases vaak ook goedkoper.

Interessant, hoe heet dit concept? Physicalisatie? Werkt dit ook voor andere services dan database-servers? Heb je hiervoor speciale versies van een OS nodig? Database-server?

[leuk_he]

Oracle prima schalen op een RAC?

Nee, dan heb je het verhaal niet helemaal begrepen. Bepaalde scenarios schalen inderdaad heel goed op een RAC. Als je b.v. veel gebruikers hebt die veel quereis doen dan schaalt het uitstekend. Als je veel inserts doet op dezelfde tabbellen waar ook weer queries op gedaan worden dan is oracle heletijd locks aan het uitwisselen. Juist daar is een NO-SQL database weer heel sterk in.

Ook de beschikbaarheid schaalt bij een RAC niet op dezelfde manier. in nosql houdt de applicatie daar min of meer al rekening mee, bij een RAC kun je uitstekend een bepaalde node gepland down brengen, maar 1 slecht functionerende node in een RAC kan een database op zijn knieren brengen. (je zou dat een implementatie probleem kunnen noemen....) . (maar goed, een slecht netwerk component kan alle typen databases op file based na op zijn kniieen brengen).

Nadeel van NO-SQL is wel dat je je applicatie van de grond af op op no-sql moet ontwerpen.

Wat ik ook mis in het NO-SQL verhaal is dat je eigenlijk niet met 1 server KUNT beginnen. Je moet met 2-3 database servers beginnen. (als ik het goed gesnapt heb).

[mphilipp]

Je mag ook wel verder lezen als 1 regel. Ik geef zelf al aan dat niet alles goed gaat.

[Umbrah]

Stiekem kan ik niet wachten totdat deze NoSQL storm weer voorbij is. Ik werk met genoeg data (zo'n 10PB kan hier opgeslagen worden) om te weten dat relationeel vaak een beperking is, maar een silver bullet in de vorm van NoSQL? Het heeft zeker zo z'n dingetjes, maar ik vrees dat het gevaar dat het een buzzwoord wordt, zoals Rob Coops, aanwezig is. Ik denk dat het net zoiets is als de GHz mythe of "LED-TV" verhalen wat mensen als zoete koek kopen.

Er moet altijd rekening worden gehouden met het "waarom" achter het IT-systeem, en dan moet er pas een tool bij worden gezocht. Hetgeen waar facebook bijvoorbeeld NoSQL voor gebruikt is héél iets anders dan hetgeen waar het SQL voor gebruikt. En dan zijn er natuurlijk dingen als MySQL dat bij een groeiend bedrijf een nachtmerrie wordt, maar een noodzakelijk kwaad.

Waar ik me wel over verbaas is dat er in dit artikel niks wordt genoemd over het volgende buzzwoord: NewSQL. Een term die door Stonebaker (voor de DB fans onder ons geen kleine naam) uitgevonden is om een database te bouwen die de lineaire schaalbaarheid van NoSQL en de flexibiliteit van SQL-in-z'n-ACID te combineren.

Overigens, puur op persoonlijke noot, houd ik altijd beheersbaarheid en performance in belang. Er zijn zó veel database oplossingen op deze wereld, maar wat is de reden dat men toch vaak voor "good ol' MySQL en Oracle" gaat? De database kan het haast niet zijn, met dingen als VoltDB, FireSQL en CassandraDB in het wild. Ik denk dat het de tooling en documentatie is. Iets wat je heel vaak bij nieuwe producten ziet verschijnen als ondergeschoven kindje. Rapid prototyping is bij MySQL een eitje, al was het maar door bijvoorbeeld hun uitstekende Windows/.Net tooling (workbench bijvoorbeeld). Uiteindelijk is het makkelijk te vertalen en te herhalen of zelfs met wat meer moeite te doen met de tool in het begin, maar je logic laag bovenop MySQL bouwen is soms wel héél wat aantrekkelijker dan gelijk maar Firebird of Cassandra of zelfs: VoltDB te pakken. De keuze voor de juiste DB voor de juiste use-case kan daarna nog wel, hoewel dat iets is wat door een deadline vaak maar uitgesteld wordt.

Ik wou dat ik meer tijd had om de claims van VoltDB bijvoorbeeld te testen, want dat klinkt toch wel heel erg als silver bullet!

[johnbetonschaar]

Stiekem kan ik niet wachten totdat deze NoSQL storm weer voorbij is. Ik werk met genoeg data (zo'n 10PB kan hier opgeslagen worden) om te weten dat relationeel vaak een beperking is, maar een silver bullet in de vorm van NoSQL?

Er staat letterlijk in het artikel dat er uberhaupt geen 'silver bullet' is als het op database technieken aankomt, dus net zo min als dat NoSQL oplossingen dat zullen worden, zijn relationele databases dat ooit geweest.

Tot niet zo lang geleden werden SQL databases overigens wel als een soort van 'silver bullet' oplossing gebruikt, en werd er zelfs niet eens over alternatieven nagedacht. Database == SQL werd/wordt er vaak gedacht, zelfs als dat betekende dat je uiteindelijk voornamelijk BLOB's aan het opslaan was voor data die niet makkelijk in tabellen en relaties te vangen is. Ik loop er op het werk nog dagelijks tegenaan, waar ik werk 'hebben we Oracle', dus elk nieuw product moet Oracle gebruiken want 'Oracle is een enterprise-grade database', en 'we hebben er toch al voor betaald' .

Feit blijft dat je voor unstructured/semi-structured of document-oriented data jezelf gewoon allerlei onnodige beperkingen oplegt als je voor een relationele database kiest. Voornamelijk het ontwerpen, onderhouden en in code implementeren van het database schema kost gewoon ram-veel tijd, en zorgt er vaak voor dat het schema simpelweg als 'heilig' wordt beschouwd, omdat er bij elke verandering anders iemand aan de gang moet om het schema te updaten, de data te 'upgraden', nieuwe views aan te maken, code die met de database communiceert aan te passen, etc. In de praktijk komt dit er vaak op neer dat producen rond databases worden gebouwd die als afvalbak gebruikt worden, omdat het gewoon niet de doen is om krampachtig te proberen alles wat je wilt opslaan in een tabel-relatie vorm te gieten. Wat is dan nog je voordeel van een relationele database, als je je data toch plat gaat slaan of je schema niet meer kunt/wilt aanpassen aan nieuwe datavormen of voortschrijdend inzicht? Iets met square pegs en round holes...

Ik snap dus niet helemaal waarom je het punt in feite probeert om te draaien met je opmerkingen dat je geen heil ziet in 'NoSQL als silver bullet', terwijl NoSQL juist een stap is om van 'SQL als silver bullet' af te komen.

[...] maar ik vrees dat het gevaar dat het een buzzwoord wordt, zoals Rob Coops, aanwezig is

Persoonlijk vind ik het een vrij kortzichtige opmerking om te stellen dat NoSQL een buzzword is, en daarom waarschijnlijk iets wat overwaait. Zoals het artikel ook al aangeeft worden NoSQL-achtige oplossingen al op zeer grote schaal professioneel gebruikt voor oplossingen die je met SQL-achtige oplossingen uberhaupt niet voor elkaar zou krijgen.

NoSQL/schema-less databases zijn zeker geen 'buzzword technologieen'. Misschien dat het nu ineens veel aandacht krijgt om wat voor reden dan ook, maar dat neemt niet weg dat dit soort databases een zeer duidelijk toepassingsgebied hebben waar relationele databases gewoon een slechte keus voor zouden zijn.

Wat ik trouwens nog mis aan het artikel is een alinea'tje over object-oriented databases zoals bijvoorbeeld ZODB, welke ook als NoSQL gezien kunnen worden maar totaal anders werken dan key-value stores, document-oriented databases of andere NoSQL database vormen.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 10:54]

[silentsnake]

Wat misschien nog leuk is om op te merken is dat Facebook naast development aan Cassandra ook veel code heeft gecommit aan Apache Hadoop & HBase. Ze gebruiken dus zowel Cassandra als HBase, waarbij het laatste gebruikt wordt voor hun messaging platform. Wat erg interessant is aangezien HBase en Hadoop van orgine niet direct bedoeld zijn voor real-time response. Hoewel ik geen fan ben van Facebook geven ze echt veel terug aan de open source community!

Ik ben zelf nu ook veel bezig met Hadoop & HBase en het grootste "probleem" is dat het redelijk complexe materie is en niet voor iedereen is weggelegd. Een traditionele database is dikwijls binnen een paar minuten geïnstalleerd, maar met Hadoop en HBase is dat zeker niet zo als je dit op de "traditionele" manier doet. Hoewel men wel eens waar probeerd om dit eenvoudiger te maken (Cloudera Express bijvoorbeeld) zal je hier in de praktijk niet heel veel aan hebben als je het serieus gaat gebruiken. Je moet immers diepgaande kennis hebben van Hadoop en HBase wil je werkelijk het beste uit je cluster gaan halen (en naarmate je cluster gaat groeien moet je dit ook zéker doen).

Voor mensen die geïntereseerd zijn om er een keer mee te spelen kunnen naar Whirr kijken. Je kan in Amazon EC2 dan automagisch een compleet Hadoop clustertje uitrollen en er mee gaan spelen. Als alternatief kun je kijken naar de Cloudera CDH distributie. Daar zit duidelijke documentatie bij om op vrij eenvoudige manier een lokaal (standalone) cluster te bouwen. Ik kan je echter aanbevelen om niet met Whirr aan de slag te gaan als je het probeerd te begrijpen - je hebt namelijk dan geen idee wat je dan moet doen als het draait.

Om nog maar wat over het het artikel an sich te zeggen - helder en duidelijk, voornamelijk de nadruk op het feit dat het absoluut geen vervanger is voor relationele databases is goed. Een NoSQL oplossing kan lang niet voor alle doeleinden gebruikt en het is zéker niet het ei van Columbus. De laatste alinea benadrukt dit alleen nog maar meer.

[Reactie gewijzigd door silentsnake op 23 juli 2024 10:54]

[tomhagen]

Wat misschien nog leuk is om op te merken is dat Facebook naast development aan Cassandra ook veel code heeft gecommit aan Apache Hadoop & HBase. Ze gebruiken dus zowel Cassandra als HBase

Maar ze gebruiken ook nog "gewoon" MySQL. Op vrij grote schaal zelfs.

[ronaldmathies]

Maar dat is ook het idee, gebruik de best tool for the job. En dat is iets wat veel bedrijven moeten leren.

Kijk naar je probleem situatie en bedenk daarbij de beste tool of tools. Wie weet is een combinatie van NoSQL met een RDBMS wel ideaal.

[Martao]

Volgens mij gaan ze MySQL wel langzaam uitfaseren; maar dat kan ik verkeerd begrepen hebben.In ieder geval gebruiken ze nu MySQL op grote schaal, gekoppeld aan MemcachedDB voor de snelheid.

Choose the right tool for the right job is inderdaad het adagium.

[Refro]

Een goed en informatief artikel, hier mogen er meer van komen. Het enige wat ik jammer vind is dat het beeld geschept wordt dat de NoSQL databases niet consistent zijn. Zover ik weet zijn ze dit wel maar volgen hierin een ander consistency model. Hierover is veel te vinden op de mongodb site http://blog.mongodb.org/p...ibuted-consistency-part-1

Elk consistency model heeft eigen tradeoffs en het ligt aan het probleem welk model het beste past.

[Reactie gewijzigd door Refro op 23 juli 2024 10:54]

[Anoniem: 14124]

Overigens ondersteund RavenDB wél transactions.

De complexiteit bij NoSQL zit hem in het modelleren van je document. Het modelleren door te normaliseren van een systeem met een schema, is velen malen eenvoudiger dan het modelleren van een NoSQL document.

Overigens is een groot voordeel van NoSQL juist het ontbreken van een schema, niet alleen voor je performance, maar ook voor software oplossingen waar je vaak werkt met wijzigingen in de structuur van je data.

Je gaat uit van de functionaliteit / use case, en in sommige situaties kom je niet om de relationele referenties heen.

edit:
grammaticale fouten verwijderd

[Reactie gewijzigd door Anoniem: 14124 op 23 juli 2024 10:54]

[udenjpg]

Ik mis nog een grotere speler op de NoSql markt intersystems.

Sinds 1978 op de markt, en veel gebruikt in de financiele en medische wereld. Ze doen niet veel aan naamsbekendheid, maar je komt het vaker tegen dan je in eerste instantie denkt.

[Y0ur1]

Goed artikel, kan alleen iemand het volgende punt wat nader toelichten?

Dat uiteindelijk het relationele model toch de standaard is geworden, is niet vreemd: bij dit model stond de opbouw en de organisatie van een database los van de manier van opslag.

[Free rider]

Voor SQL moest de hardware gerelateerd worden aan de applicatie. Stel je hebt een persoonsadministratie en een persoon heeft een primaire key 12-4-28-5. Dan weet de database meteen dat de gegevens zijn opgeslagen op disk 12, kop 4, track 28 sector 5.
Dat is bijzonder snel maar ook erg inflexibel: Je moet hopen dat disks met diezelfde structuur langer leverbaar zijn dan je levensduur van je applicatie, verder is het zeer lastig om je applicatie aan te passen en extra gegevens op te slaan - waardoor de gegevens niet meer in een sector passen.

[storeman]

In een Relationele Database wordt je database structureel opgeslagen. Het model van je data ligt vast en kan heel eenvoudig in verschillende vormen gegoten worden en je kunt de data eenvoudig analyseren dmv queries.

NoSQL legt veel meer verantwoordelijkheid bij de applicatie. Deze moet exact weten hoe de data gestructureerd is en geeft veel meer vrijheid qua opslag. Juist door deze vrijheid weet je niet precies wat je terug krijgt aan data, deze onzekerheid moet je in de applicatielaag afvangen.

In een RDBMS kun je aangeven dat velden verplicht zijn, dat betekent dat elke entity deze waarden met zekerheid heeft.

Ook is het relationele model veel meer standaard, data tussen MySQL, Postgresql, MSSQL en andere systemen wordt voor de gebruiker op dezelfde manier opgeslagen. De onderliggende mechanismen (filesystem, indexes) en dergelijke zijn veel minder van belang.

Als je naar NoSQL kijkt, blijkt dat hier veel grotere verschillen in bestaan, ook in de bovenlaag. Qua communicatie, benadering van data, snelheid, schaalbaarheid en betrouwbaarheid.

[Y0ur1]

De punten die je maakt snap ik en zijn ook uit het artikel te halen. Ik snap alleen niet wat er bedoeld wordt met "manier van opslag" in de context van een relationele database.

[Rob Coops]

Natuurlijk gaat NoSQL een buzz word worden. Het is helaas zo dat er erg veel mensen zijn die beslissingen maken willen dan wel moeten zonder dat ze verstand van zaken hebben. In de jaren 90 was het internet verbonden zijn en LDAP, niet veel later kwam Java om de hoek kijken. Toen werd het Swing en J2EE, virtualisatie, cloud computing en NoSQL zal zonder enige twijfel binnen niet al te lange tijd ook in dat lijstje thuis horen.

Het geen waar je heel erg op moet letten is het doel van het systeem. Als je weet dat je een database gaat bouwen waar minimaal 500.000 records per maand aan toegevoegd worden en waar je voor ieder record een onbekend aantal images en pdf documenten moet opslaan, met als voorwaarde dat je minimaal 6 jaar aan data online doorzoekbaar moet hebben. Dan is SQL niet je beste vriend. Ook werken dingen als Cassandra en Berkely DB niet echt lekker op zo'n moment maar bijvoorbeeld MongoDB is dan juist weer wel een erg handige oplossing.
Aan de andere kant als je juist veel voor af te definieeren relaties tussen verschillende data sets hebt en je regelmatig zult moeten zoeken naar alle data in set X die een relatie heeft met een records in set Y dan ik SQL juist weer bij uitstek geschikt.

Over het algemeen zijn er maar weinig bedrijven die op dit moment al de datasets hebben die SQL tot een probleem zou maken. De meeste bedrijven werken met databases van niet meer dan 10GB of als ze "heel groot" zijn 100 tot 200GB dit soort kleine data sets zijn veel al niet groot genoeg om zo veel problemen op te leveren dat je over moet stappen op een andere oplossing dan SQL. Er zijn zeker in de grote commerciële databases voldoende mogelijkheden om deze data razend snel te doorzoeken en te bewerken.
Daar naast is het in veel gevallen zo dat het aanpassen van de software die met deze backend werkt simpel weg vele malen duurder uit zou vallen dan het aanschaffen van meer hardware.
Dis is dan ook de reden dat ik zou zeggen als je al een overstap overweegt om welke reden dan ook buzz woord of een echte reden maakt eigenlijk niet uit. De truck is om eerst eens heel goed te bekijken wat je verwacht van de toekomst, hoe veel meer data moet je opslaan over 1, 2 en 5 jaar. Kun je misschien data verwijderen of naar een andere langzame database schrijven die alleen als archief gebruikt wordt. Er zijn vaak redelijk goedkope oplossingen te bedenken die veel minder kosten dan overstappen op een andere engine en grote wijzigingen in de software aanbrengen.
Als je toch echt niet anders kan dan is het van zeer groot belang dat je echt zeker weet dat de enigen die je kiest niet alleen nu maar ook over minimaal 10 jaar nog voldoet wat betreft performance en schaalbaarheid.

[tomhagen]

De meeste bedrijven werken met databases van niet meer dan 10GB of als ze "heel groot" zijn 100 tot 200GB dit soort kleine data sets zijn veel al niet groot genoeg om zo veel problemen op te leveren dat je over moet stappen op een andere oplossing dan SQL.

Ik werk met ~ 1.5 - 2 TB / maand. En zelfs dat gaat nog prima met MySQL.

De truck is om eerst eens heel goed te bekijken wat je verwacht van de toekomst, hoe veel meer data moet je opslaan over 1, 2 en 5 jaar. Kun je misschien data verwijderen of naar een andere langzame database schrijven die alleen als archief gebruikt wordt.

Dit principe passen wij ook toe. Oude data gaat naar archive servers. "Verse" data blijft over op productie machines. Op die fiets vernaggel je je query cache ook niet.

Als je toch echt niet anders kan dan is het van zeer groot belang dat je echt zeker weet dat de enigen die je kiest niet alleen nu maar ook over minimaal 10 jaar nog voldoet wat betreft performance en schaalbaarheid.

10 jaar vooruit kijken is in veel gevallen niet mogelijk en zelfs niet relevant. Een jaar, twee jaar valt qua groei nog wel te voorspellen, maar dan houdt 't voor vele industrieen wel op.

[naikon]

Ik werk met ~ 1.5 - 2 TB / maand. En zelfs dat gaat nog prima met MySQL.

Ik neem aan dat je dan MyISAM gebruikt, want InnoDB kan totaal niet overweg met heel veel data aangezien het niet kan compacten (zie http://bugs.mysql.com/bug.php?id=1341 ). MyISAM is nauwelijks een SQL database te noemen aangezien het geen transacties ondersteunt.

Mijn inziens is het grootste voordeel van bijv. Cassandra dat het 1) schaalt standaard lineair (performance is een veelvoud van het aantal nodes), zowel reads als writes en 2) er is geen master, alle nodes zijn gelijk. Dit maakt het beheer veel eenvoudiger en 3) data word maar beperkt gedupliceerd (copies=3 bijv.) in plaats van over het hele cluster, dit scheeld dus storage.

[Martao]

Het is niet zo'n probleem als NoSQL een buzzword doet; het is alleen jammer dat het niet staat voor NO SQL, maar Not only SQL, hetgeen gemakkelijk verkeerd begrepen wordt.

[TheekAzzaBreek]

Het is niet altijd het volume van de data die de keuze van de db architectuur bepaalt, eerder de structuur van de data en van het gebruik. Ik ken relationele db's van tientallen TB die goed voldoen. Maar als je bv logfile analyse wil doen gaat dat niet vliegen, dan ben je met een BigTable-achtige opzet veel beter uit, al werk je maar met datasets van enkele GB.

[Roeligan]

Vond dit wel een vreemd stukje:

Cassandra is vooral geschikt voor het opslaan van gegevens: schrijven gaat sneller dan lezen

Cassandra wordt geb ruikt door Facebook en Twitter, daar wordt de meeste data (een status message/tweet) toch slechts éénmaal opgeslagen en (indien genoeg friends/followers ) meerdere malen gelezen, zou de snelheid de andere kant op niet handiger zijn, of zie ik hier iets over het hoofd?

[naikon]

Facebook gebruikt Cassandra + Memcached voor het uitserveren van data. Schrijven gaat sneller in Cassandra omdat het altijd sequentieel naar de disk schrijft. Zolang data nog in Cassandra's cache staat is lezen zeer snel, maar als dit niet meer het geval is zal de het moeten zoeken op harddisk. Dit kost helaas altijd meer dan 1 I/O dus zal dit langzamer gaan dan schrijven.

[netman]

Vanaf versie 1.0.0 is schrijven bij Cassandra niet significant sneller meer dan lezen. Zowel lezen als schrijven zijn nu beide snel.

http://www.datastax.com/d...cassandra-1-0-performance

[machiel]

Leuk artikel. De grote eye-opener voor mij was het loslaten van de relationele database als de voor de hand liggende oplossing voor alle problemen. Ook als je veel data moet opslaan denk je vaak 'we tunen de database wel als het zover is'. Dat heeft vaak gewerkt, maar als de rijen in de miljarden lopen niet meer. Ook Neo4j kan soms juist makkelijker en natuurlijker zijn dan een relationele database. Kijk dus goed om je heen voordat je een database kiest

[theBazz]

Grappig, ik zat juist de laatste tijd te denken dat ik misschien ook moest over stappen op zoiets als couchdb, maar weet nu dankzij dit artikel dat ik waar ik mijn database voor nodig heb toch het beste bij een relationele database kan blijven.