Et succesfuldt offentligt it-projekt: Udvikler-engagement har været afgørende

En system med adressetjeneste, der kan anvendes af f.eks. webshops, har gået trinvis til værks i udviklingen og prioriteret en intensiv dialog med it-udviklere. Det har skabt en succes, der roses af Version2-blogger

Midt i diskussionen om nedlidte, usikre, forsinkede og fordyrede offentlige it-projekter er der også eksempler, der skiller sig positivt ud.

Finn Jordal, specialkonsulent hos Styrelsen for Dataforsyning og Effektivisering

Et af dem er DAWA, Danmarks Adressers Web API (DAWA), et it-projekt, der som en del af Grunddataprogrammet tilbyder alle interesserede gratis adgang til autoritative data og it-funktionalitet om Danmarks adresser, vejnavne og postnumre til brug i it-systemer både i det offentlige og det private.

Det offentlige it-udviklingsprojekt har været i gang siden 2013, hvor starten på udviklingen af en prototype gik i gang med første release i 2014.

Man startede altså i det små med få brugere - eller opkoblede it-systemer - fuldstændig som f.eks. folkene bag MobilePay også på it-konferencer har fortalt om.

»Omverdenen havde ikke det store kendskab til DAWA, da det gik i produktion, så vi forsøgte ikke at begrænse antallet af anvendere – tværtimod. Men det har været en klar fordel, at vi har kunne lade DAWA udvikle sig driftsmæssig over tid til det større og større load,« siger Finn Jordal, der er specialkonsulent hos Styrelsen for Dataforsyning og Effektivisering, SDFE, der står bag DAWA.

Læs også: It-professor: Intet tyder på at milliarddyre it-skandaler i det offentlige er forbi

I dag forsyner DAWA 1700 it-systemer med adresser, har 200.000 unikke brugere om ugen - og håndterede 900 mio. requests sidste år.

Udvikling i antal anvendende web-applikationer per uge. Grafen dækker ikke alle anvendende it-systemer – kun web applikationer, som kalder DAWA fra browseren.

Det har dog været en lang rejse at nå dertil:

Det har været svært at udbrede kendskabet til et produkt som DAWA. Som grafen viser, gik der ca. et år før vi kunne se at vor omverden for alvor begyndte at anvende DAWA, siger Finn Jordal.

Ude fra set skulle man tro at en adresse er en adresse. Men sådan er det langt fra. Eksempelvis kan H.C. Andersens Boulevard i København skrives på mange forskellige måder med forskellig placering af punktummer og mellemrum.

Det er noget rod i en it-verden, fordi det skaber dubletter og behov for manuel sortering og datavask.

Det gælder f.eks. hos webshops, hvor gentagelse af samme adresse i it-systemer skaber uorden i kundedatabaserne. Men fejlbehæftede adresser kan også have mere alvorlige følger:

»Det kan have fatale konsekvenser, hvis en ambulance ikke kommer frem til det rette sted som følge af en misvisende adresseoplysninger,« fortæller Finn Jordal.

Han tøver ikke med at kalde projektet en succes. Og det skyldes i høj grad, at man hele vejen i det snart 4-årige projektforløb har værnet om en intensiv dialog med brugerne, som er udviklere af de it-systemer der er koblet op på DAWA:

»Vores mål om at fokusere på slutbrugerne har båret frugt. Vi mente, at hvis DAWA skulle blive et enkelt, udbredt og attraktivt produkt til gavn for forbrugerne, så skulle vi i dialog med de faktiske brugere, som er udviklerne. Og det er lykkedes at få meget feedback og kommentarer undervejs i udviklingen, hvilket vi sætter stor pris på,« siger han.

Et behov der er implementeret er fra Region H, der havde brug for en funktion der koblede et postnummer automatisk på en adresse.

DAWA tilbyder i dag en række funktionaliteter: adresseindtastning med autocomplete, adressesøgning, adresseopslag, adressevask, adressevalidering eller etablering af en opdateret, lokal kopi af adressedata.

Data tilgås enten i form af download eller direkte i form af et web API.

Svingende kvalitet i danske adresser

Baggrunden for projektet var, at der ikke tidligere fandtes et autoritativt adressetjeneste i Danmark. Behovet betjent af mange forskellige offentlige og private adressedatabaser.

Med svingende brugervenlighed, eksempelvis krævende nogle databaser, at man tastede ind i syv forskellige felter.

Staten har længe drevet BBR og senere Danmarks Adresseregister, DAR, som Danmarks autoritative register for adresser og vejnavne. Men DAR er rettet mod kommunerne, og der manglede en overbygning på DAR, der kunne sikre nem adgang til data i tråd med grunddataprogrammets målsætning, altså en it-tjeneste og ikke bare en database.

»Vi så et potentiale i, at fremfor at brugerne individuelt skulle etablere adressefunktionalitet til it-systemer, der havde brug for at adressedata, så kunne vi skabe en fælles adressefunktionalitet. Det ville også blive billigere for alle,« siger Finn Jordal.

Og ledelsesopbakningen til it-projektet - et emne som også er meget omdiskuteret for tiden - har været der fra starten, lyder det:

»SDFE’s direktion og grunddataprogrammet har givet DAWA projektet gode rammer til at fokusere på at få en god forståelse anvendernes behov og ud fra den udvikle DAWA i en retning, som opfyldte disse behov,« siger Finn Jordal.

Læs også: Direktør i Erhvervsstyrelsen: Sådan vendte vi en it-skandale til solide gevinster

Selv om projektet generelt har kørt fint, har der også været bump på vejen.

I juni sidste år frigav man en ny version af DAWA. Det inaktive driftsmiljø skulle så efterfølgende opdateres til gældende version. Under dette arbejde med opdatering af det inaktive miljø blev det ved en fejl udført på det aktive miljø (produktionssystemet). Det medførte, at produktionssystemet blev tømt for data og måtte reetableres fra en backup.

Det har også skabt problemer, at nogen it-systemer anvender DAWA til validering og deres samarbejdspartnere ikke gør. Her bliver DAWA hurtigt udpeget som ”synderen”.

En beskrivelse af en sådan sag findes her.

Uanset udfordringerne er nye funktionalitet løbende på vej. I øjeblikket arbejder man på at skabe et direkte link fra adresse til ejendomsnummer i BBR.

Valgt kæmpe specificering fra

Version2-blogger, direktør Yoel Caspersen, Kviknet, er blandt de begejstrede brugere af DAWA.

Det er fedt at se en offentlig myndighed, der tager ansvar for udviklingen af sine systemer og tænker det ind i en større sammenhæng, lyder det fra Version2-blogger, direktør Yoel Caspersen, Kviknet

»Jeg anvendte første gang DAWA til mit aktivistiske projekt omkring forbedring af tjekditnet.dk - og jeg kunne med det samme se, at det var anderledes end det sædvanlige software, vi ser fra det offentlige,« siger han til Version2.

Han oplever f.eks. hos Skat gamle systemer, der bukker under, når selvangivelsen skal tjekkes, men DAWA er anderledes:

»Tjenesten er tilsyneladende kodet af udviklere, der går op i deres arbejde - systemet er hosted hos Amazon, og der er adskillige underliggende IP-adresser, hvilket afslører, at man allerede har gjort sig nogle tanker om redundans og skalering,« tilføjer Yoel Caspersen.

Samtidig roser han den nemme og ubesværede tilgang til de offentlige data. Ikke noget med at skulle betale pr. opslag, tilmelde sig eller andet bøvl - det er bare at gå i gang.

Kviknet har med succes anvendt DAWA til adresseopslag på selskabets website, hvilket ifølge direktøren har forbedret bestillingsflowet væsentligt.

»Vi kan også se, at DAWA lytter til konstruktive input - f.eks. har de for nylig fået IPv6-understøttelse på deres system, hvilket er et særsyn i det offentlige.«

»Det er fedt at se en offentlig myndighed, der tager ansvar for udviklingen af sine systemer og tænker det ind i en større sammenhæng. Åbne offentlige data rummer et kæmpe potentiale, hvis det gøres rigtigt,« siger Yoel Caspersen.

Drop de store kravspecs

Finn Jordal anbefaler andre, der arbejder med offentlig it, en åben og trinvis udvikling:

»Vi fravalgte fra starten at specificere hele projektet og al funktionalitet og så bygge det. For det ville gøre det svært at følge behovene ude i samfundet,« forklarer Finn Jordal, der overordnet set har følgende forklaring på, hvorfor der er forskel på succesen med offentlige it-projekter.

Læs også: Søren Lauesen: Offentlige it-kunder overvurderer egne evner og forplumrer it-kravspecs

»Mange bruger meget tid op at kravspecificere deres it-projekt i detaljen, og forskere som Søren Lauesen (IT-Universitet, red.) peger på, at det ikke er den optimale måde at gøre det på – men mere at formulere hvad det er man vil opnå med systemet. Mit bud er, at mange offentlige projektejere med fordel kunne fokusere mere på resultatet – dvs. brugernes behov og arbejdssituationer end på, hvad systemet teknisk skal gøre i it-processerne.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (25)

Kommentarer (25)
Christian Nobel

DAWA skal kun have ros herfra, virkeligt et fyrtårn i et ellers ret tåget landskab.

Hvis der så kunne komme et link mellem CVR registret (som har den mest kummerlige adresse del, nogen gange med et C/O navn rodet ind i selve adressen) og DAWA, så ville det være kanon.

Yoel Caspersen Blogger

Det kunne være interessant at vide, hvad der er årsagen til de enkelte dyk, der findes i grafen fra DAWA. Er det mon enkelte "storkunder", som har koblet DAWA fra i kortere perioder?

Anders Jensen

Hej Yoel,

Dykkende skyldes ferie. Der er nogle administrative systemer og nogle testsystemer, som ikke anvendes i ferieperioder.

Der er også nogle systemer, der anvender DAWA så sjældent at der kan gå en uge uden nogen er på.

Yoel Caspersen Blogger

anvender PostgreSQL som database

Hvordan skalerer I databasen - har I et single master, multiple slaves-setup, kører I med sharding eller noget helt tredie?

Hvor mange transaktioner pr. dag taler vi om - og hvad var baggrundet for valget af PostgreSQL?

Vi er lidt nysgerrige efter at kende lidt mere til teknikken bag :-)

Anders Jensen

Vi anvender single-master, multiple slaves. Masteren er dermed et single point of failure, men kun for skrivninger til databasen.

PostgreSQL blev valgt af følgende årsager:

  • Gennemprøvet teknologi
  • Explicit skema
  • Transaktioner
  • GIS-support
  • Tekstsøgningssupport
  • Vi kendte den relativt godt da vi begyndte på projektet
  • Ikke behov for at skalere skrivninger

DAWA har få skrivninger i løbet af dagen (typisk mindre end 1 i minuttet). Det meste dataindlæsning foregår som daglige kørsler om natten.

Driftssetuppet er overordnet som følgende:

  • Amazon CloudFront som cache. CloudFront agerer også firewall, der beskytter mod alt andet end valide HTTP-requests. Da DAWA er et fleksibelt søge-API, er det en relativt lille procentdel af requests, som kan caches (~30%). De fleste requests ryger altså igennem til databasen.
  • Brocade Virtual Traffic Manager som Load-balancer og firewall. Det er et nyt tiltag, hidtil anvendte vi Amazons ELB. Der er 2 stks af disse - den ene er i hot standby. De er placeret i hver deres Amazon availability zone.
  • En autoskaleret gruppe af amazon-instanser som kører NodeJS og Postgres Replicas. Disse instanser er også fordelt på to availability zones.
  • En PostgreSQL master.

DAWA håndterer typisk omkring 3 mio. requests i døgnet. I dagtimerne omkring 40 requests i sekundet. Trafikken varier meget - det er helt normalt med spikes på over 100/sekund. En sjælden gang oplevede vi også, at et anvendersystem havde rigtigt mange besøgende og derfor forårsagede over 300 requests/sekund.

I dagtimerne ser vi normalt ca. 2 nye, unikke IP'er pr. sekund.

Skyd endelig løs hvis I har flere spørgsmål.

Baldur Norddahl

Skyd endelig løs hvis I har flere spørgsmål.

Jeg ville have spurgt om hvor mange procent IPv6 forespørgsler i får, men det ser ikke ud til at IPv6 er aktivt?

Baldurs-MBP-2:~ baldur$ host dawa.aws.dk
dawa.aws.dk is an alias for d1ab8pula12u5s.cloudfront.net.
d1ab8pula12u5s.cloudfront.net has address 54.230.230.8
d1ab8pula12u5s.cloudfront.net has address 54.230.230.226
d1ab8pula12u5s.cloudfront.net has address 54.230.230.214
d1ab8pula12u5s.cloudfront.net has address 54.230.230.53
d1ab8pula12u5s.cloudfront.net has address 54.230.230.49
d1ab8pula12u5s.cloudfront.net has address 54.230.230.184
d1ab8pula12u5s.cloudfront.net has address 54.230.230.114
d1ab8pula12u5s.cloudfront.net has address 54.230.230.71
Baldurs-MBP-2:~ baldur$

Såfremt en stor del af brugerne er fra kommuner og stat med mere, så ser vi nok lidt en skævvridning i IPv6 andelen da det offentlige generelt ikke har implementeret IPv6.

Anders Jensen

IPv6 andelen for det seneste døgn har været 0,35%.

Vi anvender som nævnt CloudFront, så det CloudFront der styrer hvilke DNS-svar du får. Det er ikke nødvendigvis alle klienter med en IPv6-adresse, som benytter IPv6. Selv skriver de om dette:

To maintain high customer availability, CloudFront will respond to viewer requests by using IPv4 if our data suggests that IPv4 will provide a better user experience.

Det er lidt uklart hvordan dette helt præcist fungerer.

AAAA-records ser ud som følger:

ahj$ dig dawa.aws.dk AAAA

; <<>> DiG 9.8.3-P1 <<>> dawa.aws.dk AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59823
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dawa.aws.dk. IN AAAA

;; ANSWER SECTION:
dawa.aws.dk. 30 IN CNAME d1ab8pula12u5s.cloudfront.net.
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:b000:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:6200:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:6400:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:e00:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:7c00:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:c200:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:9800:1a:21b7:8c00:93a1
d1ab8pula12u5s.cloudfront.net. 60 IN AAAA 2600:9000:2002:3200:1a:21b7:8c00:93a1

Baldur Norddahl

Jeg får ikke nogen AAAA ligemeget hvordan jeg spørger. Her med "dig" (ping6 blot for at vise at jeg skam har IPv6):

Baldurs-MBP-2:~ baldur$ dig dawa.aws.dk aaaa

; <<>> DiG 9.8.3-P1 <<>> dawa.aws.dk aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40372
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dawa.aws.dk. IN AAAA

;; ANSWER SECTION:
dawa.aws.dk. 60 IN CNAME d1ab8pula12u5s.cloudfront.net.

;; AUTHORITY SECTION:
d1ab8pula12u5s.cloudfront.net. 68 IN SOA ns-576.awsdns-08.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 143 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Feb 8 20:29:43 2017
;; MSG SIZE rcvd: 153

Baldurs-MBP-2:~ baldur$ ping6 -c3 google.com
PING6(56=40+8+8 bytes) 2a00:7660:7e3::b57f:ae5:28ce:56e3 --> 2a00:1450:400e:801::200e
16 bytes from 2a00:1450:400e:801::200e, icmp_seq=0 hlim=58 time=35.740 ms
16 bytes from 2a00:1450:400e:801::200e, icmp_seq=1 hlim=58 time=35.964 ms
16 bytes from 2a00:1450:400e:801::200e, icmp_seq=2 hlim=58 time=35.266 ms

--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 35.266/35.657/35.964/0.291 ms
Baldurs-MBP-2:~ baldur$

Det er klart at IPv6 andelen er ekstra lav når klienter med IPv6 ikke får det tilbudt alligevel.

Peter Hansen

Der er også nogle systemer, der anvender DAWA så sjældent at der kan gå en uge uden nogen er på.


Kan du evt. fortælle lidt mere om jeres brug, styring af og samarbejde med leverandører af udviklingsydelser?

Indgår I 4-årige aftaler med ét systemhus om at udvikle et givent system eller indgår I eks. en rammeaftale med fire leverandører om udviklingsydelser inden for en systemarkitektur, hvor konkrete leverandører herefter vælges til udviklingsopgaver på specifikke komponenter?

Sidder der folk med udviklerkompetence i styrelsen eller er de rene Product Owners? Laver I agile sprints i teams, hvor både rekvirent og udvikler sidder i samme lokale gennem længere tid eller bruger I vandfaldsleveranceplaner?

Yoel Caspersen Blogger

Jeg får ikke nogen AAAA ligemeget hvordan jeg spørger. Her med "dig" (ping6 blot for at vise at jeg skam har IPv6):

Baldurs-MBP-2:~ baldur$ dig dawa.aws.dk aaaa

Hos mig virker det fint med IPv6 - testet på en Kviknet-forbindelse:

~$ host dawa.aws.dk  
dawa.aws.dk is an alias for d1ab8pula12u5s.cloudfront.net.  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.114  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.49  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.53  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.214  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.226  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.8  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.71  
d1ab8pula12u5s.cloudfront.net has address 54.230.230.184  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:1000:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:5c00:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:c00:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:6600:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:8a00:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:8000:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:d200:1a:21b7:8c00:93a1  
d1ab8pula12u5s.cloudfront.net has IPv6 address 2600:9000:203b:5600:1a:21b7:8c00:93a1
Yoel Caspersen Blogger

GIS-support

Lyder som en relevant feature for et projekt som jeres. Bruger I disse features aktivt?

Tekstsøgningssupport

Tegnsæt er et tilbagevendende issue for os. Af princip kører vi UTF-8 i vores MySQL-database, men rigtig mange legacy-systemer rundt omkring kører en eller anden afart af Windows-1252-tegnsæt.

Da vi skulle skrive vores første integration til et større, dansk teleselskabs bedagede adressedatabase, brugte vi lang tid på at få vores klient til at understøtte UTF-7, som foreskrevet af udviklingsmanualen - indtil vi opdagede, at der var en fejl i manualen, og det rigtige tegnsæt blot var ISO-8859-1.

I vores database skal vi også holde tungen lige i munden, når vi vælger collation for en tabel - hvis vi vælger den forkerte variant af UTF8-collation, holder mange tekstrelaterede funktioner op med at virke som de skal - som fx "ORDER BY". Hvis vi joiner to tabeller på et tekstfelt, skal der også anvendes samme collation i hver tabel, hvilket mere eller mindre definerer sproget for den type data, man har liggende i databasen.

Har I haft mange udfordringer med tegnsæt? Jeg antager naivt, at I har været nødt til at få jeres system til at spille sammen med en masse gamle legacy-systemer...

Anders Jensen

Kan du evt. fortælle lidt mere om jeres brug, styring af og samarbejde med leverandører af udviklingsydelser?

Sidder der folk med udviklerkompetence i styrelsen eller er de rene Product Owners?

Jeg er udvikler og sidder på leverandørsiden, så jeg må hellere overlade det til Finn at svare på dit spørgsmål.

Jeg kan dog afsløre, at Finn selv kodede den første, fuldt funktionsdygtige prototype af DAWA, så der er bestemt udviklerkompetencer til stede i SDFE :-)

Anders Jensen

Lyder som en relevant feature for et projekt som jeres. Bruger I disse features aktivt?

Ja, vi anvender PostGIS til følgende:

  • Konvertering mellem ERS89 og WGS84 koordinatsystemer
  • Reverse geocoding og andre GIS queries (polygon-søgning, circkelsøgning), nabovejstykker
  • Beregning af adressers DAGI-tilknytning og Zonestatus og bebyggelser ud fra deres geometrier
  • Som backend til WFS- og WMS services baseret på GeoServer

Vi har været særdeles godt tilfredse med PostGIS. Vi havde lidt udfordringer med håndtering af store polygoner (en region er et multipolygon som består af ~300.000 punkter), men det kunne løses ved at dele regionen op i mindre bidder før indeksering.

Har I haft mange udfordringer med tegnsæt? Jeg antager naivt, at I har været nødt til at få jeres system til at spille sammen med en masse gamle legacy-systemer...

Vi indlæser data fra en del forskellige kildesystemer, men det er heldigvis ikke mere legacy end at det primært er HTTP, XML og JSON.

Vi tilgår et par WFS-services for at hente DAGI-temaer og zonekort, og et HTTP-JSON-baseret API som DAR 0.9 udstiller til os, hvor vi modtager adresseændringer. Derudover tilgår vi også et HTTP-JSON API der udstiller danmarks højdemodel, for at få fat i adressens Z-koordinat.

Så er der en del data vi modtager i filer, det er bl.a. Bebyggelser (JSON), Vejmidter (JSON), og Adresseudtræk (CSV),. Derudover indlæser vi CPRs vejregister, som er et lidt mere legacy format med recordtyper og faste feltbredder. Matrikelkortet modtager vi i XML-format.

Ejerlavsfortegnelsen og postnumre vedligeholder vi selv manuelt i i et par CSV-filer.

Vi kører UTF-8 og da_DK collation i databasen på alle tabeller og kolonner. I det omfang vi har haft behov for at konvertere kildedata fra andre tegnsæt har vi anvendt iconv-lite. Da vi har samme tegnsæt og collation på alle kolonner har vi ikke haft nogen problemer i forhold til databasen, og læsning af kildedata har blot været et spørgsmål om at køre dem igennem iconv-lite med det rigtige tegnsæt.

PostgreSQL har så vidt jeg ved support for at man kan joine to kolonner med forskellig collation, samt at lave indices med andre collations en kolonnens, så det kan gøres effektivt. Men det er stadig lidt besværligt at håndtere forskellige collations, man skal holde tungen lige i munden og vist også angive hvilken collation der skal anvendes når man JOINer, hvis man joiner på kolonner med forskellig collation.

Jesper Louis Andersen

I vores database skal vi også holde tungen lige i munden, når vi vælger collation for en tabel - hvis vi vælger den forkerte variant af UTF8-collation, holder mange tekstrelaterede funktioner op med at virke som de skal - som fx "ORDER BY". Hvis vi joiner to tabeller på et tekstfelt, skal der også anvendes samme collation i hver tabel, hvilket mere eller mindre definerer sproget for den type data, man har liggende i databasen.

MySQL er generelt set en database hvor funktionaliteten er begrænset. Det giver en hulens hurtig read hastighed for simple queries, men det koster så snart du rammer mere avancerede ting. I Postgres kan du lave et såkaldt functional index

CREATE INDEX foo ON tbl (content COLLATE "y")

hvilket betyder at du har en collation over 'content' column under "y" collation. En søgning der referer til den collation kan så bruge det index. Det bliver naturligvis dyrt hvis du har mange indexes, men bemærk at Postgres er i stand til selv at kombinere indexes on the fly i queries, så du har ikke brug for at lave indexes over formen (x,y,...) hvis du skal søge i flere columns, som du skal i MySQL.

Mit umiddelbare bud er dog at det nok at bedre at vælge et kanonisk internt format og så med hård hånd collate alt til dette format før databasen adspørges. Det er som regel nemmere end at skulle håndtere flere forskellige collations. Det gør også at værktøjer kan arbejde med den samme representation som grundantagelse og det har det med at fjerne en masse omskrivningskode der dels koster tid at implementere, dels er en magnet for fejl.

Yoel Caspersen Blogger

Mit umiddelbare bud er dog at det nok at bedre at vælge et kanonisk internt format og så med hård hånd collate alt til dette format før databasen adspørges. Det er som regel nemmere end at skulle håndtere flere forskellige collations.

Det er også den tilgang, vi har valgt. Men det gør så samtidig, at vi ikke kan have data liggende i flere sprog og samtidig bruge alle tekst-relaterede funktioner på disse data korrekt. Det er dog ikke det store problem for os, for størstedelen af vores data er finansielle data (abonnementer, priser m.v.) og kundeoplysninger, som for størstedelens vedkommende er dansksproget.

Finn Jordal

DAWA er en del grunddataprogrammet, hvor datafordeleren er den strategiske løsning og DAWA den taktiske løsning. DAWA’s formål er at tilbyde adressedata og –funktionalitet indtil datafordeleren kan overtage denne opgave. Da det fra DAWA projektets start ikke har været muligt at sætte en eksakt dato for, hvornår datafordeleren overtager DAWA’s opgaver, har projektet været præget af små kontrakter af typisk en måneds varighed og ikke af langsigtede planer og kontrakter.

DAWA projektet består stort set kun af fire personer. Undertegnede, som produktejer, Anders Hessellund Jensen, som står for udviklingen, Jesper Stein Jensen og Rudi Meyer, som står for driftsmiljøet. Deres dygtighed og vilje til at spille positivt med, har gjort det let at være produktejer.

Da DAWA’s udviklingsleverandør, Trifork, sidder i Aarhus, driftsleverandør, Netic, i Aalborg og SDFE i København er Skype den primære kommunikationsform. Som backlog anvender vi Github issues og Huboard. Vi mødes kun 2-4 gange årligt fysisk. Når vi har udviklingsprojekter anvender vi daglige status-/designmøder af 5 – 45 minutters varighed.

SDFE har mange personer med udviklererfaring ansat. Dels til intern udvikling af mange forskellige geofaglige ting; dels til at have en god forståelse af vor primære brugere, udviklere. Min egen udviklererfaring har jeg i forbindelse DAWA brugt til at etablere den oprindelige prototype, lave demoapplikationer, som f.eks. Hvor er jeg? (http://hvor.aws.dk) og Danmark adresser i lommen (http://dail.aws.dk) samt testscripts.

Jesper Louis Andersen

Det er også den tilgang, vi har valgt. Men det gør så samtidig, at vi ikke kan have data liggende i flere sprog og samtidig bruge alle tekst-relaterede funktioner på disse data korrekt. Det er dog ikke det store problem for os, for størstedelen af vores data er finansielle data (abonnementer, priser m.v.) og kundeoplysninger, som for størstedelens vedkommende er dansksproget.

I det tilfælde kan man muligvis komme omkring det med et functional index der tager collation, eller ved at live-collate til det rigtige format. En anden MySQL gotcha her er iøvrigt at dens Unicode support i praksis gemmer i UTF-24 eller UTF-32 i indexet, hvilket gør at ting fylder en hel del mere end det burde. Det kan godt være det rammer jer også efterhånden som data stiger i systemet.

Den "rigtige" løsning er i mange tilfælde at rykke den slags søgning til en dedikeret løsning (ElasticSearch) og så repopulere det index periodisk når der er ændringer. Det gør at du har dedikerede værktøjer til at håndtere collation før data går i index og du kan gemme flere forskellige collations samtidigt og så filtrere resultaterne ned. Det gælder specielt når tekstsøgningen der ønskes er mere avanceret end opslag på equivalence - eller at man har behov for at foretage tungere søgninger inverteret. Du kan humpe dig igennem på Postgres GIN og GIST indexes, men en dedikeret cluster til formålet har det med at performe bedre under belastning.

Anders Jensen

Vi har haft overvejelser om det ville give mening for DAWA at flytte visse typer af søgninger (især autocomplete og tekstsøgninger) over i en ElasticSearch eller lignende, mest fordi jeg formoder ElasticSearch vil performe bedre.

Jeg kender ikke ElasticSearch godt nok til at kunne vurdere, om vores søgninger kan implementeres lige så godt (eller endnu bedre) i Elastic, og hvor stor performancegevinsten vil være på den type søgninger, som vi udfører.

Derudover er problemet, at vores søgninger kan kombineres med andre query-filtre, herunder også eksempelvis geografiske begrænsninger.

Indtil videre har vi altså valgt at holde os 100% på Postgres. Det er dels fordi vi er ret godt tilfredse med de resultater vi kan levere med Postgres, og selvom vi formentlig kunne få bedre performance med Elastic, så performer vores API godt nok til, at brugerne ikke ville opleve den store forskel i praksis. Et skift til Elastic eller lignende vil også være en dyr omgang at implementere - I hvert fald ikke under 200 timer, sikkert mere, og dertil kommer den øgede driftskompleksitet. Opgaven er svær at estimere præcist. Men det kunne være sjovt at afprøve, hvor effektivt Elastic klarer de søgninger vi laver, sammenlignet med Postgres.

Baldur Norddahl

Ja det er da alligevel lidt specielt. Gad vide hvordan Amazon afgør hvem der skal tilgå CloudFront via IPv6, og hvordan de styrer det.

Det ser ud til at de har blacklistet en af vores DNS resolvere. Der er ingen AAAA når man spørger lige den resolver, hvorimod det ser fint ud hvis man spørger en af de to andre.

Så vidt jeg kan se, så fejler resolveren ikke noget. Den kan sagtens give AAAA svar på alt andet der har IPv6.

Jesper Louis Andersen

Jeg kender ikke ElasticSearch godt nok til at kunne vurdere, om vores søgninger kan implementeres lige så godt (eller endnu bedre) i Elastic, og hvor stor performancegevinsten vil være på den type søgninger, som vi udfører.

Derudover er problemet, at vores søgninger kan kombineres med andre query-filtre, herunder også eksempelvis geografiske begrænsninger.

Med mindre i har behov for en funktionalitet i ES der er svør at få i pg, så tror jeg ikke jeg ville hoppe ud i det. ES er primært hurtig hvis du kan holde det meste af datasættet i RAM, men det er Postgres også. Så i skal ud i noget hvor i vil have fonetisk søgning eller lignende. Der er en masse udviklingstid ved at skulle have datafeed op så du periodisk dumper dine postgres-data i ES.

En anden ikke helt uvæsentlig pointe er en overvejelse om hvor meget jeres GIS-svar kræver præcision.

GIS-data er ofte ultrapræcist fordi man går op i sådan noget. Det du laver i ES er at du tager dette og så giver afkald på noget af den præcision (indenfor 100m2 etc). Og så bruger du ikke geolocation som et filter, men som en scoringsfunktion: hvis du afviger for meget scorer du det ringere. For mange søgninger er dette fint, fordi en afstand såsom 5km i virkeligheden er "omkring 5km, om det er 4997 eller 5023 er lidt ligemeget". Scoringsfunktionen sørger for at straffe et resultat hvis det er fuldstændigt off.

Men det kan være jeres løsning har et meget højere præcisionsbehov. Og så er det måske bedre med lidt filtrering i PostGIS. Det er ihvertfald noget der skal indgå i en ES-overvejelse.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 10:29

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017

Affecto has the solution and the tools you need

According to GDPR, you are required to be in control of all of your personally identifiable and sensitive data. There are only a few software tools on the market to support this requirement today.
13. sep 2017