We kunnen eindeloos blijven schrijven, praten en dromen over de cloud maar het gaat maar om één ding, namelijk de data die uiteindelijk nog steeds de core asset is van menig bedrijf. En deze kunnen we de cloud injagen maar zal wel bereikbaar, betrouwbaar en bruikbaar moeten blijven. Want geen data betekent geen service en dus geen business om het simpel te zeggen.
In traditionele architecturen zit data vaak gestructureerd in databases en kan het gevonden worden met Structured Query Language (SQL), de standaardtaal waarmee databanken gelezen en geschreven kunnen worden. Maar er is ook nog een berg aan ongestructureerde data die in omvang snel toeneemt. Om deze groeiende berg data onder controle te houden zijn wel weer databases nodig, de paradox waar ook de cloud niet aan ontkomt omdat we anders de MP3’s en filmpjes niet kunnen vinden.
Not only SQL
De populaire relationele databases zijn weliswaar flexibel maar kunnen vaak niet goed omgaan met parallelle verwerking en grote hoeveelheden data. Zo moeten records meestal exclusief geschreven worden om de consistentie binnen de database te bewaren. En deze ‘locking’ levert problemen op met het schalen. Groeiende hoeveelheid data en transacties betekent vaak een grotere server met speciale hardware en nog een tweede om de beschikbaarheid te vergoten. Niet handig in de cloud die vooral uit generieke servers bestaat en waar horizontaal schalen de norm is. Natuurlijk kun je altijd de database nog normaliseren maar dan blijken deze relationele databases weer minder flexibel, hoewel dat misschien ook te maken heeft met de populaire service-georiënteerde manier van programmeren.
Wegnemen van het probleem met exclusief schrijven van records, het oprekken van de eis voor consistentie maakt het makkelijker om de dataset over meerdere servers te verdelen. Nadeel hiervan is wel dat het antwoord dat je krijgt af kan hangen aan welke kopie je het vraagt. Nu is dat niet erg bij de database van een webshop, maar minder gewenst bij financiële transacties. Nut en noodzaak van de consistentie worden dus in de eerste plaats bepaald door eisen van een service en niet door wat er toevallig aanwezig is. Toch wordt er nog vaak gekozen voor een relationele database oplossing, de SQL tenzij gedachte.
Dat terwijl er altijd al meer keuze was maar bepaalde techniek wat op de achtergrond is geraakt. Het mainframe is dood maar lang leve de netwerk database als alternatief voor SQL. Want hoe nieuw zijn hippe oplossingen als Cassandra, Dynamo of de vele andere NoSQL-oplossingen, de non-relationele datastores waar zoveel ophef over is binnen de cloud?
Conservatieve benadering
Niet-relationele databases zijn snel, schalen fantastisch en stellen minder eisen aan de servers maar er is nog een historie om rekening mee te houden. Zo legt de querytaal SQL, ooit bedoeld om gebruikers de mogelijkheid te geven om hun data te analyseren, geen expliciete relaties. Dat maakt het makkelijker om data uit relationele databases te krijgen, bijvoorbeeld met Excel omdat SQL uiteindelijk toch te moeilijk bleek voor eindgebruikers. Hoewel mogelijkheden om data uit non-relationele databases te krijgen langzaam verbeteren is dit iets wat toch nog vaak in de code geregeld moet worden. Hierdoor zullen de populaire relationele databases dus niet zo snel vervangen worden en zijn ‘new kids on the block’ vooral nog een aanvulling.
Die voorspelling maak ik niet uit behoudzucht maar om het feit, zoals ik in de intro al zei, dat het uiteindelijk niet gaat om de database maar of en hoe je de informatie daar uit kunt halen. Nu staan de ontwikkelingen in de cloud niet stil en komen er dus steeds meer oplossingen voor dit probleem. Dat introduceert wel weer een nieuwe uitdaging omdat er ondertussen al vele noSQL-datastores zijn met ieder een specifieke inzet. En daarmee mogelijk ook een lock-in omdat het wisselen van de onderliggende datastore, net als bij relationele databases niet eenvoudig is. Dus zelfs als een applicatie platform agnostic is kan het wisselen van provider nog tegenvallen. Want worden oplossingen als Database as a Service straks niet de nieuwe ransomware, een gijzeling van data als een vorm van klantenbinding?
Slicing the elephant
Maar ook in het kamp van de relationele databases wordt niet stil gezeten en komen er ‘nieuwe’ technieken om de uitdaging van schalen op te lossen. Bijvoorbeeld met sharding, een techniek van partitionering die ook door SQL Azure gebruikt wordt met federations. Hierbij worden niet de kolommen maar de rijen van een tabel verdeeld waardoor er ‘scherven’ ontstaan. Dat kan lastig zijn voor applicaties omdat deze wel moeten weten waar de data gevonden kan worden. Net als bij andere vormen van normalisatie is er dus een sleutel (en waarde) nodig om te weten welke deur geopend moet worden. Dit kan in de code van applicaties opgenomen worden maar ook transparant gemaakt worden door vergelijkbaar als met DNS een root server te gebruiken die de transacties naar de juiste servers stuurt. Mijn vraag is echter waar het beste zo’n ‘load balancer’ gesitueerd kan worden?
De cloud tenzij
Om terug te komen op mijn eerdere opinie ‘De winst van cloud computing‘ gaat het steeds minder om de resources maar meer en meer om de data. Of eigenlijk het datamodel waar de uitdaging ligt om dit alles te ‘joinen’ tot hybride oplossingen. Ondertussen lijken namelijk steeds meer bedrijven te beseffen dat de cloud er voor iedereen is maar niet voor alles. Bijvoorbeeld omdat soms de snelheid van het licht nog niet snel genoeg is.
Dag Ewout, voordat ik verder reageer, wat bedoel je met de titel. Een debacle is toch een totale mislukking c.q. afgang?
Hi Ewout, kort samengevat “(Relationele) SQL databases en Service Oriented Architecture gaan niet zo goed samen en NoSQL lijkt ook geen goede oplossing voor bedrijfsoplossingen, maar kunnen we wel van relationele databases af?”
Henri,
Debacle heeft meerdere betekenissen, in deze opinie kun/mag je het lezen als catastrofe, een omkering in het relationele denken;-)
Gijs,
Leuke vragen waar ik niet direct een kant-en-klaar antwoord op heb omdat aangaande SOA er nogal veel ‘leverancier afhankelijke’ implementaties zijn, de architectuur principes die inderdaad nog weleens een relationele database voorstellen. Verder neem ik aan dat je bekend bent met Brewer’s stelling aangaande gedistribueerde systemen en het is dus om die reden dat ik de vraag stel waar een ‘load balancer’ moet komen te liggen, de Enterprise Service Bus die bijvoorbeeld cloud bursting zonder vendor-lock mogelijk maakt.
Stellen dat noSQL niet geschikt is voor business oplossingen doet vermoeden dat je geen ervaring hebt met mainframes: http://en.wikipedia.org/wiki/Unisys_OS_2200_databases
Ewout, die ken ik wel degelijk 🙂
De vraag is of je een op SOA en NoSQL gebaseerd, schaalbaar en multi-tenant ERP systeem kan ontwikkelen dat in je eigen datacentrum draait maar kan cloudbursten op een manier die geen vendor lock-in creeert. Ik geef het je te doen zeg!
Gijs,
Wordt met alle piketpaaltjes die je gaat zetten een beetje een andere discussie maar ik zou niet weten waarom noSQL niet past binnen een ERP systeem, meestal is dat toch een verzameling applicaties van verschillend pluimage. En er is altijd meer dan SaaS in de cloud dus ook dat zou toch inpasbaar moeten zijn?
Gijs: Relationeele database gaan prima samen met SOA. Relationele database kunnen ook gewoon groot en schaalbaar en snel, NoSQL heeft andere specifieke eigenschappen die in bepaalde scenario’s goed tot hun recht komen.
SQL en NoSQL vergen zeer andere benaderingen maar kunnen ook complementair zijn. NoSQL is vaak wel goedkoper per GB en daarom aantrekkelijk.
NoSQL vergt ook andere inzichten en als je eenmaal relationeel denkt is het zeer moeilijk om daarvan af te stappen. En daarmee onderschrijf ik dit artikel 🙂
“Zo legt de querytaal SQL, ooit bedoeld om gebruikers de mogelijkheid te geven om hun data te analyseren, geen expliciete relaties. Dat maakt het makkelijker om data uit relationele databases te krijgen, bijvoorbeeld met Excel omdat SQL uiteindelijk toch te moeilijk bleek voor eindgebruikers.”
Wat wordt daar nou mee bedoeld ?
– met SQL kun je ook relaties creeeren create table foreign key bla bla. Het DDL deel van SQL.
– kijk je naar de Query kant van SQL dan kan je zoeken/presenteren en rekening houden met die relaties.
– maar dat moet juist niet want dat vinden gebruikers weer moeilijk ?
Het zal aan mij liggen, maar ik kan hier geen touw aan vast knopen. Wat heeft de Cloud nu te maken met een database, SQL of NoSQL? Waarom zou SQL in hemelsnaam zelf expliciete relaties moeten leggen, wanneer je daar helemaal niet om vraagt? Vaak wil je dat ook helemaal niet, wil je juist die data hebben die geen relatie heeft met de rest. Hoe je de JOIN dan opstelt, is jouw verantwoordelijkheid. En zoals al is gezegd, relaties en onderhoud van relaties is ook af te dwingen in de DDL.
Databases zijn zo oud als de weg naar Rome. En dat geldt voor relationele databases die SQL spreken, die geen SQL spreken en NoSQL database. NoSQL is ook maar oude wijn in nieuwe zakken, in de jaren ’60 en ’70 waren dit de meest voorkomende smaakjes.
Hier komt nog bij dat wanneer NoSQL de oplossing is, een relationele database hoogst waarschijnlijk de verkeerde keuze zou zijn: De data is totaal anders. De bekende appels en peren…
Een cloud kun je ook (laten) inrichten in een lokaal datacentrum of je eigen bezemkast, daarvoor hoef je echt niet naar Azure of Amazon.
@mauwerd
Ik bedoel ermee wat ik schrijf, dat het leggen van relaties achteraf met SQL makkelijker is maar niet altijd efficienter omdat juist door het gemak hiervan de prestatie van de database (server) nog weleens te wensen over wil laten. Want hoewel Henri aangeeft dat relationele databases ook groot, snel en schaalbaar kunnen zijn vraagt dat vaak ook wel enige normalisatie achteraf.
Aangaande je inbreng over DDL, hierdoor is het makkelijk om met bijvoorbeeld Excel allerlei tabellen te maken om aanwezige data te analyseren, in mijn opinie ook een noSQL oplossing;-)