Å velge den “riktige” databasen kan ofte være avgjørende for at en applikasjon lykkes. I stedet for å ta råd fra leverandører eller bruke en database fordi du allerede har det, er det nyttig å vurdere det grunnleggende formålet og kravene til datalageret.
Dette er de viktigste spørsmålene du må stille når du velger en database:
- Hvor mye data forventer du å lagre når applikasjonen er moden?
- Hvor mange brukere forventer du å håndtere samtidig ved toppbelastning?
- Hvilken tilgjengelighet, skalerbarhet, ventetid, gjennomstrømning og datakonsistens trenger applikasjonen din?
- Hvor ofte vil databaseskjemaene dine endres?
- Hva er den geografiske fordelingen av brukerpopulasjonen din?
- Hva er den naturlige "formen" på dataene dine?
- Trenger søknaden din online transaksjonsbehandling (OLTP), analytiske spørsmål (OLAP) eller begge deler?
- Hvilket forhold mellom lesing og skriving forventer du i produksjonen?
- Trenger du geografiske spørsmål og / eller fulltekstspørsmål?
- Hva er dine foretrukne programmeringsspråk?
- Har du et budsjett? I så fall vil det dekke lisenser og støttekontrakter?
- Er det lovlige begrensninger på datalagringen din?
La oss utvide disse spørsmålene og deres implikasjoner.
Hvor mye data vil du lagre?
Hvis estimatet ditt er på gigabyte eller mindre, vil nesten hvilken som helst database håndtere dataene dine, og databaser i minnet er fullstendig gjennomførbare. Det er fortsatt mange databasealternativer for å håndtere data i terabyteområdet (tusenvis av gigabyte).
Hvis svaret ditt er i petabyte (millioner gigabyte) eller mer, vil bare noen få databaser tjene deg godt, og du må være forberedt på betydelige datalagringskostnader, enten i kapitalutgifter for lokal lagring eller i driftsutgifter til skylagring. På den skalaen vil du kanskje ha lagdelt lagring slik at spørringer om "live" data kan kjøre i minnet eller mot lokale SSD-er for hastighet, mens hele datasettet ligger på spinnende disker for å spare økonomi.
Hvor mange samtidige brukere?
Å estimere belastningen fra mange samtidige brukere blir ofte behandlet som en serverstørrelsesøvelse som skal gjøres rett før installasjon av produksjonsdatabasen. Dessverre kan mange databaser ikke håndtere tusenvis av brukere som spør etter terabyte eller petabyte med data på grunn av skaleringsproblemer.
Å estimere samtidige brukere er mye lettere for en database som brukes av ansatte enn for en offentlig database. For sistnevnte kan det hende du må ha muligheten til å skalere ut til flere servere for uventede eller sesongmessige belastninger. Dessverre støtter ikke alle databaser horisontal skalering uten tidkrevende manuell skjæring av de store tabellene.
Hva er dine '-ility' krav?
I denne kategorien inkluderer jeg tilgjengelighet, skalerbarhet, ventetid, gjennomstrømning og datakonsistens, selv om ikke alle ord slutter med "-ility".
Tilgjengelighet er ofte et nøkkelkriterium for transaksjonsdatabaser. Selv om ikke alle applikasjoner trenger å kjøre 24/7 med 99,999% tilgjengelighet, gjør noen det. Noen få skydatabaser tilbyr "fem-nines" tilgjengelighet, så lenge du kjører dem i flere tilgjengelighetssoner. Lokale databaser kan vanligvis konfigureres for høy tilgjengelighet utenfor planlagte vedlikeholdsperioder, spesielt hvis du har råd til å sette opp et aktivt aktivt serverpar.
Skalerbarhet, spesielt horisontal skalerbarhet, har historisk vært bedre for NoSQL-databaser enn SQL-databaser, men flere SQL-databaser fanger opp. Dynamisk skalerbarhet er mye lettere å oppnå i skyen. Databaser med god skalerbarhet kan håndtere mange samtidige brukere ved å skalere opp eller ut til gjennomstrømningen er tilstrekkelig for belastningen.
Latens refererer både til responstiden til databasen og til end-to-end responstid for applikasjonen. Ideelt sett vil hver brukerhandling ha en responstid på under et sekund; som ofte oversettes til at databasen trenger å svare på under 100 millisekunder for hver enkle transaksjon. Analytiske spørsmål kan ofte ta sekunder eller minutter. Programmer kan bevare responstiden ved å kjøre kompliserte spørsmål i bakgrunnen.
Gjennomstrømning for en OLTP-database måles vanligvis i transaksjoner per sekund. Databaser med høy gjennomstrømning kan støtte mange samtidige brukere.
Datakonsistens er vanligvis “sterk” for SQL-databaser, noe som betyr at alle lesinger returnerer de nyeste dataene. Datakonsistens kan være alt fra “eventuell” til “sterk” for NoSQL-databaser. Eventuell konsistens gir lavere ventetid, med risiko for å lese foreldede data.
Konsistens er "C" i ACID-egenskapene som kreves for gyldighet i tilfelle feil, nettverkspartisjoner og strømbrudd. De fire syreegenskapene er atomitet, konsistens, isolasjon og holdbarhet.
Er databaseskjemaene dine stabile?
Hvis det er lite sannsynlig at databaseskjemaene dine vil endre seg betydelig over tid, og du vil at de fleste felt skal ha konsistente typer fra post til post, vil SQL-databaser være et godt valg for deg. Ellers kan NoSQL-databaser, hvorav noen ikke støtter skjemaer, være bedre for applikasjonen din. Det er imidlertid unntak. For eksempel tillater Rockset SQL-spørsmål uten å pålegge et fast skjema eller konsistente typer på dataene det importerer.
Geografisk fordeling av brukere
Når databasebrukerne dine er over hele verden, setter lyshastigheten en lavere grense for databasenes forsinkelse for de eksterne brukerne, med mindre du gir flere servere i deres regioner. Noen databaser tillater distribuerte lese- og skriveservere; andre tilbyr distribuerte skrivebeskyttede servere, med alle skrifter tvunget til å gå gjennom en enkelt masterserver. Geografisk fordeling gjør avveiningen mellom konsistens og ventetid enda vanskeligere.
De fleste databasene som støtter globalt distribuerte noder og sterk konsistens, bruker konsensusgrupper for å øke hastigheten på skriving uten alvorlig nedverdigende konsistens, vanligvis ved bruk av Paxos (Lamport, 1990) eller Raft (Ongaro og Ousterhout, 2013) algoritmer. Distribuerte NoSQL-databaser som til slutt er konsistente, bruker vanligvis ikke-konsensus-peer-to-peer-replikering, noe som kan føre til konflikter når to replikaer mottar samtidige skrivinger til samme post, konflikter som vanligvis løses heuristisk.
Dataform
SQL-databaser lagrer klassisk data med sterk inntasting i rektangulære tabeller med rader og kolonner. De er avhengige av definerte forhold mellom tabeller, bruker indekser for å øke hastigheten på valgte spørsmål, og bruker JOINS til å spørre flere tabeller samtidig. Dokumentdatabaser lagrer vanligvis svakt skrevet JSON som kan inneholde matriser og nestede dokumenter. Grafdatabaser lagrer enten toppunkt og kanter, eller tredobler eller firhjulinger. Andre NoSQL-databasekategorier inkluderer nøkkelverdi- og søylebutikker.
Noen ganger genereres dataene i en form som også fungerer for analyse; noen ganger er det ikke, og en transformasjon vil være nødvendig. Noen ganger er en type database bygget på en annen. For eksempel kan nøkkelverdibutikker ligge til grunn for nesten alle slags databaser.
OLTP, OLAP eller HTAP?
For å fjerne forkortelsene ovenfor, er spørsmålet om søknaden din trenger en database for transaksjoner, analyse eller begge deler. Å trenge raske transaksjoner innebærer rask skrivehastighet og minimale indekser. Behovsanalyse innebærer rask lesehastighet og mange indekser. Hybrid-systemer bruker forskjellige triks for å støtte begge kravene, inkludert å ha en primær transaksjonsbutikk som mater en sekundær analyselager gjennom replikering.
Les / skriv-forhold
Noen databaser er raskere ved lesing og spørsmål, og andre er raskere ved skriving. Blandingen av leser og skriver du forventer av søknaden din, er et nyttig nummer å inkludere i kriteriene for databasevalg, og kan lede din benchmarkinginnsats. Det optimale valget av indekstype er forskjellig mellom lese-tunge applikasjoner (vanligvis et B-tre) og skrive-tunge applikasjoner (ofte et loggstrukturert flette-tre, også kalt LSM-tre).
Geospatiale indekser og spørsmål
Hvis du har geografiske eller geometriske data og vil utføre effektive spørsmål for å finne objekter innenfor en grense eller objekter innenfor en gitt avstand fra et sted, trenger du andre indekser enn du ville gjort for typiske relasjonsdata. Et R-tre er ofte det foretrukne valget for geospatiale indekser, men det er mer enn et dusin andre mulige geospatiale indeksdatastrukturer. Det er et par dusin databaser som støtter geodata; de fleste støtter noen eller hele Open Geospatial Consortium-standarden.
Fulltekstindekser og spørsmål
Tilsvarende krever effektiv fulltekstsøk i tekstfelt andre indekser enn relasjons- eller geospatiale data. Vanligvis bygger du en omvendt listeindeks over tokeniserte ord og søker etter det for å unngå å gjøre en kostbar tabellskanning.
Foretrukne programmeringsspråk
Mens de fleste databaser støtter API-er for mange programmeringsspråk, kan det foretrukne programmeringsspråket i applikasjonen noen ganger påvirke valget av database. For eksempel er JSON det naturlige dataformatet for JavaScript, så det kan være lurt å velge en database som støtter JSON-datatypen for et JavaScript-program. Når du bruker et sterkt skrevet programmeringsspråk, kan det være lurt å velge en sterkt skrevet database.
Budsjettmessige begrensninger
Databaser varierer i pris fra gratis til veldig dyre. Mange databaser har både gratis og betalte versjoner, og noen ganger har de mer enn ett nivå av betalt tilbud, for eksempel å tilby en Enterprise-versjon og forskjellige responstider for tjenestene. I tillegg er noen databaser tilgjengelig i skyen på betalingsvilkår.
Hvis du velger en gratis, åpen kildekodedatabase, kan det hende du må avstå fra leverandørstøtte. Så lenge du har kompetanse internt, kan det være greit. På den annen side kan det være mer produktivt for folkene dine å konsentrere seg om applikasjonen og overlate databaseadministrasjon og vedlikehold til leverandører eller skyleverandører.
Juridiske begrensninger
Det er mange lover om datasikkerhet og personvern. I EU har GDPR omfattende implikasjoner for personvern, databeskyttelse og plasseringen av data. I USA regulerer HIPAA medisinsk informasjon, og GLBA regulerer måten finansielle institusjoner håndterer kundenes private informasjon på. I California forbedrer den nye CCPA personvernrettighetene og forbrukerbeskyttelsen.
Noen databaser er i stand til å håndtere data på en måte som er i samsvar med noen eller alle disse reglene, så lenge du følger beste praksis. Andre databaser har feil som gjør det veldig vanskelig å bruke dem til personlig identifiserbar informasjon, uansett hvor forsiktig du er.
Ærlig talt, det var en lang liste med faktorer du bør vurdere når du velger en database, sannsynligvis mer enn du foretrekker å vurdere. Likevel er det verdt å prøve å svare på alle spørsmålene etter beste evne til teamet ditt før du risikerer å forplikte prosjektet til det som viser seg å være en utilstrekkelig eller for dyr database.
