Uuden projektin luomiseen kuuluu oikean tietokannan valitseminen tietojen tallentamista varten. Monet tuntemani kehittäjät valitsevat alusta alkaen oletuksena relaatiotietokannan. Mutta onko se paras päätös? Se riippuu tietenkin monista tekijöistä. Tässä artikkelissa haluan esitellä sinulle muita tietokantatyyppejä, jotta valintasi olisi helpompaa ja jotta voisit valmistautua tuleviin hankkeisiisi.
Tietokannan tyyppi ei ole ainoa huomioon otettava asia. On monia muitakin asioita, joita on pohdittava, esim. kuinka monta aktiivista käyttäjää sovelluksella voi olla? Tarvitsetko vahvaa yhdenmukaisuutta kaikkialla? Riittääkö mahdollinen johdonmukaisuus joissakin tapauksissa? On niin monia kysymyksiä, joihin ei ole suoraviivaisia vastauksia, sillä "mitä enemmän asiaan paneudutaan, sitä monimutkaisemmaksi se muuttuu". Huomaa siis, että tässä artikkelissa keskitytään vain tietokantatyyppeihin.
Ota kuppi kahvia ja nauti tästä lukemisesta.
Yleinen tietokantaluokitus
Aluksi on hyvä tietää, että tietokantoja on kahta päätyyppiä: relaatiotietokantoja (SQL) ja ei-relaatiotietokantoja (NoSQL).
- SQL-tietokannat ovat rakenteeltaan relaatiotietokantoja, mikä tarkoittaa, että tiedot tallennetaan taulukoihin ja niiden välillä ylläpidetään suhteita.
- NoSQL-tietokannat (Not only SQL) eivät ole relaatiotietokannoista poiketen hyvin strukturoituja, joten ne mahdollistavat paremman mukautuvuuden ja joustavuuden.
Kahden edellä mainitun lisäksi on olemassa vielä yksi tyyppi, nimittäin muistitietokanta. Sitä ei voida luokitella relaatiotyyppiseksi eikä ei-relaatiotyyppiseksi, koska se liittyy siihen, missä tiedot on fyysisesti tallennettu. Jokainen tietokanta voidaan tallentaa joko levylle tai muistiin.
Tietokantatyypit
1. Suhteellinen
Mielestäni se on suosituin tietokantatyyppi. Se toimii hyvin rakenteellisten tietojen kanssa, kun tietueiden väliset suhteet halutaan säilyttää. Tietokannan rakenne kuvataan skeemassa.
Tärkeimmät edut liittyvät transaktioihin (ne auttavat varmistamaan tietojen eheyden ja noudattavat ACID-sääntöjä) ja kykyyn käsitellä monia monimutkaisia kyselyjä.
Milloin valita se?
Se on hyödyllinen esimerkiksi sellaisten tietojen säilyttämiseen, jotka eivät muutu rakenteeltaan kovin usein ja jotka on säilytettävä pysyvästi:
- CRM (Customer Relationship Management),
- Tilausten hallinta,
- ERP (Yritys Resurssien suunnittelu),
- tietovarastointi tai varastonhallinta,
- kirjanpito tai rahoitus.
Esimerkkejä:
Amazon Aurora, Microsoft Azure SQL-tietokanta, PostgreSQL, MySQL.
Relaatiotietokannat eivät riitä moniin uusiin sovelluksiin, ja tarvitset useamman kuin yhden tietokannan. Artikkelin seuraavassa osassa keskityn ei-relationaalisiin tietokantoihin.
2. Avainarvo
Se tallentaa jokaisen tietoarvon yksilöllisellä avaimella. Se tarkoittaa, että tietoja käytetään yhden avaimen avulla, aivan kuten hash mapissa. Toisin kuin relaatiotietokannat, se ei noudata järjestelmää eikä tietueiden välisiä suhteita. Useimmat näistä tietokannoista eivät yleensä tue päivitysoperaatioita. Jos tietoja halutaan muuttaa, koko olemassa oleva joukko on korvattava.
Milloin valita se?
Se on hyödyllinen sellaisten tietojen kohdalla, joita haluat lukea/kirjoittaa nopeasti (mutta joita ei päivitetä kovin usein):
- reaaliaikainen tarjoaminen, mainostaminen,
- tietojen välimuistiin tallentaminen,
- istunnon hallinta,
- ostoskärryt,
- asiakkaan mieltymykset tai profiilinhallinta.
Esimerkkejä:
Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.
3. Asiakirja
Se tallentaa asiakirjakokoelmia. Jokainen asiakirja sisältää kenttiä, joissa on tietoja, jotka voivat olla yksinkertaisia arvoja tai monimutkaisia elementtejä, kuten luetteloita tai lapsikokoelmia. On tärkeää tietää, että jokaisella asiakirjalla voi olla erilainen rakenne, vaikka ne edustaisivatkin samaa asiaa (jokainen asiakirja on ainutlaatuinen ja kehittyy ajan myötä). Esimerkiksi ensimmäinen asiakasasiakirja sisältää vähemmän tietoa kuin toinen:
{
"FirstName": "John",
"LastName": "Fake",
"Motorcycles:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
{
"FirstName": "Alex",
"LastName": "Nolastname",
"Age": 15,
"Osoite": {
"Country": "Puola",
"Kaupunki": "Jossain"
},
"Motorcycles:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
Milloin valita se?
Se on hyödyllinen tiedoille, jotka edellyttävät joustavaa skeemaa nopeaa käsittelyä varten:
- tuote luettelot,
- CMS (sisällönhallintajärjestelmä),
- käyttäjäprofiilit ja personointi.
Esimerkkejä:
Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.
4. Kuvaaja
Se käyttää graafirakennetta ja koostuu kahdesta elementistä: solmuista ja reunoista. Solmut vastaavat taulukon rivejä tai JSON-dokumentteja. Särmät ovat solmujen välisiä suhteita - ne ovat yhtä tärkeitä kuin solmut. Molemmilla voi olla ominaisuuksia. Lisäksi reunoilla voi olla määritelty suhteen suunta.
Milloin valita se?
Se on hyödyllinen silloin, kun tietosi muistuttavat kuvaajaa, toisin sanoen tietoelementtien väliset suhteet ovat dynaamisia ja muuttuvat ajan myötä. Lisäksi se on hyvä valinta silloin, kun liiketoiminnallinen tai tekninen joukkue on ymmärrettävä tietojen välisiä suhteita. Joitakin merkittäviä esimerkkejä ovat mm:
- organisaatiokaaviot,
- petosten havaitseminen,
- sosiaaliset graafit/verkostoituminen,
- suositukset moottorit,
- tietämysgraafit.
Esimerkkejä:
Amazon Neptune, Neo4j, ArangoDB, Titan.
5. Aikasarjat
Se tallentaa tiedot ajallisesti järjestettynä. Tyypillisesti siihen kertyy valtavia määriä tietoja reaaliajassa. Sitä käytetään useimmiten tietojen tallentamiseen, vaikka päivittäminen on hyvin harvinaista. Yleensä aikaleimaa käytetään ensisijaisena avaimena ja/tai tietojen lajittelussa. Joissakin tietokannoissa voidaan määritellä tunnisteita lisätietoina, kuten tietojen alkuperä tai tyyppi.
Milloin valita se?
On hyödyllistä tallentaa pieniä määriä tietoja, jotka on liitetty peräkkäin kronologiseen järjestykseen, esimerkiksi:
- DevOps,
- sovellusten seuranta,
- seuranta ja tapahtumien telemetria,
- IoT sovellukset (kuten tiedonkeruu laitteen antureista).
Esimerkkejä:
Azure Time Series Insights, Amazon Timestream, InfluxDB.
6. Kirjanpito
Se tarjoaa muuttumattoman, läpinäkyvän ja kryptografisesti todennettavan tapahtumalokin, jonka omistaa keskusviranomainen. - Amazonin QLDB:n yleiskatsaus
Selitetään lyhyesti jokainen avainsana edellä olevassa lainauksessa:
- muuttumaton - tarkoittaa, että tähän tietokantaan luotua tietuetta ei voi poistaa, muuttaa tai edes korvata,
- läpinäkyvä - se seuraa ja pitää kirjaa jokaisesta tietojesi muutoksesta,
- kryptografisesti todennettavissa - tähän tietokantaan luodut tiedot todennetaan kryptografisilla hash-tekniikoilla lohkoketjujen tapaan (SHA-256-hash-funktiota käyttäen).
Milloin valita se?
On hyödyllistä tallentaa tarkka historia, esim. kirjaamalla jokaisen tietomuutoksen peräkkäiset kirjaukset, kuten seuraavassa:
- raha-asioita (veloitus- tai luottotapahtumahistoria),
- valmistus (track where parts were sourced),
- vakuutus,
- HR ja palkanlaskenta,
- vähittäiskauppa,
- toimitusketjut.
Esimerkkejä:
Amazon QLDB
Päätelmät
Tämän artikkelin otsikossa esitettyyn kysymykseen ei ole yksinkertaista vastausta. Ainoa tapa valita oikea tietokanta on oppia lisää tiedoistasi. Vastaa kysymykseen: "Millaista dataa sovelluksesi tuottaa?", niin voit tehdä oikeat valinnat.
Lisäksi sinun on tunnettava hyvin liiketoiminnan vaatimukset ja sovellusalue. Sinun on tiedettävä, miten aiot käyttää tietoja, mitä kyselyjä lähetät tietokantaan ja kuinka monta kertaa säilytät, luet, päivität tai poistat tietoja. Kaikilla näillä asioilla on merkitystä, mutta kaikki kehittäjät eivät kiinnitä näihin alueisiin riittävästi huomiota.
Ajattele tietojasi sovelluksessa, jota kehität parantaaksesi/luodaksesi parempia ohjelmistoja. Kaiken kaikkiaan toivon, että opit tuntemaan tietosi tarpeeksi hyvin tallentaaksesi ne paikkaan, jossa ne viihtyvät.
Lue lisää:
Muutamia niksejä JavaScript-sovelluksen nopeuttamiseksi
Tapoja lisätä Railsin suorituskykyä
Faktoja ja myyttejä yhteistyöstä ulkoisen ohjelmistokehityskumppanin kanssa