Database debacle in de cloud

We kunnen eindeloos blijven schrijven, praten en dromen over de cloud maar het gaat maar om één ding, namelijk de data welke 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. Geen data, geen service en geen business.

In traditionele architecturen zit data vaak gestructureerd in databases en kan gevonden worden met Structured Query Language (SQL), de standaardtaal waarmee meeste 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 om gaan 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 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. 

http://blogs.the451group.com/information_management/2012/12/20/database-landscape-map-december-2012/

Dat terwijl er altijd al meer keuze was maar bepaalde techniek wat op de achtergrond is geraakt. De mainframe is dood maar lang leve de netwerk database als alternatief voor SQL. Want hoe nieuw zijn hippe oplossingen zoals Cassandra, DynamoDB of de vele andere NoSQL oplossingen, de non-relationele datastores waar zoveel ophef 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 tegen vallen. 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?

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 de snelheid van het licht soms nog niet snel genoeg is.