Tietokantapalvelimet ja upotetut tietokannat: arkkitehtuurin ja I/O-ominaisuuksien vertailu

Tietokantapalvelin

Tietokantapalvelin tarkoittaa tietokantaa, joka toimii itsenäisenä palvelinprosessina ja käsittelee sovellusten pyyntöjä verkon kautta. MySQL, PostgreSQL, Oracle DB ja useimmat meille tutut RDBMS-järjestelmät kuuluvat tähän malliin. Tietokantapalvelimella on seuraavat edut.

• Keskitetty hallinta: Data hallitaan yhdessä paikassa, mikä helpottaa yhtenäisyyden, tietoturvan sekä varmuuskopioinnin ja palautuksen toteuttamista.
• Resurssien riippumattomuus: Palvelin saa oman suorittimen, muistin ja tallennustilan, ja se takaa vakaan suorituskyvyn sovelluksen tilasta riippumatta.
• Korkea rinnakkaisuus ja skaalautuvuus: Palvelin on optimoitu monen käyttäjän samanaikaiseen käyttöön, ja klusterointi tai replikointi mahdollistaa suhteellisen helpon vaakasuuntaisen skaalauksen.

Näiden ominaisuuksien ansiosta tietokantapalvelimesta on viime vuosikymmeninä vakiintunut ohjelmistoinfrastruktuurin standardi. Teknologian kehitys ja ympäristön muutokset ovat kuitenkin saaneet tietokantapalvelimen heikkoudet näkymään joissakin ympäristöissä, ja tämän vuoksi upotettu tietokanta on alkanut saada uudelleen huomiota vaihtoehtona.

Uusi suuntaus: upotettu tietokanta

Upotettu tietokanta on tietokantamoottori, joka sisältyy sovellukseen kirjastona ja toimii samassa prosessissa ilman erillistä palvelinprosessia. SQLite, LevelDB ja RocksDB ovat tyypillisiä upotettuja tietokantoja. Upotetun tietokannan nousu vahvaksi vaihtoehdoksi nykyisessä teknologiaympäristössä johtuu seuraavista syistä.

• SSD-levyjen yleistyminen

  Aiemmin HDD-pohjaisissa järjestelmissä satunnaisen käytön suorituskyky oli merkittävästi heikompi kuin peräkkäisen luku- ja kirjoitussuorituskyky. Siksi levy-I/O:n minimointi ja muistivälimuistin maksimointi olivat suorituskyvyn optimoinnin ydin. Tietokantapalvelimet ylläpitivät tämän vuoksi suuria välimuisteja ja yhdistelivät kirjoitusoperaatioita, ja näin ne kiersivät HDD:n fyysisiä rajoituksia.

  SSD-levyjen yleistyminen on kuitenkin muuttanut tämän lähtökohdan täysin. SSD:n satunnaisen I/O:n suorituskyky on tuhansia kertoja HDD:tä nopeampi, ja viiveet ovat huomattavasti lyhyempiä. Tämän seurauksena aiempi käsitys "levy-I/O on suurin pullonkaula" on menettänyt merkityksensä, ja verkon kautta tapahtuvan etätietokantapalvelimen käytön viive on alkanut nousta uudeksi pullonkaulaksi.

• MSA ja datan riippumattomuus

  Aiemmin oli tavallista, että yksi suuri monoliittinen sovellus nojasi yhteen keskitettyyn tietokantaan. Tämä rakenne on yksinkertainen, mutta palvelun kasvaessa tietokantaskeemojen muuttaminen vaikeutuu, ja kun kaikki palvelut jakavat saman tietokannan, niiden välinen kytkentä kiristyy liikaa.

  Nykyaikaisessa mikropalveluarkkitehtuurissa tätä ongelmaa ratkaistaan usein periaatteella "Database per Service". Jokainen palvelu omistaa ja kapseloi oman dedikoidun tietovarastonsa, mikä takaa palvelujen välisen riippumattomuuden ja helpottaa vikojen eristämistä ja skaalausta. Tässä yhteydessä upotettu tietokanta on luonteva valinta palvelukohtaiseksi tietovarastoksi. Se on kevyt ja nopea, ja koska se voidaan julkaista yhdessä palvelukoodin kanssa, se sopii MSA-ympäristöön erittäin hyvin.

  Esimerkiksi Kubernetes-ympäristöissä käytetään laajalti sidecar-mallia, jossa upotettu tietokanta sijoitetaan sovelluskontin viereen paikallisen datankäsittelyn optimoimiseksi. Tämä vähentää verkon pullonkaulaa ja minimoi datan käyttöviiveen.

• Käyttöympäristön yksinkertaistaminen

  Tietokantapalvelin vaatii monimutkaisia operatiivisia toimenpiteitä, kuten asennuksen, päivitykset, varmuuskopioinnin, vikatilanteista palautumisen, replikoinnin ja suorituskyvyn seurannan. Näihin tarvitaan omistautunut DBA ja ammattitaitoinen operatiivinen henkilöstö. Erityisesti suurissa ympäristöissä tämä hallinnollinen taakka on hyvin suuri.

  Upotettu tietokanta lieventää tätä ongelmaa merkittävästi. Kun tietokanta on integroitu sovellukseen, yksikkötestaus, rakentaminen, versionhallinta ja julkaisu tapahtuvat yhdessä, joten erillistä palvelimen ylläpitoa ei tarvita. Lisäksi kun sovellusta skaalataan Scale-out-periaatteella, myös upotettu tietokanta skaalautuu mukana, ja DevOps-kulttuurin sekä CI/CD-putkien avulla hallinta voidaan automatisoida. Erityisesti startupeissa, pienissä palveluissa ja prototyyppien kehitysympäristöissä upotettu tietokanta vähentää merkittävästi operatiivista monimutkaisuutta ja nopeuttaa huomattavasti kehitystä ja julkaisua.

• Korkean suorituskyvyn järjestelmäkielet ja ekosysteemin kehitys

  Aiemmin tietokanta ja sovellus kirjoitettiin yleensä eri kielillä. Esimerkiksi suorituskykyä vaativat tietokantamoottorit kirjoitettiin pääasiassa C- ja C++-kielillä, kun taas sovellukset kehitettiin kielillä, kuten Java, Python ja PHP. Tämä tapa oli tehokas suorituskyvyn optimoinnin kannalta, mutta siihen liittyi rajoituksia: muistin turvallisuusongelmia, monimutkaista rinnakkaisuuden hallintaa, viiveitä sekä kirjastojen integroinnin ja julkaisun vaikeuksia.

  Viime aikoina Go- ja Rust-kaltaisten nykyaikaisten järjestelmäohjelmointikielten nousu on kuitenkin lieventänyt näitä rajoituksia merkittävästi. Erityisesti Go soveltuu sekä korkean suorituskyvyn sovelluksiin että matalan tason ohjelmiin, kuten tietokantamoottoreihin, joten tietokanta ja sovellus voidaan käsitellä yhdessä saman kielen ekosysteemissä.

  Käytännössä Golangissa käytetään aktiivisesti korkean suorituskyvyn upotettuja tietokantoja, kuten BadgerDB ja PebbleDB. Tämä osoittaa, että upotetut tietokannat eivät ole enää pelkkiä tietokantapalvelimen kevyitä vaihtoehtoja, vaan niistä on tullut omilla vahvuuksillaan varustettu ja merkittävä valinta.

Johtopäätökset

Vaatimuksissa, joissa tarvitaan keskitettyä suurten datamäärien hallintaa, monimutkaisia transaktioita ja korkeaa rinnakkaisuutta, tietokantapalvelin on edelleen tehokkain ratkaisu. Kuitenkin MSA-ympäristön yksittäisissä palveluissa, IoT-reunalaitteissa, nopeassa prototyypityksessä sekä projekteissa, joissa operatiivinen tehokkuus on tärkeää, upotetusta tietokannasta voi tulla tehokkaampi ja järkevämpi valinta. Lopulta tärkeintä on valita tilanteeseen ja vaatimuksiin parhaiten sopiva työkalu, ja upotettujen tietokantojen kehitys tarjoaa meille laajemman ja monipuolisemman valikoiman vaihtoehtoja.