Databaseservere og indlejrede databaser

Databaseserver

En databaseserver er en database, der kører som en uafhængig serverproces og behandler applikationsanmodninger via netværket. De fleste velkendte RDBMS'er, såsom MySQL, PostgreSQL og Oracle DB, falder ind under denne model. En databaseserver har følgende fordele:

• Centraliseret administration: Data administreres samlet på ét sted, hvilket letter konsistens, sikkerhed, backup og gendannelse.
• Ressourceuafhængighed: Den tildeles sin egen CPU, hukommelse og storage, hvilket sikrer stabil ydeevne uafhængigt af applikationens tilstand.
• Høj samtidighed og skalerbarhed: Den er optimeret til samtidig adgang for mange brugere, og horisontal skalering via clustering eller replikering er relativt let.

På grund af disse egenskaber har databaseservere i årtier været standarden inden for softwareinfrastruktur. Men på grund af teknologisk udvikling og ændringer i miljøet er ulemperne ved databaseservere begyndt at vise sig i visse miljøer, og embeddede databaser får igen opmærksomhed som et alternativ.

Ny tendens: Embedded database

En embedded database er en database-engine, der er inkluderet som et bibliotek i applikationen og kører inden for den samme proces uden en separat serverproces. SQLite, LevelDB og RocksDB er eksempler på embeddede databaser. Baggrunden for, at disse embeddede databaser er blevet et stærkt alternativ i det nyeste teknologimiljø, er som følger:

• Fremkomsten af SSD'er

  I tidligere systemmiljøer, der var centreret om HDD'er, var tilfældig adgangsydelse markant ringere end sekventiel data læse-/skriveydelse. Derfor var kernen i ydelsesoptimering at minimere disk-I/O og maksimere hukommelses-caching. Databaseservere har overvundet HDD'ens fysiske begrænsninger ved at drive store caches og behandle skriveoperationer samlet.

  Imidlertid har fremkomsten af SSD'er fuldstændigt ændret denne præmis. SSD'er er tusindvis af gange hurtigere i tilfældig I/O-ydelse og har dramatisk kortere latency sammenlignet med HDD'er. Som et resultat er den tidligere opfattelse af "disk-I/O som den største flaskehals" forsvundet, og forsinkelser forårsaget af fjernadgang til DB-servere via netværket er begyndt at fremstå som en ny flaskehals.

• MSA og datauafhængighed

  Tidligere var det almindeligt med en monolitisk applikation, der var afhængig af en centraliseret database. Denne tilgang var enkel, men efterhånden som servicens omfang voksede, blev det vanskeligt at ændre dataskemaet, og der opstod et problem med overdreven kobling, da alle services delte den samme DB.

  I moderne mikroservicearkitekturer lægges der vægt på princippet om "Database per Service" for at løse disse problemer. Ved at hver service ejer og indkapsler sin egen dedikerede datalager, sikres uafhængighed mellem services, og fejlisolering og skalering lettes. I denne proces bliver en embedded DB et ideelt valg som datalager på serviceniveau. Den er let, hurtig og kan implementeres sammen med servicekoden, hvilket gør den meget velegnet til MSA-miljøer.

  For eksempel er det i Kubernetes-miljøer almindeligt at bruge sidecar-mønsteret til at placere en embedded DB ved siden af applikationscontaineren for at optimere lokal databehandling. Dette reducerer netværksflaskehalse og minimerer forsinkelser i dataadgang.

• Forenkling af driftsmiljøet

  Databaseservere kræver komplekse driftsprocedurer, herunder installation, patching, backup, fejlgenoprettelse, replikering og ydeevneovervågning, og dette kræver dedikerede DBA'er og professionelt driftspersonale. Især i store miljøer er denne administrationsbyrde meget stor.

  Embeddede DB'er lindrer disse problemer betydeligt. Når databasen er integreret i applikationen, udføres enhedstest, build, versionsstyring og implementering sammen, så der ikke er behov for separat serverdrift. Desuden skaleres den embeddede DB sammen, når applikationen skaleres ud, og automatiseret administration er mulig via DevOps-kultur og CI/CD-pipelines. Især i startups, små services og prototypeudviklingsmiljøer reducerer embeddede databaser driftskompleksiteten markant og øger udviklings- og implementeringshastigheden betydeligt.

• Højtydende systemsprog og økosystemudvikling

  Tidligere var det almindeligt, at databaser og applikationer blev skrevet i forskellige sprog. For eksempel blev højtydende database-engines primært skrevet i C, C++, og applikationer blev udviklet i sprog som Java, Python, PHP. Denne tilgang var effektiv til ydelsesoptimering, men havde begrænsninger såsom problemer med hukommelsesstabilitet, kompleks håndtering af samtidighed, latency og vanskeligheder med biblioteksintegration og implementering.

  Men med fremkomsten af moderne systemprogrammeringssprog som Go og Rust er disse begrænsninger blevet markant reduceret. Især Go er velegnet til at skrive højtydende applikationer såvel som lavniveau-programmer som database-engines, hvilket gør det muligt at håndtere databaser og applikationer sammen inden for ét sprogøkosystem.

  Faktisk bruges højtydende embeddede databaser som BadgerDB og PebbleDB aktivt i Golang. Dette betyder, at embeddede databaser er blevet et vigtigt valg med deres egen konkurrenceevne, ud over at være et letvægtsalternativ til databaseservere.

Konklusion

I situationer, der kræver centraliseret administration af store datamængder, komplekse transaktioner og høj samtidighed, er databaseservere stadig den mest robuste løsning. Men i MSA-miljøers individuelle services, IoT edge-enheder, hurtig prototyping og projekter, hvor driftseffektivitet er afgørende, kan embeddede databaser være et mere effektivt og rationelt valg. I sidste ende er det vigtigt at vælge det optimale værktøj, der passer bedst til den givne situation og krav, og udviklingen af embeddede databaser giver os et bredere og mere varieret udvalg af muligheder.