NoSQL - maar wat is het dan wél?

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.