At vælge den “rigtige” database kan ofte være afgørende for, at en applikation kan få succes. I stedet for at tage råd fra leverandører eller bruge en database, fordi du allerede har det, er det nyttigt at overveje det grundlæggende formål og kravene i datalageret.
Dette er de vigtigste spørgsmål, du skal stille, når du vælger en database:
- Hvor mange data forventer du at gemme, når applikationen er moden?
- Hvor mange brugere forventer du at håndtere samtidigt ved spidsbelastning?
- Hvilken tilgængelighed, skalerbarhed, latenstid, gennemstrømning og datakonsistens har din applikation brug for?
- Hvor ofte ændres dine databaseskemaer?
- Hvad er den geografiske fordeling af din brugerpopulation?
- Hvad er den naturlige "form" på dine data?
- Har din applikation brug for online transaktionsbehandling (OLTP), analytiske forespørgsler (OLAP) eller begge dele?
- Hvilket forhold mellem læsning og skrivning forventer du i produktionen?
- Har du brug for geografiske forespørgsler og / eller fuldtekstforespørgsler?
- Hvad er dine foretrukne programmeringssprog?
- Har du et budget? Hvis ja, vil det dække licenser og supportkontrakter?
- Er der juridiske begrænsninger for din datalagring?
Lad os udvide disse spørgsmål og deres implikationer.
Hvor meget data gemmer du?
Hvis dit skøn er på gigabyte eller mindre, vil næsten enhver database håndtere dine data, og databaser i hukommelsen er fuldstændige gennemførlige. Der er stadig mange databaseindstillinger til håndtering af data i terabyteområdet (tusinder af gigabyte).
Hvis dit svar er i petabyte (millioner gigabyte) eller mere, vil kun få databaser tjene dig godt, og du skal være forberedt på betydelige datalagringsomkostninger, enten i kapitaludgifter til lokal opbevaring eller i driftsudgifter til Sky lagring. I den målestok vil du muligvis have et lagret lag, så forespørgsler på "live" data kan køre i hukommelsen eller mod lokale SSD'er for hurtigere, mens det fulde datasæt ligger på spindende diske for at spare økonomi.
Hvor mange samtidige brugere?
Estimering af belastningen fra mange samtidige brugere behandles ofte som en serverstørrelsesøvelse, der skal udføres lige før installation af din produktionsdatabase. Desværre kan mange databaser bare ikke håndtere tusindvis af brugere, der spørger terabyte eller petabyte data på grund af skaleringsproblemer.
Det er meget lettere at estimere samtidige brugere for en database, der bruges af medarbejderne, end for en offentlig database. For sidstnævnte skal du muligvis have mulighed for at skalere ud til flere servere for uventede eller sæsonbestemte belastninger. Desværre understøtter ikke alle databaser vandret skalering uden tidskrævende manuel deling af de store tabeller.
Hvad er dine '-ility' krav?
I denne kategori inkluderer jeg tilgængelighed, skalerbarhed, latenstid, gennemstrømning og datakonsistens, selvom ikke alle udtryk ender med "-ility".
Tilgængelighed er ofte et nøglekriterium for transaktionsdatabaser. Selvom ikke alle applikationer skal køre 24/7 med 99,999% tilgængelighed, gør nogle det. Et par skydatabaser tilbyder "fem-nines" tilgængelighed, så længe du kører dem i flere tilgængelighedszoner. Lokale databaser kan normalt konfigureres til høj tilgængelighed uden for planlagte vedligeholdelsesperioder, især hvis du har råd til at oprette et aktivt aktivt par servere.
Skalerbarhed, især vandret skalerbarhed, har historisk været bedre for NoSQL-databaser end SQL-databaser, men flere SQL-databaser er ved at indhente. Dynamisk skalerbarhed er meget lettere at opnå i skyen. Databaser med god skalerbarhed kan håndtere mange samtidige brugere ved at skalere op eller ud, indtil kapaciteten er tilstrækkelig til belastningen.
Latency henviser både til databasens responstid og til end-til-end responstid for applikationen. Ideelt set vil enhver brugerhandling have en responstid på under et sekund; der ofte oversættes til, at databasen skal svare på under 100 millisekunder for hver enkel transaktion. Analytiske forespørgsler kan ofte tage sekunder eller minutter. Applikationer kan bevare svartiden ved at køre komplicerede forespørgsler i baggrunden.
Gennemstrømning for en OLTP-database måles normalt i transaktioner pr. Sekund. Databaser med høj kapacitet kan understøtte mange samtidige brugere.
Datakonsistens er normalt “stærk” for SQL-databaser, hvilket betyder, at alle læsninger returnerer de nyeste data. Datakonsistens kan være alt fra “eventuel” til “stærk” for NoSQL-databaser. Eventuel konsistens giver lavere ventetid med risiko for at læse uaktuelle data.
Konsistens er “C” i ACID-egenskaberne, der kræves for gyldighed i tilfælde af fejl, netværkspartitioner og strømsvigt. De fire syreegenskaber er atomicitet, konsistens, isolering og holdbarhed.
Er dine databaseskemaer stabile?
Hvis dine databaseskemaer sandsynligvis ikke ændres væsentligt over tid, og du vil have, at de fleste felter har ensartede typer fra post til post, ville SQL-databaser være et godt valg for dig. Ellers kan NoSQL-databaser, hvoraf nogle ikke engang understøtter skemaer, være bedre for din applikation. Der er dog undtagelser. For eksempel tillader Rockset SQL-forespørgsler uden at pålægge et fast skema eller ensartede typer på de data, det importerer.
Geografisk fordeling af brugere
Når dine databasebrugere er over hele verden, påfører lyshastigheden en lavere grænse for databaselatens for fjernbrugere, medmindre du leverer yderligere servere i deres regioner. Nogle databaser tillader distribuerede læse-skriv-servere; andre tilbyder distribuerede skrivebeskyttede servere, hvor alle skrivninger er tvunget til at gå gennem en enkelt masterserver. Geografisk fordeling gør afvejningen mellem konsistens og latenstid endnu sværere.
De fleste af databaser, der understøtter globalt distribuerede noder og stærk konsistens, bruger konsensusgrupper til at fremskynde skrivning uden alvorligt nedværdigende konsistens, typisk ved hjælp af algoritmerne Paxos (Lamport, 1990) eller Raft (Ongaro og Ousterhout, 2013). Distribuerede NoSQL-databaser, der i sidste ende er konsistente, bruger typisk ikke-konsensus-peer-to-peer-replikering, hvilket kan føre til konflikter, når to replikaer modtager samtidige skrivninger til samme post, konflikter, som normalt løses heuristisk.
Dataform
SQL-databaser gemmer klassisk stærkt indtastede data i rektangulære tabeller med rækker og kolonner. De er afhængige af definerede relationer mellem tabeller, bruger indekser til at fremskynde valgte forespørgsler og bruger JOINS til at forespørge flere tabeller på én gang. Dokumentdatabaser gemmer typisk svagt skrevet JSON, der kan omfatte arrays og indlejrede dokumenter. Grafdatabaser gemmer enten toppunkter og kanter eller tredobler eller quads. Andre NoSQL-databasekategorier inkluderer nøgleværdi og søjleforretninger.
Nogle gange genereres dataene i en form, der også fungerer til analyse; nogle gange er det ikke, og en transformation vil være nødvendig. Nogle gange er en slags database bygget på en anden. For eksempel kan nøgleværdibutikker ligge til grund for næsten enhver form for database.
OLTP, OLAP eller HTAP?
For at afkode akronymerne ovenfor er spørgsmålet, om din applikation har brug for en database til transaktioner, analyse eller begge dele. Brug af hurtige transaktioner indebærer hurtig skrivehastighed og minimale indekser. Behovsanalyse indebærer hurtig læsehastighed og mange indekser. Hybride systemer bruger forskellige tricks til at understøtte begge krav, herunder at have en primær transaktionsbutik, der fodrer en sekundær analyselager gennem replikering.
Læs / skriv-forhold
Nogle databaser er hurtigere ved læsning og forespørgsler, og andre er hurtigere ved skrivning. Den blanding af læser og skriver, du forventer af din applikation, er et nyttigt tal, der skal medtages i dine databasevalgskriterier, og kan styre din benchmarkingindsats. Det optimale valg af indekstype adskiller sig mellem læsetunge applikationer (normalt et B-træ) og skrivetunge applikationer (ofte et logstruktureret fletræ, også kaldet LSM-træ).
Geospatiale indekser og forespørgsler
Hvis du har geografiske eller geometriske data, og du vil udføre effektive forespørgsler for at finde objekter inden for en grænse eller objekter inden for en given afstand fra en placering, har du brug for andre indekser, end du ville have for typiske relationsdata. Et R-træ er ofte det foretrukne valg for geospatiale indekser, men der er mere end et dusin andre mulige geospatiale indeksdatastrukturer. Der er et par dusin databaser, der understøtter geodata; de fleste understøtter nogle eller hele Open Geospatial Consortium-standarden.
Fuldtekstindekser og forespørgsler
Tilsvarende kræver effektiv fuldtekstsøgning af tekstfelter forskellige indekser end relationelle eller geospatiale data. Typisk opbygger du et omvendt listeindeks over tokeniserede ord og søger efter det for at undgå at lave en dyr bordscanning.
Foretrukne programmeringssprog
Mens de fleste databaser understøtter API'er til mange programmeringssprog, kan det foretrukne programmeringssprog i din applikation undertiden påvirke dit valg af database. For eksempel er JSON det naturlige dataformat for JavaScript, så det kan være en god idé at vælge en database, der understøtter JSON-datatypen til en JavaScript-applikation. Når du bruger et stærkt skrevet programmeringssprog, kan det være en god idé at vælge en stærkt skrevet database.
Budgetmæssige begrænsninger
Databaser varierer i pris fra gratis til meget dyre. Mange databaser har både gratis og betalte versioner og har undertiden mere end et niveau af betalte tilbud, for eksempel tilbyder de en Enterprise-version og forskellige servicetider. Derudover er nogle databaser tilgængelige i skyen på pay-as-you-go-vilkår.
Hvis du vælger en gratis open source-database, skal du muligvis give afkald på leverandørsupport. Så længe du har ekspertise internt, kan det være fint. På den anden side kan det være mere produktivt for dine medarbejdere at koncentrere sig om applikationen og overlade databaseadministration og vedligeholdelse til leverandører eller skyudbydere.
Juridiske begrænsninger
Der er mange love om datasikkerhed og privatliv. I EU har GDPR vidtrækkende konsekvenser for privatlivets fred, databeskyttelse og placeringen af data. I USA regulerer HIPAA medicinsk information, og GLBA regulerer den måde, hvorpå finansielle institutioner håndterer kunders private information. I Californien forbedrer den nye CCPA fortrolighedsrettigheder og forbrugerbeskyttelse.
Nogle databaser er i stand til at håndtere data på en måde, der overholder nogle eller alle disse regler, så længe du følger bedste praksis. Andre databaser har mangler, der gør det meget vanskeligt at bruge dem til personligt identificerbare oplysninger, uanset hvor forsigtig du er.
Ærligt talt var det en lang liste over faktorer, der skal overvejes, når du vælger en database, sandsynligvis mere end du foretrækker at overveje. Ikke desto mindre er det værd at forsøge at besvare alle spørgsmålene bedst muligt af dit team, før du risikerer at forpligte dit projekt til det, der viser sig at være en utilstrækkelig eller for dyr database.
