Case study Databaseoptimalisatie
DATABASE-OPTIMALISATIE Bedrijven kunnen niet zonder goede databases. Zij vormen de lijm die de boel bij elkaar houdt. Steeds meer vormen complexe en krachtige databases het hart van de complete informatiestroom binnen grote organisaties. Keerzijde van de medaille is dat wanneer er problemen zijn met de toegang tot de benodigde gegevens, er als eerste direct naar de database gekeken wordt. De database is namelijk door de jaren heen uitgegroeid van een eenvoudige manier om gegevens op te slaan en op te vragen naar een multifunctioneel monster. De nadruk ligt niet langer op eenvoud, maar op de vraag of de database wel geavanceerd genoeg is. Deze verschuiving zorgt voor veel problemen, zegt senior analist Marcus Collins van de Burton Group.
“Het moet benadrukt worden dat databases echt heel complex zijn. Je kunt bij het selecteren van het data management-systeem en ontwikkelplatform goede keuzes, maar ook verkeerde keuzes maken.” Volgens Collins is het zaak om een paar fundamentele beslissingen te nemen. Daarbij moeten in het begin een aantal simpele vragen worden gesteld. “Waar zet je de code neer, in de database zelf of in de middelste tier?” Dus in de ict-laag tussen data-opslag (de database) en data-gebruik (applicatieservers). Je kunt op heel veel verschillende plekken beginnen met optimaliseren, maar het is moeilijk om vast te stellen waar je moet beginnen.”
John Goodson en Rob Steward schrijven in The Data Access Handbook dat het probleem vaak niet bij de
database zelf ligt, maar bij de manier waarop toegang wordt verleend tot de gegevens. Ze wijzen erop dat bedrijven ieder jaar duizenden of zelfs miljoenen euro’s besteden om problemen op te lossen, om vervolgens opgescheept te worden met capaciteitsperikelen. Die kunnen opduiken als alle aandacht uitgaat naar capaciteitsproblemen van de database, en geen tijd wordt besteed aan het ontwikkelen van applicaties
Case study
die gericht zijn op de gegevens zelf en het verfijnen van de code.
Databaseoptimalisatie
Collins, Goodson en Steward leggen daarmee de vinger op de zere plek. Het oplossen van prestatie
problemen met databases is niet hetzelfde als het repareren van een auto, waarbij een probleem terug kan worden geleid tot twee of misschien drie onderdelen. Het is ook niet hetzelfde als het oplossen van een probleem met het netwerk, waarbij de beheerder meestal een goed gedefinieerd stappenplan kan afwerken/ doorlopen om de pijnpunten te isoleren. Bij moderne databasesystemen ligt het probleem bij de interconnectiviteit zelf.
Ronan Miles, voorzitter van de Engelse Oracle gebruikersgroep, omschrijft dit als een domino-effect.
“Als je een wijziging doorvoert of een index toevoegt aan het ene deel van een database, dan kan dat funest uitpakken voor een ander deel van de database. Waardoor hij onbedoeld juist langzamer wordt.”
Dat is de kern van het probleem, en het is de reden waarom het tweaken van de software om optimale
prestaties te krijgen zo verdraaid lastig is. De software kan dusdanig worden geschreven dat alles perfect in elkaar steekt. Maar bij een verandering kan het hele systeem imploderen.
Deze situatie komt perfect terug in de beschrijving van de maatschappij door Ulysses in de Shakespeare-
tragedie Troïlus en Cressida: “De hemel zelf, de dwaalsterren, dit centrum, eerbiedigen ieders rang, voorrang en plaats, loop, draaipunt, vorm, verhouding en seizoen, taak en gewoonte, naar de wet der orde.” Maar als de databases niet naar behoren presteren, of op zijn minst enigszins efficiënt werken, dan moet je kijken naar de losse elementen. Dat kan de software als geheel zijn, het platform waar het op draait of de manier waarop alles aan elkaar gekoppeld is.
Dit is makkelijker gezegd dan gedaan. Het isoleren van problemen in een bedrijfsbreed databasesysteem
is niet iets dat je kunt beschrijven in een enkel artikel. Er zijn hele boekwerken verschenen over hoe je databases kunt verfijnen en configureren om de prestaties op te krikken. Een eerste actie die dikwijls wordt ondernomen bij traagheid van het database, is een upgrade van de server of netwerk. Maar het is zelden de beste aanpak, ondanks dat de prijs van processorkracht blijft zakken en ook bandbreedte goedkoper wordt. Het mag dan wel niet zo’n dure aangelegenheid zijn als pak ‘m beet 10 of 15 jaar geleden, maar CIO’s zijn tegenwoorden attenter op het efficiënt inzetten van processorkracht. En ze houden zich al helemaal bezig met het omlaag krijgen van de energiekosten.
>> pagina 2
Een mogelijke omzeiling van dit probleem is het inzetten van virtuele servers. Maar ook dit is niet altijd de beste oplossing. Een bedrijf dat virtuele servers gebruikt om zijn databases op te draaien moet er bijvoorbeeld niet automatisch van uit gaan dat het toevoegen van rekenkracht helpt omdat het overprovisioneren van een virtuele machine met cpu’s juist voor vertraging kan zorgen. Dat komt door het werk dat het systeem uitvoert bij het verdelen van de last tussen de processors. Die overhead kan de toegevoegde rekenkracht teniet doen. Bij het tweaken en afstellen van databases bestaan er dus een aantal uitgangspunten die je moet onthouden. Het eerste waar je volgens Miles op moet letten, is dat je altijd naar het eindresultaat toe dient te werken en je dus niet doelloos moet gaan zitten rommelen. “Je moet weten wanneer je ermee moet kappen”, zegt Miles. Je kunt altijd door blijven gaan, maar je zult toch een moment moeten vinden om te stoppen. Daarbij lijkt het een beetje op verantwoord gokken, waarbij je voor jezelf moet vaststellen hoeveel je precies kunt verliezen. Miles trekt een wat dramatischere vergelijking. “Het is als crack”, zegt hij. “Het is nogal moeilijk om af te kicken.” Het is volgens Miles ook belangrijk om je te beperken tot doorvoeren van één verandering tegelijk.
“Je moet niet met hagel schieten, maar als een ingenieur denken en bij iedere verandering kijken wat er gebeurt. Wees vooral niet bang om de veranderingen ongedaan te maken.” Collins van Burton raadt aan om als eerste te kijken naar de onderliggende architectuur. “De beslissing met welke architectuur wordt gewerkt is voor veel organisaties al direct een probleem”, zegt hij. “Ze hebben vaak ook heel veel keus: welk database moeten ze nemen? Moet hij op een enkel systeem of over meerdere systemen worden uitgerold? Gaan we Exadata voor warehousing inzetten of niet? Een product kan op verschil lende manieren worden ingesteld, en bedrijven weten niet goed wat ze moeten doen. Als ze eenmaal een keuze hebben gemaakt, dan kunnen ze ook niet meer terug.”
Daarom is de planning volgens Collins een van de sleutelelementen voor het optimaliseren van de
database. “Je moet goed weten wat de doelen zijn voor de komende twee of drie jaar, niet alleen voor de komende zes maanden”, zegt hij. De onderverdeling van gegevens is een voorbeeld. Zo kan een winkelketen
Case study Databaseoptimalisatie
ervoor kiezen om gegevens te verdelen naar regio of naar individuele winkels. Als er iets gebeurt, een wijziging in bedrijfsstrategie bijvoorbeeld, kan die onderverdeling op de schop. Zonder planning is het tegen die tijd al te laat om er eentje op te zetten. Of wat als het bedrijf plotseling heel veel successen boekt en het aantal gebruikers verdubbelt, kan het systeem dat aan? Collins hanteert tijdens de ontwikkeling een simpele vuistregel om tot een bruikbare architectuur te komen. “Denk aan de afkorting RAMPS: Reliable, Available, Manageable, Perform well en Scalable.” Een van de eenvoudigste methodes om de prestaties van queries te verbeteren is het direct aanmaken van efficiënte indexen zodat niet de hele databasetabel gescand hoeft te worden. De database zal dan de relevante informatie afwegen en opslaan in de geïndexeerde kolom. Deze statistische informatie wordt vervolgens gebruikt om de optimale benadering van een query vast te leggen. De zoektijd wordt zo flink teruggebracht, omdat slechts een kleine subsectie van de gehele database hoeft te worden doorzocht. Indexen kunnen dus de prestaties van grote, logge databases flink versnellen. Maar toch zitten er volgend David Cartwright, netwerk- telecom- en hostingmanager van financieel bedrijf CPA Global, een aantal addertjes onder het gras. “Meer schijfruimte is een minder groot probleem als vroeger, maar het speelt wel mee. En belangrijker nog: iedere index van een tabel moet worden geactualiseerd op het moment dat je een INSERT, UPDATE of DELETE uitvoert. Te veel indexeren kan de prestaties van een database tot een dieptepunt brengen als gebruikers meer moeten doen dan alleen de gegevens uitlezen.” Iets anders speelt volgens hem ook een rol. “Sommige optimalisatiefuncties, zoals defragmentatie van de indexen, kan de tabel voor een lange, lange tijd vastzetten.” DBA’s (database-beheerders) willen dit nog wel eens vergeten en de opdracht geven om de database te rebuilden. De applicatie kan dan soms uren achter elkaar onbereikbaar zijn. Cartwright zegt verder dat je bij het verbeteren van database-prestaties niet te diep moet gaan tijdens de zoektocht naar problemen. Hier geldt Ockhams scheermes: het beste antwoord is het antwoord dat het
>> pagina 3
meest voor de hand ligt. “Als de database niet functioneert zoals dat zou moeten, zoek dan eerst naar de meest eenvoudige oplossingen. Ga niet zitten morrelen met ingewikkelde prestatiemetrieken en diepgaande tests voordat je de basisdingen hebt gedaan, zoals het controleren van de I/O-parameters van de schijven, de cpu-last, geheugen, of de antivirus staat ingesteld op ‘scan bij toegang’, enzovoorts”, zegt hij. De experts zijn het erover eens dat het voor alle grote ondernemingen belangrijk is om analysetools te gebruiken. Modelleringtools zijn volgens Collins van Burton de perfecte oplossing om veranderingen mee te plannen. “De database-leveranciers hebben een paar krachtige tools ontwikkeld. IBM heeft een hele krachtige voor DB2. Die van Oracle is iets laagdrempeliger, maar werkt ook naar behoren. Als je met een derde partij in zee wilt gaan, dan kun je bijvoorbeeld Embarcadero proberen. Maar je hebt ook anderen.” Cartwright van CPA snapt niet waarom er nog steeds organisaties zijn die zich hier terughoudend in opstellen. Tools kunnen een keur aan diagnostieke capaciteiten bieden, “en toch worden ze door veel organisaties niet gebruikt, of vaker nog: ze weten niet van het bestaan af of weten niet hoe ermee om te springen. Ze tasten bij optimalisatie volledig in het donker.” Ook normalisatie speelt een uiterst belangrijke rol. De klassieke theorie rond databases luidt dat ze zoveel mogelijk moeten worden genormaliseerd. Gegevens moeten zo efficiënt mogelijk worden gepresenteerd, zonder redundante data, en iedere tabel moet alleen de gerelateerde gegevens bevatten. Maar hoewel normalisatie volgens Cartwright in theorie een uitstekend idee is, kun je daar ook in doorschieten. “Een beetje denormalisatie zal de prestaties juist goed doen, want anders krijg je belachelijk langdurige JOINs in je queries. Denk dus niet dat normalisatie automatisch staat voor verbeterde prestateis, want dat is lang niet altijd zo.”
Cartwright zegt ook dat veel databaseproblemene helemaal niet technisch van aard zijn, maar voort
komen uit kantoorplitiek. Hij wijst vooral naar bedrijven die aan het beknibbelen zijn door niet-professionele DBA’s in te zetten, en neigen naar “het uitrollen van een product zonder deze eerst te optimaliseren omdat dat minder belangrijk lijkt dan andere projecten die in de begroting moeten. Dit kan uiteraard een grote vergissing zijn”, zegt hij.
Collins van Burton wijst op een andere organisatorisch probleem dat dikwijls wordt genegeerd.
“Het traditionele databasebeheer gaat uit van twee bedrijfsonderdelen: een ontwikkelings-arm en een productie-arm. Het ontwikkelteam schrijft de software, en gooit het ergens over de schutting.
Case study Databaseoptimalisatie
Het productieteam moet het daar oppakken. Dat betekent dat dingen als de index pas op dat moment worden gevormd. Die schutting is kunstmatig en moet worden verwijderd”, zegt hij. “voeg operaties en ontwikkeling samen zodat ze allebei in een vroeg stadium betrokken zijn.”
Als de database eenmaal volledig geoptimaliseerd is, betekent dat niet dat je klaar bent. Er is altijd ruimte
voor verbetering. Ronan Miles heeft nog een advies voor de techneuten onder ons: “Hou je vaardigheden up-to-date. Bezoek beurzen, praat met experts en blijf vooral doorleren.” Wie zijn database maximaal efficiënt wil krijgen, moet zijn infrastructuur dus vanaf het begin op orde hebben. Planning is daarbij het belangrijkste: met het kiezen van de juiste architectuur, het rekening houden met groei en het inzetten van de juiste mensen op de juiste plek kom je al een heel eind. Technieken als normalisatie en indexering dragen hun steentje bij, maar pas op voor de valkuilen. Zorg ervoor dat je de juiste vaardigheden in huis hebt en houdt deze goed bij. Goede databaseoptimalisatie moet het hebben van de samenwerking tussen veel verschillende elementen. Zo niet, dan zou Shakespeares Ulysses (die in dit tijdperk een uitstekende database-ontwikkelaar zou zijn) zeggen dat “het bedrijf ziek is”. Goede databaseoptimalisatie houdt in dat de ziekte wordt genezen voor hij verder verspreidt.
>> pagina 4
BOXOUT: De tien grootste fouten 1 Geen langetermijnsplanning Het is onvoldoende om een database voor het hier en nu te plannen. Een verstandige ontwikkelaar denkt van tevoren na over wat het bedrijf in drie tot vier jaar nodig gaat hebben. Het is vaak niet eenvoudig om een database-architectuur te wijzigen, dus denk goed na voor je begint met de implementatie. 2 Indexeren tot je erbij neervalt Geen moment kiezen om te kappen met al dat gerommel, en maar door blijven gaan. Ontwikkelaars moeten goed voor ogen hebben wat de doelen zijn bij het indexeren, en hun doel niet voorbij schieten. 3 Het domino-effect Dit sluit direct aan op het vorige punt. Een verandering kan negatieve gevolgen hebben voor een ander onderdeel van de software, waardoor het moeilijker wordt om vast te stellen waar een bepaald probleem vandaan komt. 4 Niet technisch denken Als je veranderingen doorvoert, doe dan één verandering tegelijk. Probeer in te schatten wat er gebeurt, en probeer ook je eigen tweakers-kunde in te schatten. 5 Geen expertise gebruiken Database-ontwikkeling en -beheer zijn allebei een vak, en er is een groot gebrek aan bekwame vaklieden. Hoewel het inderdaad heel moeilijk is om goede mensen te krijgen en te behouden, is het belangrijk om hier halfslachtig mee om te gaan. En, misschien nog belangrijker: zorg ervoor dat je vaardigheden actueel blijven door regelmatig conferenties te bezoeken en de literatuur te lezen.
Case study
6 Geen analysetools gebruiken
Databaseoptimalisatie
Er zijn heel veel tools te krijgen die je enorm kunnen helpen bij het optimaliseren van je database. Sommige komen van de leverancier zelf, anderen zijn door derden ontwikkeld. Gebruik ze. Ze kunnen een enorme hulp zijn bij het oplossen van de veel voorkomende problemen. 7 Rücksichtlos normaliseren Normalisatie maakt een belangrijk deel uit van de huidige database-ontwerpen, maar wees hier voorzichtig mee. Schiet niet door, want dit kan voor heel veel nieuwe problemen zorgen. 8 Geen samenwerking tussen ontwikkeling en productie Er bestaat binnen de meeste bedrijven een scheiding tussen database-ontwikkeling en het productieteam. Maar in veel gevallen is dit een kunstmatige grens, en meer en meer bedrijven kiezen ervoor om deze te verwijderen. Als dat niet mogelijk is, zorg er dan tenminste voor dat de twee groepen nauw samenwerken. 9 Slordige documentatie Een bekend gegeven is dat ontwikkelaars niet heel goed in het aangeven wat er is gedaan, door wie en waarom. Het uitvogelen hoe alles ook alweer in elkaar zat kan een ontwikkelaar die later betrokken wordt bij het project flinke hoofdpijn opleveren. Het is daarom beter dat het meteen goed gebeurt. 10 Onvoldoende rekenkracht Goed, dit mag dan nog steeds het eerste zijn waar direct naar gekeken wordt als een database spaak loopt, maar het is zeker een geldig probleem. Als al het andere niet helpt, dan moet je kijken of het echt niet de onderliggende server of netwerk is die de problemen veroorzaakt.
>> pagina 5
