Drop Databasen August 14, 2007 00:12 over 3 years ago
Hvis din objektmodel er replikeret over flere VM’er, så er sandsynligheden for at alle crasher samtidigt, lige så lille som at DB’s diske crasher. Så kan man rent faktisk arbejde med crash-tolerant memory og antage at heap’en aldrig slettes. Det fjerner hele behovet for et data-access layer, for applikationens model er jo crash-resilient.
Det betyder at man kan droppe databasen og bruge memory i stedet.
Halvdelen af alle framevorks i Java handler om O/R mappingsproblemet og der er skrevet indtil flere design patterns som attakere netop dette problem som fx valuebean(VB) og datatransferobject(DTO) der er strukturelle mønster.
Enlig er det en ret enkelt og ligetil proces. Problemet er at det er trivielt og at vi i mange år skrevet tusind af klasser som gør præsis det samme. En såkaldt serverside programmør lever af at mappe tabeller og relationer i databasen til en objektmodel til trods trods for at tabeller og objekter er to vidt forskellige konstruktioner. Firkantede database tabeller passer ikke lige over til et rent objektorienteret paradigme.
Et par gode kolleger fra Javahouse tiden og jeg selv, inviterede Owen Taylor til Danmark for at tale i et par banker og i cybercomgroup headquarter. Owen er specialist i Giga Spaces teknologien. Det helt essentielle ved Spaces er hastighed og skalerbarhed. Men i tilgift får man en sjov afledt effekt. Et typisk forløb er at man preloader en mængte data fra databasen om morgenen hvorefter arbejdet begynder. Efter arbejdet kan man evt. gemmer nye data. Resten af tiden benyttes kun memory. Alle objekter er persistente og replikerede.
Eneste logiske grund til at opdatere databasen er at interaktion med legacy systemer. Selve spaces er aldrig nede.
Den helt store fordel er at man kan fjerne hele databasen og alle de gamle problemer med O/R mapping og hele dataaccess layer i den gammeldags software model.
Der er fortaget undersøgelser som viser at backend programmering(O/R mapping) tager ca. 60 procent af alt udviklingstid.
By Frank Vilhelmsen - 3 tags: architecture database scaling - Add comment