Ingenting er mer frustrerende enn å sitte og vente på at et IT-system skal reagere på en forespørsel. En faktor som bidrar til lange responstider, er at applikasjonen som behandler forespørselen, selv venter på å få relevante data fra en database.
Tangosol oppfant en løsning på denne utfordringen: Deres produkt Coherence legger opp en serverklynge med samspilt minne, og bruker dette minnet som distribuert cache – mellomlager – for alle databaseobjektene. I stedet for å henvende seg til databasen, forholder applikasjonene seg til dataobjektene i det Tangosol kaller «Data Grid».
Denne datagriden kan utvides etter behov for å håndtere spørringer, datamodellering, forretningslogikk og til og med automatisk hendelsesdrevet prosessering på dataobjektene.
Egne mekanismer sørger for at alle endringer i databaseobjektene synkroniseres med hverandre og med databasen, på en så sikker måte at det aldri skal være fare for inkoherens.
I våres ble Tangosol kjøpt av Oracle, og i sommer ble hovedproduktet oppgradert til Coherence 3.3. Coherence utgjør i dag et vesentlig tilskudd til Oracles mellomvare, og Tangosol-teknologien ble viet betydelig oppmerksomhet under presentasjonen av den nye databasen 11g.
Da Oracle Database 11g ble høytidelig presentert i Oslo nylig, fikk digi.no møte tidligere toppsjef Cameron Purdy i Tangosol, i dag visepresident i Oracle. Vi ba ham forklare nærmere hva løsningen innebærer.
– Vi betegner vår teknologi for «in memory information management» [håndtering av informasjon i minne]. Det har mange likheter med en database, men det er to viktige forskjeller.
Den første forskjellen, er at Tangosols løsning ikke behøver å bry seg om den varige oppbevaringen av informasjon.
– Vi er opptatt av å gjøre data tilgjengelig for applikasjoner i det øyeblikket forespørselen er der. Det er i databasen at informasjon oppbevares for å vare. Det fleste anvendelsene av vår programvare innebærer at man også har en database.
Den andre forskjellen er at Tangosol betrakter informasjon som objekter.
Vi forholder oss til ustadige objekter, ikke varige relasjonelle data. – Vi forholder oss ikke til relasjonelle data, men til objekter, altså data presentert på den måten applikasjonene vil ha dem. Altså er ustadige objekter grunnlaget for vår tilnærming.
Når grunnlaget er gitt, gjenstår ganske mange utfordringer.
– Vår teknologi inngår i mellomvareløsninger for systemer med mange titalls eller mange hundretalls applikasjonsservere, som alle trenger øyeblikkelig tilgang til den samme store mengden informasjon. Vår løsning består av programvare som baserer seg på klynger og grid for å gjøre informasjonen tilgjengelig for hver server der applikasjonen kjører.
I løsningen lages det mange kopier av dataobjektene: Det bidrar til både rask tilgang, og til immunitet mot svikt i maskinvarekomponenter.
– En annen egenskap er at løsningen vår sørger for å spre databaseobjektene på en slik måte at de skal befinne seg der de kan aksesseres raskest.
Purdy mener denne løsningen i dag er unik.
– Vi sørger for øyeblikkelig tilgang til informasjon, konsistens i alle transaksjoner, uavbrutt tilgjengelighet, ingen avhengighet av komponenter som det bare finnes én av, og utrolig skalerbarhet: Hver ny server i datagrid øker ytelsen i det samlede systemet.
Skisse over «Enterprise Edition» av Data Grid i Coherence. Symbolene i sekskanten viser til at Data Grid brukes til distribuert felles minne, spørringer og modellering av data i minne, forretningslogikk og hendelsesdrevet prosessering på dataobjektene i minne.
Norske kunder omfatter teleoperatører, finansinstitusjoner, banker og oljeselskaper. Purdy nevner spesielt Statoil.
For å illustrere mer konkret hvordan dette virker i praksis, trekker Purdy fram et eksempel fra en onlinetjeneste innen forsikring.
– Tjenesten bygget på informasjon lagret i en Oracle database, og hadde som mål å gjøre kundene selvbetjente. Applikasjonen vedlikeholder all kundeinformasjon i én post per kunde. Teknisk virket dette slik at når kundene meldte seg på nettstedet, hentet applikasjonen all informasjon om vedkommende og la den i minne. Når kunden var ferdig ble alle endringer ført tilbake til databasen.
I denne formen virket alt hensiktsmessig.
– Problemene meldte seg etter hvert som stadig flere kunder tok tjenesten i bruk. Databasen ble overbelastet bare av å håndtere kundeinformasjon. Det ble ikke bedre da applikasjonen ble lagt ut i en egen klynge: Ordningen for lastbalansering kunne slå ut ved å sende hver forespørsel fra kunden til en forskjellig server. Det multipliserte antall ganger informasjon måtte lagres i databasen og hentes opp igjen.
Da Coherence ble lagt inn i systemet fikk man løst denne utfordringen.
I stedet for stadig å lagres og hentes på nytt fra databasen, lever endringene et trygt liv i det delte minnet. – Selskapet beholdt databasen og applikasjonen. Coherence gjør det mulig å la alle kundepostene leve i minne, slik at de er tilgjengelig for hver applikasjonsserver til enhver tid. I stedet for stadig å lagres og hentes på nytt fra databasen, lever endringene et trygt liv i det delte minnet. Lagring til databasen skjer batchvis og kontrollert, og belaster ikke ressurser som påvirker responstiden.
I prinsippet hadde det vært mulig å skrive om applikasjonen slik at den håndterte databasen mer effektivt. Purdy mener at det hadde vært umulig å oppnå den samme effektivitetsgevinsten ved å skrive om applikasjonen som ved å legge inn Coherence i den totale løsningen.
– Grunnen er enkel: Du kan ikke oppnå større effektivitet enn ved å sørge for at data alltid er i minne. Det er kanskje ikke så vanskelig å få applikasjonen til å gjøre det. Men så må du ta i betraktning alle tilleggsutfordringene som Coherence løser en gang for alle: Hvordan skal du sikre at all informasjon endres synkront? Hvordan skal du sikre deg at informasjon som endres alltid havner tilbake i databasen selv om en server eller to i klyngen skulle svikte?
