Der er hundredvis af teknisk tunge databaseanmeldelser derude, men de giver ikke altid klar vejledning om det første trin i valg af en database: at vælge den bedste generelle type til en bestemt applikation. Alle databaser oprettes ikke ens. Hver har specifikke styrker og svagheder. Selvom det er rigtigt, at der findes løsninger til at få en favoritdatabase til at fungere for de fleste projekter, tilføjer brug af disse tricks unødvendig kompleksitet.
Før du overvejer en bestemt database, skal du tage dig tid til at overveje, hvilken type der bedst understøtter det aktuelle projekt. Spørgsmålet går dybere end "SQL vs. NoSQL." Læs videre for en oversigt over de mest almindelige databasetyper, de relative fordele for hver og hvordan man fortæller, hvilken der passer bedst.
Relationelle databasestyringssystemer (Oracle, MySQL, MS Server, PostgreSQL)
Relationsdatabaser blev udviklet i 1970'erne for at håndtere den stigende strøm af data, der produceres. De har en solid grundteori og har påvirket næsten ethvert databasesystem, der er i brug i dag.
Relationsdatabaser gemmer datasæt som “relations”: tabeller med rækker og kolonner, hvor al information er gemt som en værdi af en bestemt celle. Data i en RDBMS administreres ved hjælp af SQL. Selvom der er forskellige implementeringer, er SQL standardiseret og giver et niveau af forudsigelighed og nytte.
Efter en tidlig oversvømmelse af leverandører forsøgte at udnytte systemets popularitet med ikke helt relationelle produkter, skabte skaberen E.F. Codd et sæt regler, der skal følges af alle relationelle databasestyringssystemer. Codds 12 regler drejer sig om at indføre strenge interne strukturprotokoller, hvilket sikrer, at søgninger pålideligt returnerer anmodede data og forhindrer strukturelle ændringer (i det mindste af brugerne). Rammen sikrede, at relationsdatabaser er konsistente og pålidelige den dag i dag.
Styrker
Relationsdatabaser udmærker sig ved håndtering af stærkt strukturerede data og yder support til ACID (Atomicitet, Konsistens, Isolering og Holdbarhed) transaktioner. Data gemmes let og hentes ved hjælp af SQL-forespørgsler. Strukturen kan skaleres op hurtigt, fordi det er simpelt at tilføje data uden at ændre eksisterende data.
Oprettelse af grænser for, hvad bestemte brugertyper kan få adgang til eller ændre, er indbygget i en RDBMS-struktur. På grund af dette er relationsdatabaser velegnede til applikationer, der kræver trinvis adgang. For eksempel kunne kunder se deres konti, mens agenter både kunne se og foretage de nødvendige ændringer.
Svagheder
Den største svaghed i relationelle databaser er spejlet i deres største styrke. Så godt som de er til at håndtere strukturerede data, har de svært ved ustrukturerede data. At repræsentere virkelige verdensenheder i sammenhæng er vanskeligt inden for rammerne af en RDBMS. "Skivede" data skal samles fra tabeller til noget mere læsbart, og hastighed kan påvirkes negativt. Det faste skema reagerer heller ikke godt på ændringer.
Omkostninger er en overvejelse med relationelle databaser. De har tendens til at være dyrere at oprette og vokse. Horisontal skalering eller skalering ved at tilføje flere servere er normalt både hurtigere og mere økonomisk end lodret skalering, hvilket indebærer tilføjelse af flere ressourcer til en server. Imidlertid komplicerer strukturen i relationsdatabaser processen. Sharding (hvor data er opdelt vandret og distribueret over en samling maskiner) er nødvendigt for at skalere en relationsdatabase. Det kan være en udfordring at opdele relationsdatabaser, mens ACID-overholdelse opretholdes.
Brug en relationsdatabase til:
- Situationer hvor dataintegritet er absolut altafgørende (dvs. til økonomiske applikationer, forsvar og sikkerhed og private sundhedsoplysninger)
- Meget strukturerede data
- Automatisering af interne processer
Dokumentbutik (MongoDB, Couchbase)
Et dokumentlager er en ikke-relationel database, der gemmer data i JSON-, BSON- eller XML-dokumenter. De har et fleksibelt skema. I modsætning til SQL-databaser, hvor brugere skal erklære en skema for en tabel, inden de indsætter data, håndhæver dokumentlagre ikke dokumentstrukturen. Dokumenter kan indeholde alle ønskede data. De har nøgleværdipar, men integrerer også attributmetadata for at gøre forespørgslen lettere.
Styrker
Dokumentforretninger er meget fleksible. De håndterer semistrukturerede og ustrukturerede data godt. Brugere behøver ikke at vide under opsætning, hvilke typer data der gemmes, så dette er et godt valg, når det ikke på forhånd er klart, hvilken slags data der kommer ind.
Brugere kan oprette deres ønskede struktur i et bestemt dokument uden at påvirke alle dokumenter. Skema kan ændres uden at forårsage nedetid, hvilket fører til høj tilgængelighed. Skrivehastigheden er generelt også hurtig.
Udover fleksibilitet kan udviklere lide dokumentbutikker, fordi de er lette at skalere vandret. Afskæringen, der er nødvendig for vandret skalering, er meget mere intuitiv end med relationelle databaser, så dokumentlagre skaleres hurtigt og effektivt ud.
Svagheder
Dokumentdatabaser ofrer ACID-overholdelse for fleksibilitet. Selvom forespørgsel kan udføres i et dokument, er det ikke muligt på tværs af dokumenter.
Brug en dokumentdatabase til:
- Ustrukturerede eller semistrukturerede data
- Indholdsstyring
- Dybtgående dataanalyse
- Hurtig prototyping
Nøgleværdibutik (Redis, Memcached)
En nøgleværdilager er en type ikke-relationel database, hvor hver værdi er knyttet til en bestemt nøgle. Det er også kendt som et associerende array.
"Nøglen" er en unik identifikator, der kun er knyttet til værdien. Nøgler kan være tilladt af DBMS. I Redis er nøglerne for eksempel enhver binær sekvens op til 512 MB.
"Værdier" gemmes som klatter og har ikke brug for foruddefineret skema. De kan have næsten enhver form: tal, strenge, tællere, JSON, XML, HTML, PHP, binære filer, billeder, korte videoer, lister og endda et andet nøgleværdipar indkapslet i et objekt. Nogle DBMS'er tillader, at datatypen specificeres, men det er ikke obligatorisk.
Styrker
Denne databasestil har mange positive. Det er utroligt fleksibelt og er i stand til nemt at håndtere en meget bred vifte af datatyper. Taster bruges til at gå direkte til værdien uden indeks søgning eller sammenføjninger, så ydeevnen er høj. Bærbarhed er en anden fordel: nøgleværdibutikker kan flyttes fra et system til et andet uden omskrivning af kode. Endelig er de meget vandret skalerbare og har generelt lavere driftsomkostninger.
Svagheder
Fleksibilitet har en pris. Det er umuligt at stille spørgsmål til værdier, fordi de er gemt som en blob og kun kan returneres som sådan. Dette gør det svært at rapportere eller redigere dele af værdier. Ikke alle objekter er heller ikke nemme at modellere som nøgleværdipar.
Brug en nøgleværdilager til:
- Anbefalinger
- Brugerprofiler og indstillinger
- Ustrukturerede data såsom produktanmeldelser eller blogkommentarer
- Sessionsstyring i skala
- Data, der ofte åbnes, men ikke ofte opdateres
Bredkolonnebutik (Cassandra, HBase)
Bredkolonneforretninger, også kaldet kolonneforretninger eller udvidelige pladeforretninger, er dynamiske kolonneorienterede ikke-relaterede databaser. De ses undertiden som en type nøgleværdibutik, men har også attributter til traditionelle relationsdatabaser.
Store kolonnebutikker bruger begrebet nøglerum i stedet for skemaer. Et nøgleområde omfatter kolonnefamilier (svarende til tabeller, men mere fleksible i struktur), som hver indeholder flere rækker med forskellige kolonner. Hver række behøver ikke at have samme antal eller type kolonne. Et tidsstempel bestemmer den nyeste version af data.
Styrker
Denne type database har nogle fordele ved både relationelle og ikke-relaterede databaser. Det handler bedre om både strukturerede og semistrukturerede data end andre ikke-relaterede databaser, og det er lettere at opdatere. Sammenlignet med relationsdatabaser er den mere vandret skalerbar og hurtigere i skala.
Søjledatabaser komprimerer bedre end rækkebaserede systemer. Også store datasæt er enkle at udforske. Bredkolonneforretninger er især gode til aggregeringsforespørgsler, for eksempel.
Svagheder
Skrift er dyrt i det lille. Mens opdatering er let at gøre i bulk, er det svært at uploade og opdatere individuelle poster. Plus, store søjlebutikker er langsommere end relationsdatabaser, når de håndterer transaktioner.
Brug en bred søjlebutik til:
- Big data-analyse, hvor hastighed er vigtig
- Datalager på big data
- Store skala projekter (denne databasestil er ikke et godt værktøj til gennemsnitlige transaktionsapplikationer)
Søgemaskine (Elasticsearch)
Det kan virke underligt at medtage søgemaskiner i en artikel om databasetyper. Imidlertid har Elasticsearch set øget popularitet på dette område, da udviklere ser efter innovative måder at skære ned på søgeforsinkelse. Elastisearch er en ikke-relationel, dokumentbaseret datalagrings- og hentningsløsning, der er specielt arrangeret og optimeret til lagring og hurtig hentning af data.
Styrker
Elastisearch er meget skalerbart. Det har fleksibelt skema og hurtig hentning af poster med avancerede søgemuligheder inklusive fuldtekstsøgning, forslag og komplekse søgeudtryk.
En af de mest interessante søgefunktioner stammer. Stemming analyserer rodformen af et ord for at finde relevante poster, selv når en anden form bruges. For eksempel vil en bruger, der søger i en beskæftigelsesdatabase efter "betalende job", også finde positioner mærket som "betalt" og "løn."
Svagheder
Elastisearch bruges mere som en mellemmand eller supplerende butik end en primær database. Det har lav holdbarhed og dårlig sikkerhed. Der er ingen medfødt godkendelse eller adgangskontrol. Elastisearch understøtter heller ikke transaktioner.
Brug en søgemaskine som Elastisearch til:
- Forbedring af brugeroplevelsen med hurtigere søgeresultater
- Logning
Afsluttende overvejelser
Nogle applikationer passer pænt i styrken af en bestemt databasetype, men for de fleste projekter er der overlapning mellem to eller flere. I disse tilfælde kan det være nyttigt at se på, hvilke specifikke databaser i de anfægtede stilarter, der er gode kandidater. Leverandører tilbyder et bredt spektrum af funktioner til at skræddersy deres database til individuelle standarder. Nogle af disse kan hjælpe med at løse usikkerhed om faktorer som sikkerhed, skalerbarhed og omkostninger.
