Skip to end of metadata
Go to start of metadata

Grunnide: Gitt de åpenbare kravene til systemer alà altinn,

a) hvorfor er db-sentrisk og batch-orientert arkitektur feil vei

b) hvilke egenskaper bør være grunnleggende drivere,

c) hvilke arkitekturbyggeklosser og patterns er aktuelle for denne typen systemer

Rapport fra DNV om altinn: http://www.regjeringen.no/upload/NHD/Vedlegg/Rapporter_2012/altinn_sluttrapport_20120321.pdf Se spesielt kapittel 5.5.

"Økende datamengde vil gi begrensninger i backup mulighetene. Datavolumet som det tas backup av er i dag på 8,8 Terrabytes (TB). Backup tar 12 timer og vil øke med økende datamengder (ref figuren under). En plan for hvordan fremtidige datavolumer skal håndteres har vi ikke funnet."

"Det er ennå ikke forsøkt å deploye i fart. Deploy innebærer dermed nedetid. Man må ta ned systemet ved deploy fordi databasen må oppdateres ved hver deploy og stenger da for andre brukere, komponentene er ikke designet med versjonsnummer og systemet håndterer ikke flere samtidige versjoner av komponenter."

Systemet synes ikke designet for å håndtere store datamengder da batchkjøring reduserer responstid
bl.a. ved bruk av basen, og det ikke er mulig å kjøre parallelle batcher, slik det er i Altinn 1. Dagens
vindu er i ferd med å gå fullt, og med forventet økning i datamengde vil det sannsynligvis føre til
behov for batchkjøring på dagtid med tilsvarende vanskeligheter med å opprettholde responstid på 3
sekunder.

"I litteraturen som beskriver databasesentrisk arkitektur sies det
at skalering gjennom økning av HW fungerer kun i en viss grad, etter et gitt punkt må skalering også
omfatte redesign av komponenten"

"Stored procedures er i seg selv
ikke et problem men en vanlig måte å organisere felles databaseoperasjoner ved at prosedyrene legges
i databasen. Dette gjøres ofte for å forenkle og for å forbedre responstidene i systemet. "

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 22, 2012

    a) Multi/cross database arkitektur
    Ulik trafikk (system/sluttbruker) vil påvirke ytelse til mange tjenester/komponenter med begrensede muligheter for throttling. Det skaper gjensidige avhengigheter mellom komponenter (som er det motsatte av hva man vanligvis vil oppnå med modularisering). Overbelastning av en enkelt database kan medføre dårlig ytelse på tvers av komponenter. På sikt skaper det store problemer med videreutvikling/forvaltning og drift av systemet dersom ting er for tett koblet mot hverandre. Oppetid blir et minste felles multiplum.

    b) Løskobling av komponenter/tjenester. Skille mellom sluttbrukers mål (eventuellt splitte disse i kategorier) for bruk av tjenesten og systemeiers

    c) Se Service Categorization på denne wiki

    Et viktig moment er at sluttbrukerne i all hovedsak gjør Read-operasjoner, og burde ikke bli påvirket at systemdrevne skriv-operasjoner.

    Forslag: Data som må være oppdatert i sanntid er nok begrenset, og burde separeres fra et read-only storage. Read-only storage kan oppdateres regelmessig. Dersom man har 2 alternerende read-spaces kan man oppdatere ett mens det andre er online, så switches det slik at man kan bygge opp nytt read-storage.

    1. Mar 22, 2012

      Ref. read-only-tanken din, Dag. Jeg vil tro en god del av ytelsesproblemene ifbm. selvangivelsen legges ut er basert på et(!!) tall, dvs. "min saldo". Burde være mulig å få tilgang til det uten å måtte logge seg på et komplekst saksbehandlersystem som skal håndtere alt fra fiskeeksport til Selvangivelsen til Kenneth.