Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Het database debacle in de cloud

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4681367). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

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;-)

@Joost

Bedankt voor je reacties maar bij mijn weten geef ik min of meer dezelfde boodschap: "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?"

En inderdaad kun je de cloud ook inrichten in je bezemkast en stel ik dus ook de vraag waar en hoe de afslag gemaakt moet worden, hoe 'joinen' we de data die we on-premise hebben met wat er in de cloud zit. Want met toenemende samenwerkingen die soms de landsgrenzen overschrijden zullen er uiteindelijk toch relaties gelegd moeten worden tussen de verschillende systemen die gebruikt worden. Want ik ben het niet met je eens dat de data anders is, even de uitdagingen in diakritische tekens daar gelaten, maar alleen verschillend wordt opgeslagen.

@Ewout

Ik zou, zeker als architect, het boek "In-memory Data Management" van Hasso Plattner lezen. De nieuwste ontwikkelingen op database gebied zijn, grofweg gezegd, dat ze gedeeltelijk comlumn georienteerd worden en dat schijven worden vervangen door memory. Eea. heeft niets met cloud te maken.

http://epic.hpi.uni-potsdam.de/Home/InMemoryDataMgmt

KJ: Interessante materie, maar ook een work in progress en vergt een behoorlijke investering in tijd en ook andere hardware. Niettemin veelbelovend.

@KJ

Dat er nog vele ontwikkelingen in datamanagement zijn maakt het allemaal reuze interessant maar neemt niet weg dat we nog steeds een erfenis hebben uit het verleden, deels ingegeven door de altijd aanwezige economische afweging. Want zoals Henri al aangeeft gaan de kosten hier vaak nog voor de baten uit waardoor network en in-memory database mede interessant worden door de dalende kosten van de infrastructuur met gelijk ook een stijgende behoefte aan prestatie en capaciteit. De vraag is echter wel waar het 'break-even point' ligt omdat, juist in de IT de eerder gekozen oplossingen nog weleens door voortschrijdende techniek ingehaald wordt.

@Ewout
Dat klopt en de meeste grote SAP klanten zijn nu bezig met HANA pilots.
HANA systemen zijn complexe en prijzige appliances en de DB maturity ontbreekt nog, maar de trend is niet te stoppen.

@ KJ,

HANA lijkt mij een leuk concept. Maar creeert natuurlijk wel weer een extra vendor lock-in.

@Ruud
Het concept is fantastisch. Wat vendor lock-in betreft, zie : http://www.saphana.com/docs/DOC-2080 voor een verhaal over de licentiekosten. De appliance wordt geleverd door verschillende hardware partners : HP, IBM, Cisco, Dell, Fujitsu, Hitachi, NEC.
http://www.bluefinsolutions.com/insights/blog/the_sap_hana_hardware_faq/

Wat een enorm warrig artikel waar heel veel termen worden beschreven die op onduidelijke manier samenkomen, zoals ACID compliancy, Scale-up vs partitioning, gestructureerde data vs ongestructureerd, Cloud of niet, ransomware etc. Er worden woorden gebruikt die niet passen; er is geen paradox, geen debacle, het woord 'locking' bij consistency klopt in deze contekst niet. Verder worden er matige voorbeelden gebruikt: "Nu is dat niet erg bij de database van een webshop, maar minder gewenst bij financiële transacties." : bij webshops vinden wel degelijk financiele transacties plaats, beter is te zeggen: "Social Media" ipv webshops.

Verder zijn er zinnen die niet goed geformuleerd zijn:

"Zo legt de querytaal SQL, ooit bedoeld om gebruikers de mogelijkheid te geven om hun data te analyseren, geen expliciete relaties"

Zowel in de onderliggende verzamelingenleer alsook de implementatie in DDL zijn er juist wel relaties gelegd. Vandaar de R in RDBMS.

En bij de laatste alinea vraag ik mij oprecht af of je zelf wel weet wat je probeert uit te leggen.

verder:
"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."

Mijn ervaring is dat dit onderwerp minder thuishoort in een discussie over RDBMS vs NoSQL of Cloudoplossingen of andere technologieen, maar meer gaat over de intelligentie van mensen en organisaties.

tot slot: ik probeer niet je expertise ter discussie te stellen, maar een helder betoog houden en helder formuleren is m.i. hier niet gelukt.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×