Oikean tietokannan valitseminen voi usein olla kriittinen sovelluksen onnistumisen kannalta. Sen sijaan, että ottaisit myyjiltä neuvoja tai käytät tietokantaa, koska sinulla jo on niitä, on hyödyllistä ottaa huomioon tietovaraston perustarkoitus ja vaatimukset.
Nämä ovat tärkeimmät kysymykset, jotka on esitettävä tietokantaa valittaessa:
- Kuinka paljon tietoja aiot tallentaa, kun sovellus on kypsä?
- Kuinka monen käyttäjän odotat käsittelevän samanaikaisesti huippukuormituksella?
- Mitä saatavuutta, skaalautuvuutta, viivettä, läpäisykykyä ja tietojen yhdenmukaisuutta sovelluksesi tarvitsee?
- Kuinka usein tietokantamallisi muuttuvat?
- Mikä on käyttäjäryhmäsi maantieteellinen jakauma?
- Mikä on tietojesi luonnollinen muoto?
- Tarvitseeko sovelluksesi verkkotapahtumien käsittelyä (OLTP), analyyttisiä kyselyjä (OLAP) vai molempia?
- Minkä luku- ja kirjoitussuhteen odotat tuotannossa?
- Tarvitsetko maantieteellisiä kyselyjä ja / tai kokotekstikyselyjä?
- Mitkä ovat haluamasi ohjelmointikielet?
- Onko sinulla budjettia? Jos on, kattako se lisenssit ja tukisopimukset?
- Onko tietojesi tallennuksessa laillisia rajoituksia?
Tarkastellaanpa näitä kysymyksiä ja niiden seurauksia.
Kuinka paljon tietoja tallennat?
Jos arvio on gigatavuissa tai vähemmän, lähes kaikki tietokannat käsittelevät tietojasi, ja muistissa olevat tietokannat ovat täysin mahdollisia. Teratavuilla (tuhansilla gigatavuilla) olevien tietojen käsittelyyn on edelleen monia tietokantavaihtoehtoja.
Jos vastauksesi on petatavuina (miljoonina gigatavuina) tai enemmän, vain muutama tietokanta palvelee sinua hyvin, ja sinun on oltava valmis varautumaan merkittäviin tietovarastokustannuksiin joko paikan päällä tapahtuvaan varastointiin tai käyttömenoihin. pilvitallennus. Tässä mittakaavassa saatat haluta porrastettua tallennustilaa, jotta "elävien" tietojen kyselyt voidaan suorittaa muistissa tai paikallisia SSD-asemia vastaan nopeuden vuoksi, kun taas koko tietojoukko sijaitsee pyörivillä levyillä taloudellisuuden vuoksi.
Kuinka monta samanaikaista käyttäjää?
Monien samanaikaisten käyttäjien kuormituksen arviointia pidetään usein palvelimen mitoitusharjoituksena, joka on tehtävä juuri ennen tuotantotietokannan asentamista. Valitettavasti monet tietokannat eivät yksinkertaisesti pysty käsittelemään tuhansia käyttäjiä, jotka kyselevät teratavuja tai petatavuja tietoja skaalausongelmien takia.
Samanaikaisen käyttäjän arvioiminen on paljon helpompaa työntekijöiden käyttämälle tietokannalle kuin julkiselle tietokannalle. Jälkimmäistä varten sinulla voi olla mahdollisuus skaalata useille palvelimille odottamattomien tai kausiluonteisten kuormitusten varalta. Valitettavasti kaikki tietokannat eivät tue vaakasuuntaista skaalausta ilman aikaa vievää suurten pöytien manuaalista sirpaloitumista.
Mitkä ovat "-vaatimuksesi"?
Tähän luokkaan kuuluvat käytettävyys, skaalautuvuus, viive, läpäisykyky ja tietojen yhdenmukaisuus, vaikka kaikki termit eivät pääty "-joustavuuteen".
Saatavuus on usein keskeinen kriteeri transaktiotietokannoille. Vaikka kaikkien sovellusten ei tarvitse toimia 24 tuntia vuorokaudessa, ja niiden saatavuus on 99,999%, jotkut tarvitsevat. Muutamat pilvitietokannat tarjoavat ”viiden yhdeksän” saatavuuden, kunhan niitä käytetään useilla käytettävyysalueilla. Paikallisissa tietokannoissa voidaan yleensä määrittää korkea käytettävyys aikataulun mukaisten ylläpitojaksojen ulkopuolella, varsinkin jos sinulla on varaa perustaa aktiivinen-aktiivinen palvelinpari.
Skaalautuvuus, erityisesti horisontaalinen skaalautuvuus, on perinteisesti ollut parempi NoSQL-tietokannoille kuin SQL-tietokannoille, mutta useat SQL-tietokannat ovat kiinni. Dynaaminen skaalautuvuus on paljon helpompi saavuttaa pilvessä. Hyvin skaalautuvat tietokannat pystyvät käsittelemään monia samanaikaisia käyttäjiä suurentamalla tai pienentämällä, kunnes suoritusteho on riittävä kuormalle.
Viive tarkoittaa sekä tietokannan vasteaikaa että sovelluksen päästä päähän -vasteaikaa. Ihannetapauksessa jokaisella käyttäjän toiminnolla on alle sekunnin vasteaika; Tämä tarkoittaa usein tietokannan tarvetta vastaamaan alle 100 millisekunnissa jokaisesta yksinkertaisesta tapahtumasta. Analyyttiset kyselyt voivat usein kestää sekunteja tai minuutteja. Sovellukset voivat säästää vasteaikaa suorittamalla monimutkaisia kyselyitä taustalla.
OLTP-tietokannan suorituskyky mitataan yleensä tapahtumina sekunnissa. Suuren suorituskyvyn tietokannat voivat tukea monia samanaikaisia käyttäjiä.
Tietojen yhdenmukaisuus on yleensä "vahva" SQL-tietokannoille, mikä tarkoittaa, että kaikki lukut palauttavat uusimmat tiedot. Tietojen yhdenmukaisuus voi olla mitä tahansa NoSQL-tietokantojen "mahdollisesta" ja "vahvasta". Lopullinen johdonmukaisuus tarjoaa pienemmän viiveen, vaarana vanhentuneiden tietojen lukeminen.
Johdonmukaisuus on ”C” ACID-ominaisuuksissa, joita tarvitaan voimassaololle virheiden, verkko-osioiden ja virtakatkosten yhteydessä. Neljä hapon ominaisuutta ovat atomisuus, johdonmukaisuus, eristäminen ja kestävyys.
Ovatko tietokantamallisi vakaat?
Jos tietokantamallisi eivät todennäköisesti muutu merkittävästi ajan myötä ja haluat, että useimmilla kentillä on yhdenmukaiset tyypit tietueesta toiseen, SQL-tietokannat olisivat hyvä valinta sinulle. Muuten NoSQL-tietokannat, joista osa ei edes tue skeemejä, saattavat olla parempia sovelluksellesi. On kuitenkin poikkeuksia. Esimerkiksi Rockset sallii SQL-kyselyt asettamatta kiinteää mallia tai yhtenäisiä tyyppejä tuoduille tiedoille.
Käyttäjien maantieteellinen jakauma
Kun tietokannan käyttäjät ovat kaikkialla maailmassa, valon nopeus asettaa alarajan tietokannan viiveelle etäkäyttäjille, ellet tarjoa lisäpalvelimia heidän alueilleen. Jotkut tietokannat sallivat hajautetut kirjoituspalvelimet; toiset tarjoavat hajautettuja vain luku -palvelimia, ja kaikki kirjoitukset pakotetaan käymään yhden pääpalvelimen läpi. Maantieteellinen jakauma tekee johdonmukaisuuden ja latenssin välisen kompromissin vielä vaikeammaksi.
Suurin osa maailmanlaajuisesti hajautettuja solmuja ja vahvaa yhdenmukaisuutta tukevista tietokannoista käyttää konsensusryhmiä kirjoitusten nopeuttamiseksi vakavasti heikentämättä johdonmukaisuutta, yleensä käyttämällä Paxos (Lamport, 1990) tai Raft (Ongaro ja Ousterhout, 2013) algoritmeja. Hajautetut NoSQL-tietokannat, jotka ovat lopulta yhdenmukaisia, käyttävät yleensä yksimielisyyttä, peer-to-peer replikointia, mikä voi johtaa konflikteihin, kun kaksi kopiota saa samanaikaisesti kirjoja samaan tietueeseen, konfliktit, jotka yleensä ratkaistaan heuristisesti.
Tietojen muoto
SQL-tietokannat tallentavat voimakkaasti kirjoitettua tietoa klassisesti suorakaiteen muotoisiin taulukoihin, joissa on rivejä ja sarakkeita. He luottavat määriteltyihin taulukkojen välisiin suhteisiin, nopeuttavat valittuja kyselyitä hakemistoilla ja käyttävät JOINSia useiden taulukoiden kyselyyn kerralla. Asiakirjatietokannoissa on tyypillisesti heikosti kirjoitettu JSON, joka voi sisältää taulukoita ja sisäkkäisiä asiakirjoja. Graafitietokannat joko tallentavat kärkipisteitä ja reunoja, tai kolminkertaisia tai nelinkertaisia. Muita NoSQL-tietokantaluokkia ovat avainarvot ja sarakemyymälät.
Joskus tiedot luodaan muodossa, joka toimii myös analyysia varten; joskus ei ole, ja muutos on tarpeen. Joskus tietyntyyppinen tietokanta rakennetaan toiselle. Esimerkiksi avainarvomyymälät voivat olla melkein minkä tahansa tyyppisen tietokannan taustalla.
OLTP, OLAP tai HTAP?
Yllä olevien lyhenteiden purkamiseksi on kysymys siitä, tarvitseeko sovelluksesi tietokanta tapahtumia, analyysejä tai molempia varten. Nopeat tapahtumat edellyttävät nopeaa kirjoitusnopeutta ja minimaalisia hakemistoja. Analyysin tarve tarkoittaa nopeaa lukunopeutta ja paljon hakemistoja. Hybridijärjestelmät käyttävät erilaisia temppuja molempien vaatimusten tukemiseksi, mukaan lukien ensisijaisen transaktiovaraston syöttäminen toissijaiseen analyysivarastoon replikaation avulla.
Luku / kirjoitus -suhde
Jotkut tietokannat ovat nopeampia lukemisissa ja kyselyissä ja toiset nopeammin kirjoittamisessa. Sovelluksestasi odotettavissa olevien lukujen ja kirjoitusten yhdistelmä on hyödyllinen numero sisällytettäväksi tietokannan valintaperusteisiin, ja se voi ohjata esikuva-analyysejäsi. Hakemistotyypin optimaalinen valinta eroaa toisistaan luettavien sovellusten (yleensä B-puu) ja kirjoitusraskaiden sovellusten (usein lokirakenteinen yhdistämispuu eli LSM-puu) välillä.
Paikkatieteelliset hakemistot ja kyselyt
Jos sinulla on maantieteellisiä tai geometrisia tietoja ja haluat suorittaa tehokkaita kyselyitä löytääksesi objekteja rajan sisällä tai esineitä tietyllä etäisyydellä sijainnista, tarvitset erilaisia hakemistoja kuin tavallisten relaatiotietojen kohdalla. R-puu on usein ensisijainen valinta paikkatietohakemistoille, mutta muita paikkatietopohjaisia hakemistotietorakenteita on yli tusina. Paikkatietoja tukevia tietokantoja on pari tusinaa; suurin osa tukee jotakin tai kaikkia Open Geospatial Consortium -standardeja.
Koko tekstihakemistot ja kyselyt
Vastaavasti tehokas tekstikenttien kokotekstihaku vaatii erilaisia hakemistoja kuin relaatio- tai paikkatiedot. Tyypillisesti rakennat käänteisen luettelomerkin tunnisteellisista sanoista ja etsit sitä välttääksesi kalliita taulukon skannauksia.
Ensisijaiset ohjelmointikielet
Vaikka useimmat tietokannat tukevat sovellusliittymiä monille ohjelmointikielille, sovelluksesi ensisijainen ohjelmointikieli voi joskus vaikuttaa tietokantavalintasi. Esimerkiksi JSON on JavaScriptin luonnollinen tietomuoto, joten kannattaa ehkä valita tietokanta, joka tukee JSON-tietotyyppiä JavaScript-sovelluksessa. Kun käytät voimakkaasti kirjoitettua ohjelmointikieliä, kannattaa ehkä valita vahvasti kirjoitettu tietokanta.
Budjettirajoitukset
Tietokantojen hinta vaihtelee ilmaiseksi erittäin kalliiksi. Monissa tietokannoissa on sekä ilmaisia että maksettuja versioita, ja joskus niissä on useampi kuin yksi tasoinen tarjous, esimerkiksi yritysversio ja erilaiset palvelun vasteajat. Lisäksi jotkut tietokannat ovat käytettävissä pilvessä maksullisin ehdoin.
Jos valitset ilmaisen, avoimen lähdekoodin tietokannan, saatat joutua luopumaan toimittajien tuesta. Niin kauan kuin sinulla on sisäistä asiantuntemusta, se voi olla hieno. Toisaalta ihmisillesi voi olla tuottavampaa keskittyä sovellukseen ja jättää tietokannan hallinta ja ylläpito toimittajien tai pilvipalvelujen tarjoajille.
Lailliset rajoitukset
Tietoturvasta ja yksityisyydestä on monia lakeja. EU: ssa GDPR: llä on laaja vaikutus yksityisyyteen, tietosuojaan ja tietojen sijaintiin. Yhdysvalloissa HIPAA säätelee lääketieteellistä tietoa ja GLBA sääntelee tapaa, jolla rahoituslaitokset käsittelevät asiakkaiden yksityisiä tietoja. Kaliforniassa uusi CCPA parantaa yksityisyyden suojaa ja kuluttajansuojaa.
Jotkut tietokannat pystyvät käsittelemään tietoja tavalla, joka noudattaa kaikkia tai kaikkia näitä säännöksiä, kunhan noudatat parhaita käytäntöjä. Muissa tietokannoissa on puutteita, jotka vaikeuttavat niiden käyttöä henkilötietojen tunnistamiseen riippumatta siitä, kuinka varovainen olet.
Rehellisesti, se oli pitkä luettelo tekijöistä, jotka on otettava huomioon tietokantaa valittaessa, todennäköisesti enemmän kuin haluat mieluummin harkita. Siitä huolimatta kannattaa yrittää vastata kaikkiin kysymyksiin tiimisi parhaalla mahdollisella tavalla, ennen kuin riskoit sitouttaa projektisi puutteelliseksi tai liian kalliiksi tietokannaksi.
