Sådan skifter Det Fælles Medicinkort fra MySQL til NoSQL

GOTO: Deltagerne på GOTO-konferencen i Aarhus kan blandt andet høre, hvordan man bruger en NoSQL-database til at få en høj oppetid. Få en faglig smagsprøve her.

Trifork udvikler softwaren til det Fælles Medicinkort. Og udfordringen har blandt andet været, hvordan man opbevarer alle inputtene, har en oppetid på gerne 100 procent, får mulighed for effektiv fejlfinding og hurtige opslag i databasen.

Indtil nu har det Fælles Medicinkort kørt på en MySQL-database, men hurtigt stod det klart, at de store mængder af data gav problemer med at vedligeholde databasen.

Læs også: Derfor er Fælles Medicinkort en it-succes: Intet abe-skubberi mellem leverandører

Trifork har således migreret dele af systemet fra en MySQL-database til en NoSQL-database, og det vil Kresten Krab Thorup fortælle om på dette års GOTO:

»Udfordringen som mange kæmper med, når de skal gøre det her, er, hvad skal man helt praktisk skal gøre gribe det an. Hvordan laver man skemadesign med NoSQL? For hvilke skemadesign for NoSQL-databasen, skal der være? Der er en masse arbejdsgange, som skal laves om,« siger han til Version2.

Gode råd

Derfor har den tekniske chef nogle gode råd til andre, der også vil migrere over til en NoSQL-database:

»Man bliver nødt til at modellere sine data på en anden måde, fordi man basalt set ikke har nogle ACID-transaktioner. Og man er også nødt til at forberede sig på, hvordan man vil søge på de her data. I en NoSQL-database designer man sin datamodel efter, hvilke søgninger der skal være hurtige og laver performanceforskel på dem, der er designet ind.«

Derfor skal man tænke meget i design og funktionalitet, er hans råd.

»Så man skal også overveje, hvordan man laver alle de her traditionelle ting, som ad hoc-queries, historik og versionering af data,« siger han.

NoSQL kommer fra den type infrastruktur, som Google og Amazon bruger til at skalere med. Amazon udviklede oprindeligt infrastrukturen, fordi virksomheden mistede læssevis af penge på, at kundens indkøbskurv gik tabt, fordi systemet ikke kunne klare loaden.

MySQL har en øvre grænse

Problemet med MySQL-databaser er, at de er sværere at skalere end vedligeholde i forhold til NoSQL. For når man kører på én stor MySQL-database, når man hurtigt en grænse for, hvor mange hændelser databasen kan klare, og hvilke ændringer man kan lave i applikationen, når den skal være tilgængelig hele tiden. Og det var netop det, der skete for det Fælles Medicinkort.

»Vi var ved at nå grænsen for, hvad man kunne proppe i den en enkelt database-instans – det er jo ikke receptmængden i sig selv, der er problemet, men det er alle hændelserne og logningen, der bliver til meget data,« siger han til Version2.

Trifork bruger en open source NoSQL-database, som hedder Riak. Og Kresten Krab Thorup mener, at der både er fordele og ulemper ved at migrere til en NoSQL, men i forhold til det Fælles Medicinkort, var det helt klart smart.

»Riak har den fordel, at hvis man vil have mere kapacitet, kan man koble en ekstra computer på, og gøre den til en del af databasen og fordele data over på den. Så det er ikke noget med, at man skal omprogrammere sit system til at dele loaden ud over den. Så skalerbarheden er lineær, og det er en væsentlig bevæggrund, for vi kommer til at have mere og mere data,« siger han til Version2.

Netværket kan sætte ud

Kresten Krab Thorup understreger også, at det er vigtigt at designe sin database, således at man altid som udgangspunkt går ud fra, at maskiner brænder sammen.

»På den måde får man gennemtvunget sådan en mentalitet, at man går ud fra, at der vil være problemer. Og det nytter jo fx ikke noget, at man ikke kan udskrive recepter i det ganske land, fordi en maskine går ned. Det er ligesom en grundindstilling i softwaren,« siger han og fortsætter:

»Det ændrer på den måde, man tænker på. Man går ud fra, at alt kan gå i stykker hele tiden. Jeg er vokset op i en pc-æra, hvor man tænker én mand, én computer, og det er der mange, der er. Os der er voksne, professionelle programmører, vi er ikke genetisk kodede til at tænke i at køre på flere computere, og det skal man lære.«

Hans anbefaling er derfor, at man altid designer sin database som sit database-setup ud fra en betragtning om, at systemet er kritisk for andre forretningsfunktioner, så det for eksempel kan holde sig oppe, selv om dele af netværket forsvinder. Der kræver, at systemet kan håndtere skrivekonfllikter, hvilket kan opstå, hvis netværket har været nede, og flere udgaver af databasen skal synkroniseres.

Det vil sige, at der kan være to forskellige informationer, og det skal databaserne i din applikation kunne håndtere.

»Fordi systemet er så stort og kører så mange transaktioner, så sker der alle mulige mærkelige ting. Så når systemet opfører sig mærkeligt, er det et spørgsmål om at kunne håndtere forskellige komplikationer, for eksempel hvis der er netværksfejl, hvor de forskellige maskiner ikke kan se hinanden,« siger han.

Version2 er mediepartner på GOTO.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lean Fuglsang

Jeg synes det giver mening at skelne mellem SQL og NoSQL. Hvilken SQL eller NoSQL implementation man vælger er så en implementeringsdetalje, men det overordnede valg siger noget om hvilken type applikation man kan udvikle. Jeg tror ikke udviklerne på projektet har sagt, aah vi skal bruge Riak, det er pudsigt nok en NoSQL database. De har sagt, vi skal bruge en NoSQL database, og vi undersøger markedet, og Riak ser ud til at være et nogenlunde fornuftigt valg. Så super artikel!

  • 1
  • 0
Morten Bøgh

Altså: Fordi MySQL har skaleringsproblemer bliver man nødt til at forlade brugen af SQL. Så: Over i NoSQL hvor man så har problemet med at databasen ikke har native support for ad-hoc søgninger. Det må man selv sørge for at ens systemdesign håndterer (Dvs. det bliver netop ikke ad-hoc).

Kære kollegaer: Der findes professionelle SQL databaser såsom DB2 og Oracle. Sådanne systemer driver fx. Bank of China med 380 millioner konti. Hvor ordet 'professionel' i denne forbindelse betyder at systemerne koster kassen, men de leverer varen. Bl.a. har de ikke skaleringsproblemer.

Ideen i brug af en professionel SQL-database er netop at man som programmør ikke skal tage stilling til loadbalancering på flere maskiner, håndtering af maskinnedbrud, ad-hoc søgninger, skalering fra test-system til produktionssystem, udvidelse af ens datagrundlag med begreber som i øjeblikket ikke er kendte - etc. Det har man folk til. Pointen er ikke at man har folk til det, pointen er at man ikke selv - som programmør - skal tænke det igennem på forhånd, samtidigt med at man udvikler sit system. Hvis man vil gå Bank of China i skoene, skal man også have en mainframe, og af samme grund som for SQL-basen: man får en langt bedre adskillelse mellem systemprogrammør-siden og applikations-udviklingssiden: man kan lege parallelt, man har ikke alle bolde på samme bane.

En vej til lidt flere succes'er indenfor edb-udvikling er at minimere antallet samtidige bolde i luften.

  • 9
  • 5
Asger Solvang

Kunne være rart at få at vide "hvor stort" dette system virkelig er. Hvor mange tusinde transaktioner er der f.eks. i sekundet og hvor komplicerede er de? Hvor store datamængder taler vi om der skal lagres? Hvor mange tusinde samtidige brugere er der af systemet?

  • 3
  • 0
Niels Wind

Jeg har arbejdet med Oracle siden '88 og er nok ikke helt enig i at man ikke skal tage stilling til performance, skalering etc. :-) Måske fordi min erfaring er at det mest effektive er både at kunne tage rollen som udvikler eller/og dba.

Men derfra og så til at affærdige NoSQL artitekturen pga de gode gamle professionelle databaser, synes jeg ikke er logisk. Der er jo heller ikke alle der har penge som Bank of China. Ideen med at bruge standard 'beige-box' maskiner til at skalere med er da interessant, når husker at tage begrænsningerne med i overvejelserne.

Gad vide hvad priserne hos Amazon AWS f.eks. ville have været hvis de havde brugt Oracle som basis for S3, i stedet for Dynamo? :-).

Det er nye spændende tider, og selv Oracle har øjnet NoSQL http://www.version2.dk/artikel/oracle-vil-bruge-memcached-til-faa-mysql-...

  • 6
  • 0
Daniel Udsen

Sådanne systemer driver fx. Bank of China med 380 millioner konti. Hvor ordet 'professionel' i denne forbindelse betyder at systemerne koster kassen, men de leverer varen. Bl.a. har de ikke skaleringsproblemer.

Og du er sikker på de ikke bruger IBM's gamle NoSQL system IMS til at styre meget af det data.

En ting der glemmes i detbatten er at mainframen realt var en noSQL platform og at mange af de ting som folk stadigvæk bruger dem til er de roller hvor det er besværet værd at binde applikation og database sammen.

NoSQL er moderne nu og jeg er sikker på at det er bedre end MySQL når du rammer MySQL's rammer men det er måske relevant at sammenligne mere med systemer der realt er designet til at at skalere end netop MySQL

  • 0
  • 0
Karsten Thygesen

Det er lidt trist, at der er så stor fokus på scalering og performance når der tales NoSQL. Scalering er selvfølgelig vigtig, men er absolut ikke eneste grund til at vælge fx. Riak.

Riak tilbyder langt større redundans end traditionelle DBMS'er, da et nedbrud af en enkelt node (eller flere - afhængig af cluster størrelse) ikke har betydning for tilgængeligheden af det samlede system. Denne redundans er derfor uhyre vigtig for netop sundhedssystemer, hvor manglende tilgængelighed kan have menneskelige konsekvenser.

Riak tilbyder ydermere cluster til cluster replikering, så man ved to-center drift kan have aktive løsninger i begge driftcentre og rent faktisk få glæde af sit "stand by" setup i dag-til-dag brug. Det er der heller ikke mange DBMS'er der kan.

Cluster til cluster replikeringen kan endda gøre endnu komples i form af replikering imellem flere clustre i både stjerne og mesh topologier. Dette kan så udnyttes til distribueret drift, hvor løsningen kører aktivt i flere geografisk adskilte driftscentre og dermed kan man altså begynde at implementere løsninger, som er endda meget robuste overfor traditionelle nedbrudsscenarier.

Det er denne vision, som gør Riak særdeles spændende indenfor løsninger med høje krav til tilgængelighed.

  • 6
  • 0
Nicolai Møller-Andersen

Ingen ACID, ingen transaktioner, ingen relationer... blot et simpelt associativt array med lidt fejltolerance. Kan man overhovedet kalde det for en database? Så vidt jeg kan se, er noSQL og ægte RDBMS komplementære teknologier. Det er ligesom at sammenligne en hammer med en svensknøgle. Det er selvfølgelig smart, at en noSQL ikke går ned, men til gengæld ligger alle relationer jo i kodelaget, så hvis en stum kode går amok, er data smadret. Nå, men associative arrays har jo længe været rare at have i værktøjskassen. Man kan jo gemme hvad som helst i sådan et, og det er praktisk i moderne udviklingsprojekter, hvor man benytter max 14 dages udsyn, når man koder. Jeg siger ikke, at det er skidt; Associative arrays er simpelthen bare nødvendige i short cycle development, fordi man ikke aner, hvor man er på vej hen, når man starter.

  • 0
  • 0
Niels Wind

Riak tilbyder ydermere cluster til cluster replikering, så man ved to-center drift kan have aktive løsninger i begge driftcentre og rent faktisk få glæde af sit "stand by" setup i dag-til-dag brug. Det er der heller ikke mange DBMS'er der kan.

Cool! Sku' faktisk til at se på Cassandra, fordi den supporterer replikering mellem datacentre, men skulle måske kigge på Riak også så :-)

Og helt enig - data tilgængelighed er lige så interessant som skaleringen. Det ku' ske man fik brug for det først...

Har I forresten erfaringer med opdatering af Riak softwaren på kørende clusters? Så vidt jeg ved kommer man stadig ud for med Oracle RAC at skulle lukke det hele ned, alligevel. (her kunne multi-datacenter/cluster replikering måske redde en hel del)

  • 1
  • 0
Log ind eller Opret konto for at kommentere