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.
@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.