Database Server og Embedded Database

Database Server

En Database Server refererer til en database som kjører som en uavhengig serverprosess og behandler applikasjonsforespørsler via nettverket. De fleste RDBMS-ene vi er kjent med, som MySQL, PostgreSQL og Oracle DB, faller inn under denne modellen. En database server har følgende fordeler:

• Sentralisert Administrasjon: Data administreres integrert på ett sted, noe som gjør konsistens, sikkerhet, sikkerhetskopiering og gjenoppretting enklere.
• Ressursuavhengighet: Den tildeles egen CPU, minne og lagring, noe som sikrer stabil ytelse uavhengig av applikasjonens tilstand.
• Høy Samtidighet og Skalerbarhet: Den er optimalisert for samtidig tilgang fra mange brukere, og horisontal skalering gjennom klyngedrift eller replikering er relativt enkelt.

Takket være disse egenskapene har database serveren vært standarden for programvareinfrastruktur i flere tiår. Imidlertid har teknologisk utvikling og miljøendringer ført til at ulempene med database servere har kommet til syne i enkelte miljøer, og embedded databases har igjen fått oppmerksomhet som et alternativ.

Ny Trend: Embedded Databases

En embedded database er en database-motor som er inkludert i applikasjonen som et bibliotek, uten en separat serverprosess, og som kjører innenfor den samme prosessen. SQLite, LevelDB og RocksDB er typiske eksempler på embedded databases. Bakgrunnen for at disse embedded databases har vokst frem som et kraftig alternativ i det nyeste teknologiske landskapet er som følger:

• Fremveksten av SSD

  I tidligere systemmiljøer dominert av HDD, var ytelsen for tilfeldig tilgang (random access) betydelig dårligere sammenlignet med sekvensiell datalesing/skriving. Derfor var kjernen i ytelsesoptimalisering å minimere disk-I/O og maksimere minne-caching. Database servere har taklet de fysiske begrensningene til HDD-er ved å operere med store cacher og behandle skriveoperasjoner samlet.

  Imidlertid har fremveksten av SSD-er fullstendig endret denne forutsetningen. SSD-er er tusenvis av ganger raskere i random I/O-ytelse enn HDD-er, og har en dramatisk kortere forsinkelse (latency). Som et resultat har den tidligere oppfatningen om at "disk-I/O er den største flaskehalsen" forsvunnet, og forsinkelsen som oppstår ved tilgang til en ekstern DB-server via nettverket har i stedet blitt fremhevet som en ny flaskehals.

• MSA og Datauavhengighet

  Tidligere var det vanlig med en struktur der én massiv monolittisk applikasjon var avhengig av én sentralisert database. Denne tilnærmingen var enkel, men etter hvert som tjenestens omfang vokste, ble det vanskelig å endre dataschemaet, og det oppstod et problem med at alle tjenestene delte den samme DB-en, noe som førte til altfor sterk kobling.

  I moderne Microservices Architecture (MSA) vektlegges prinsippet om "Database per Service" for å løse disse problemene. Ved at hver tjeneste eier og kapsler inn sitt dedikerte datalager, sikres uavhengighet mellom tjenestene, og feilisolering og skalering blir enklere. I denne prosessen blir embedded DB-er et ideelt valg for datalager på tjenestenivå. De er lette, raske og kan distribueres sammen med tjenestekoden, noe som passer svært godt til MSA-miljøet.

  Representative for dette, brukes ofte Sidecar-mønsteret i Kubernetes-miljøer for å plassere en embedded DB ved siden av applikasjonscontaineren for å optimalisere lokal databehandling. Dette reduserer nettverksflaskehalser og minimerer forsinkelsen i datatilgangen.

• Forenkling av Driftsmiljøet

  Database servere krever komplekse driftsprosedyrer som installasjon, patching, sikkerhetskopiering, feilgjenoppretting, replikering og ytelsesovervåking, og dette krever dedikert DBA-personell og spesialisert driftspersonell. Spesielt i store miljøer er denne administrasjonsbyrden svært stor.

  Embedded DB-er reduserer disse problemene betraktelig. Når databasen er integrert i applikasjonen, skjer enhetstesting, bygging, versjonskontroll og utrulling samtidig, slik at det ikke er behov for separat serverdrift. Videre skalerer den embedded DB-en sammen med applikasjonen når den Scale-out-es, og automatisert administrasjon gjennom DevOps-kultur og CI/CD-pipelines blir mulig. Spesielt i startups, småskalatjenester, prototypeutviklingsmiljøer, reduserer embedded databases driftskompleksiteten dramatisk og øker utviklings- og utrullingshastigheten betraktelig.

• Utvikling av Høytytende Systemspråk og Økosystem

  Tidligere var det vanlig at databaser og applikasjoner ble skrevet i forskjellige språk. For eksempel ble database-motorer som krevde høy ytelse, vanligvis skrevet i C, C++, mens applikasjoner ble utviklet i språk som Java, Python, PHP. Denne tilnærmingen var effektiv for ytelsesoptimalisering, men hadde begrensninger som minnestabilitetsproblemer, kompleks samtidighetshåndtering, forsinkelse, og vanskeligheter med bibliotekintegrasjon og utrulling.

  Imidlertid har disse begrensningene blitt betydelig redusert med fremveksten av moderne systemprogrammeringsspråk som Go og Rust. Spesielt Go er egnet for å skrive både høytytende applikasjoner og lavnivåprogrammer som database-motorer, noe som gjør det mulig å håndtere databasen og applikasjonen sammen innenfor ett språks økosystem.

  Faktisk brukes høytytende embedded databases som BadgerDB og PebbleDB aktivt i Golang. Dette indikerer at embedded databases ikke bare er et lettvektsalternativ til database servere, men har etablert seg som et viktig valg med egen konkurransekraft.

Konklusjon

For sentralisert administrasjon av store datamengder, komplekse transaksjoner og forhold som krever høy samtidighet, er database serveren fortsatt den mest kraftfulle løsningen. Men i individuelle tjenester i et MSA-miljø, IoT Edge-enheter, rask prototyping, og prosjekter der driftseffektivitet er viktig, kan embedded databases være et mer effektivt og rasjonelt valg. Til syvende og sist er det viktig å velge det optimale verktøyet som passer best til den gitte situasjonen og kravene, og utviklingen av embedded databases gir oss et bredere og mer variert utvalg av valgmuligheter.