Databaseservere og embedded databaser: sammenligning av arkitektur og I/O-egenskaper

Databaseserver

Databaseserver refererer til en database som kjører som en uavhengig serverprosess og behandler forespørsler fra applikasjoner via nettverket. MySQL, PostgreSQL, Oracle DB og de fleste andre RDBMS-er som vi er godt kjent med, tilhører denne modellen. Databaseserveren har følgende fordeler.

Sentralisert administrasjon: Data administreres samlet på ett sted, noe som gjør konsistens, sikkerhet, sikkerhetskopiering og gjenoppretting enklere.
Ressursuavhengighet: Serveren tildeles egne CPU-, minne- og lagringsressurser, og sikrer dermed stabil ytelse uavhengig av applikasjonens tilstand.
Høy samtidighet og skalerbarhet: Serveren er optimalisert for samtidig tilgang fra mange brukere, og horisontal skalering gjennom clustering eller replikering er relativt enkel.

Takket være disse egenskapene har databaseserveren i flere tiår etablert seg som standard i programvareinfrastruktur. Men med teknologisk utvikling og endrede omgivelser har ulemper ved databaseserveren begynt å komme til syne i enkelte miljøer, og som et alternativ har embedded databaser igjen fått oppmerksomhet.

Ny retning: Embedded databaser

Embedded databaser er databasemotorer som ikke krever en egen serverprosess, men er inkludert i applikasjonen som et bibliotek og kjører i samme prosess. SQLite, LevelDB og RocksDB er typiske eksempler på embedded databaser. Bakgrunnen for at embedded databaser har fremstått som et sterkt alternativ i moderne teknologiske miljøer, er følgende.

Fremveksten av SSD-er
I tidligere systemmiljøer dominert av HDD-er var ytelsen ved tilfeldig tilgang betydelig lavere enn ved sekvensiell lesing og skriving. Derfor var det sentralt for ytelsesoptimalisering å minimere diskens I/O og maksimere minnecaching. Databaseservere har tilpasset seg dette ved å drive store cacher og samle skriveoperasjoner for å overvinne de fysiske begrensningene til HDD-er.
SSD-ens fremvekst har imidlertid fullstendig endret disse forutsetningene. En SSD er tusenvis av ganger raskere enn en HDD ved tilfeldig I/O, og ventetiden er også dramatisk kortere. Som følge av dette har den tidligere oppfatningen om at "diskens I/O er den største flaskehalsen" forsvunnet, og i stedet har forsinkelser ved fjerntilgang til databaseserveren via nettverket begynt å fremstå som den nye flaskehalsen.
MSA og datauavhengighet
Tidligere var det vanlig med en arkitektur der én stor monolittisk applikasjon var avhengig av én sentralisert database. Selv om denne tilnærmingen var enkel, medførte den at endringer i dataskjemaet ble vanskeligere etter hvert som tjenestens omfang økte, og at koblingen mellom tjenestene ble for sterk fordi alle tjenester delte samme database.
I moderne mikrotjenestearkitekturer legges det derfor stor vekt på prinsippet "Database per Service" for å løse disse problemene. Ved at hver tjeneste eier og innkapsler sitt eget dedikerte datalager, sikres uavhengighet mellom tjenestene, og feilisolasjon og skalering blir enklere. I denne sammenhengen blir embedded databaser et ideelt valg som datalager på tjenestenivå. De er lette og raske, og kan distribueres sammen med tjenestekoden, noe som passer svært godt til MSA-miljøer.
I Kubernetes-miljøer brukes det for eksempel ofte et sidecar-mønster, der en embedded database plasseres ved siden av applikasjonscontaineren for å optimalisere lokal datahåndtering. Dette reduserer nettverksflaskehalser og minimerer forsinkelser i datatilgangen.
Forenklet driftsmiljø
Databaseservere krever komplekse driftsprosedyrer, som installasjon, oppdateringer, sikkerhetskopiering, gjenoppretting etter feil, replikering og ytelsesovervåking, og for dette trengs dedikerte DBA-er og kvalifisert driftspersonell. Særlig i store miljøer er denne administrative belastningen svært stor.
Embedded databaser lindrer disse problemene betydelig. Når databasen integreres i applikasjonen, utføres enhetstesting, bygging, versjonshåndtering og distribusjon samlet, og det er dermed ikke nødvendig med en egen serverdrift. Dessuten skaleres den embedded databasen sammen med applikasjonen når den skaleres horisontalt, og automatisert administrasjon gjennom DevOps-kultur og CI/CD-pipelines blir mulig. Særlig i oppstartsbedrifter, små tjenester og utviklingsmiljøer for prototyper reduserer embedded databaser driftskompleksiteten betydelig og øker utviklings- og distribusjonshastigheten vesentlig.
Høytytende systemspråk og utvikling i økosystemet
Tidligere ble databaser og applikasjoner vanligvis skrevet i ulike språk. For eksempel ble høytytende databasemotorer hovedsakelig skrevet i C og C++, mens applikasjoner ble utviklet i språk som Java, Python og PHP. Denne tilnærmingen var effektiv for ytelsesoptimalisering, men hadde begrensninger knyttet til minnesikkerhet, kompleks samtidighetshåndtering, ventetid, samt vanskeligheter med integrering av biblioteker og distribusjon.
Den senere tids fremvekst av moderne systemprogrammeringsspråk som Go og Rust har imidlertid betydelig redusert disse begrensningene. Særlig er Go egnet både for høytytende applikasjoner og for skriving av lavnivåprogrammer som databasemotorer, slik at databaser og applikasjoner kan håndteres innenfor ett og samme språkøkosystem.
Faktisk brukes høytytende embedded databaser som BadgerDB og PebbleDB aktivt i Golang. Dette innebærer at embedded databaser ikke lenger bare er et lettvektsalternativ til databaseservere, men har etablert seg som et viktig valg med egen konkurransekraft.

Konklusjon

For krav til sentralisert forvaltning av store datamengder, komplekse transaksjoner og høy samtidighet er databaseserveren fortsatt den sterkeste løsningen. Men i MSA-miljøers enkelttjenester, IoT-enheter ved kanten av nettverket, raske prototyper og prosjekter der driftseffektivitet er viktig, kan embedded databaser være et mer effektivt og fornuftig valg. Til syvende og sist er det avgjørende å velge det verktøyet som best passer til den aktuelle situasjonen og kravene, og utviklingen av embedded databaser gir oss flere og mer varierte valgmuligheter.