Services

Ontwerpen voor Performance

De noodzakelijke (ie. verwachte) verwerkingssnelheid van een applicatie hoort duidelijk te zijn bij aanvang van het ontwerp. Zelfs bij iteratieve projecten via SCRUM moet de basale info over hoeveel gegevens (records) er per batch of periode verwerkt moeten kunnen worden bekend zijn. Het weten van de verwachte noodzakelijke doorvoersnelheid is zelf wellicht nog belangrijker dan de functionele details. Voor DBAs zoals mijzelf is het aanhoren van gebruikers en managers die klagen over de lange tijd die het kost om query resultaten te krijgen (waar "lang" natuurlijk varieert tov de persoon die klaagt) een standaard deel van de dag.
Foute ontwerp beslissingen kunnen dramatische effecten hebben op de performance.
Bij voorbeeld :
Bij een klant had men een Java applicatie waarbij het Java team zelf het datamodel ontwerp had gemaakt zonder enige ruggespraak of consultatie met het DBA team. Het resultaat was een data model dat de facto een afslag was van het Object Oriented Java model dat binnen de applicatie werd gebruikt. De gehele applicatie werd ontwikkeld en getest met 10 producten er in en voor release goed bevonden. Tijdens de pre release testen werd de applicatie voor de eerste keer met een werkelijke toekomstige hoeveelheid data geladen. Daar waar de applicatie het leuk deed met 10 producten en klant, was de verwerkingssnelheid exponentieel slechter met de werkelijke data set. Aangezien de verwachte data set bestond uit 500k klanten en 40 producten, elk met ongeveer 40 relevante attributen, duurde het opeens 5 minuten om slechts 1 product verzoek af te handelen. Omdat hardware capaciteit tegen dit probleem aangooien om het op te lossen dramatische Oracle licentie kosten tot gevolg had was de enige oplossing weer vanaf scratch een nieuw data model te maken. Deze keer wel met ondersteuning van de DBAs.
Helaas kan ik enorm veel van dit soort voorbeelden geven uit mijn carriere. Een mooi voorbeeld over hoe dramatisch de verbeteringen kunnen zijn bij een correcte opzet en data model was een klus waarbij een Datawarehouse werd geladen via Oracle Gateway vanuit een DB2 Mainframe bron. Het gehele laad proces koste 60 uur waardoor het Datawarehouse enkel gedurende het weekend kon worden bijgewerkt. Ik heb een totaal nieuwe setup ontworpen met standaard ETL (Extract Transform Load) modellen gebruikmakende van directe EBCDIC file load via SQL*Loader. Files werden geladen direct op het moment dat ze beschikbaar waren en alle data werd op correctheid van het data type gevalideerd. De gehele verwerking was een autonoom waterval model waarbij processen direct konden starten indien processen waarvan ze afhankelijk waren gereed waren. Eind resultaat was dat de nieuwe opzet de gehele load, validatie en verwerking uitvoerde binnen 3 uur en elke proces individueel kon worden herstart indien er fouten waren. Een verbetering dus van een factor 20, hetgeen dagelijkse refreshes van het Datawarehouse mogelijk maakte ipv eens per week.

Het moge duidelijk zijn dat enige tijd vrijmaken voor ontwerp voor performance zijn kosten meer dan terugverdiend.