På få år har en ny heterogen gruppe af databasesystemer erobret verdens opmærksomhed som et mere og mere oplagt alternativ til de relationelle databasesystemer. Opmærksomheden er fuldt fortjent. NoSQL-databaserne repræsenterer en tilgang til databaseteknologi, som har potentialet til fundamentalt at ændre virksomheders it-arkitektur.
Analysehuse, virksomheder og IT-eksperter morer sig fra tid til anden med at konkretisere, hvordan verdens datamængder stiger for hvert sekund. Datahåndteringsselskabet AIS vurderede eksempelvis for nylig, at hvis man havde samlet hele verdens dataregistreringer fra 2012 og brændt dem på DVD-skiver, ville stablen nå til månen og retur fem gange. I samme boldgade har en Cisco-analyse anslået, at verdens datacentre i 2016 samlet set vil håndtere 6,6 zettabytes data om året. Det svarer til, at hver person på jorden dagligt streamer ca. 2,5 timers HD-video. Uanset tankespind og gætterier, så er det et faktum, at verdens datamængder er eksploderet gennem de seneste år. At opbevare disse data er en udfordring, som vi er i stand til at løse. Men når det kommer til at udlede mening af de enorme datamængder – navnlig i realtid – bliver udfordringen af en helt anden karakter.
I databasesammenhæng har SQL siden midten af 1980’erne været det foretrukne standardsprog, når det drejede sig om at opbevare og hente data fra et relationelt databasesystem – eksempelvis MySQL eller Oracle. Data blev opdelt i tabeller og kunne dermed lagres og tilgås efter en fastlagt struktur. Men fra og med de tidlige 00’er begyndte nettet og virksomheder at generere en anden form for data. Data, der i sin natur var meget mere ustrukturerede, og som gjorde modstand mod at blive passet ind i traditionelle tabeller. Det var bl.a. data fra web 2.0-applikationer og sociale medier, billeder, geografisk information, chats osv. Denne ændring i både dataomfang og datatype har ført til opblomstringen af en gruppe af databaser, som benævnes NoSQL, og som inden for de seneste år har vundet større og større udbredelse. Google og Amazon var blandt de første til at anvende NoSQL-databaser, og siden er mange andre fulgt efter. I dag bruger store virksomheder som Facebook, Mozilla, Adobe, Foursquare, LinkedIn og Digg alle NoSQL-databaser. Som et tegn på, at NoSQL-databaser ikke kun er for internetgiganter, men i stigende grad også for “almindelige” virksomheder, havde analysehuset Gartner NoSQL-databaser med i sin rapport ”Emerging Technologies Hype Cycle 2012”.
Sammenfaldende karakteristika
Mens der er bred enighed om, at der er en række databasesystemer på markedet, der er væsensforskellige fra relationelle databasesystemer, er der mindre enighed om en egentlig definition af NoSQL-databaser. Ikke engang den britiske databaseguru Martin Fowler vover at forsøge sig med en egentlig begrebsdefinition. Dertil er de forskellige NoSQL-databaser for forskellige fra hinanden. I stedet kommer han med en række sammenfaldende karakteristika for NoSQL-databaser:
- De bruger (som oftest) ikke SQL-sproget
- Mange er designet til at køre på clusters
- Mange er open source
- De opererer ikke med en fast schema-struktur
Selvom ordlyden af NoSQL ellers foreslår det, så står ‘No’ ikke for ‘Ikke’, men for ‘Not only’ SQL. Det betyder, at NoSQL-databaser faktisk godt kan bruge SQL-lignende query-sprog, men som oftest ikke gør det. Martin Fowlers andet karakteristika henviser til, at relationelle databaser og SQL er designet til at køre på én maskine, mens mange NoSQL-databaser er designet til at køre på store clusters af maskiner. Det gør NoSQL-databaserne i stand til at levere meget højere responstider, fordi systemet lynhurtigt kan distribuere belastningen ud på mange computere. Det tredje karakte-ristika er, at mange af NoSQL-databaserne er open source. Det betyder bl.a., at virksomheder med en begrænset investering kan downloade, implementere og teste, om den pågældende applikation og en given NoSQL-database snakker godt sammen. Endelig opererer NoSQL-databaser ikke med en fast schema-struktur ligesom relationelle databaser. Hvis man som virksomhed eksempelvis gerne vil lagre en kundes telefonnummer, for- og efternavn, adresse og by, skal alle disse data være defineret i en fast struktur i en relationel database. Det betyder, at hele strukturen skal ændres, hvis man eksempelvis vil tilføje kundens foretrukne produkt som en yderligere tabel. Det er dyrt og irriterende. NoSQL-databaser er designet til at tillade tilføjelse af data uden en prædefineret struktur. Det betyder, at man kan ændre i applikationen i realtid uden at bekymre sig om nedetid.
Fra ACID til BASE
Som allerede beskrevet er der flere forskellige måder at anskueliggøre forskellen mellem relationelle og NoSQL-databaser på. Udover rækken af karakteristika ovenfor kan man også stille to databaseregelsæt op over for hinanden. Det første regelsæt hedder ACID (Atomic, Consistent, Isolated, Durable), og det overholder relationelle databaser altid. Det betyder, at en transaktion enten gennemføres fuldstændig eller slet ikke (Atomic), at kun valide data bliver tilføjet databasen (Consistent), at transaktioner aldrig har indvirkning på hinanden (Isolated), og at transaktioner aldrig går tabt (Durable).
NoSQL-databaserne fungerer efter et andet regelsæt kendt som BASE (Basic Availability, Soft state, Eventually consistent). BASE er nemmest at forklare bagfra begyndende med Eventually consistent. Et ACID-system garanterer datakonsistens efter hver transaktion; et BASE-system garanterer datakonsistens inden for en rimelig tidsperiode efter hver transaktion. Med andre ord er der datakonsistens i systemet – bare ikke omgående. Det leder videre til Soft State-princippet. For hvis data ikke er konsistente til enhver tid, må systemet tage højde for en midlertidig tilstand af data – en Soft State. Endelig betyder summen af begge disse principper, at tilgængelighed til data prioriteres meget højt i et NoSQL-system – også selvom der skulle forekomme flere sammenfaldende fejl i databasesystemet, operativsystemet eller hardwaren. Hvis dele af databasen ikke fungerer, tager andre dele af databasen over, så data altid kan tilgås.
En forretningsbeslutning
Virksomheder, konsulenter og eksperter kan hurtigt fortabe sig i junglen af teknologiske muligheder inden for den spirende verden af databasesystemer. For hvornår er et traditionelt relationelt databasesystem bedst egnet til at håndtere virksomhedens data, og hvornår kan man med fordel søge alternativer i mængden af NoSQL-systemer? Svaret på det spørgsmål bør basere sig på en forretningsbeslutning truffet i samarbejde med den IT-ansvarlige. Tag Amazon som eksempel. Amazon besluttede sig meget hurtigt for, at deres forretningsgrundlag var at levere lynhurtig shopping til sine kunder. Til gengæld kunne det godt være, at kunderne fra tid til anden oplevede, at en købt vare alligevel ikke var på lager, fordi data ikke var konsistente. Pyt med det, sagde Amazon. Vi vil bare kendes på, at kunderne altid har mulighed for at shoppe. Det mål harmonerede ikke med regelsættet i et ACID-databasesystem, og derfor udviklede Amazon sit eget databasesystem Dynamo, som bedre understøttede always available-tilgangen. En IT-beslutning truffet på baggrund af en forretningsbeslutning. Amazon havde de økonomiske muskler til at bygge sin egen skræddersyede databasearkitektur. Det er der mange andre, der ikke har. Men pointen er den samme. Det hører fortiden til at vælge det relationelle databasesystem som en automatreaktion.
Fordele og ulemper ved
NoSQL-databaser:
Fordele
- Høj skalerbarhed
- Høj schema-fleksibilitet
- Velegnet til distribuerede
- systemer
- Mindre administrationstunge
- Cloud-venligt
- Lave omkostninger
Ulemper
- Ingen standardisering
- Stadig umodne teknologier
- Begrænsede tooling-muligheder
- Eventual consistency er ikke
- intuitivt at programmere til
