NoSQL-databaser har fået meget stor opmærksomhed på meget kort tid. Udpeget af nogle som løsningen på fremtidens databaseudfordringer, forhadt af andre som unødvendige teknologiske benspænd. Uanset om man er for eller imod NoSQL-systemerne, har den megen hype ført til den fejlagtige slutning, at den relationelle database efter 20 års dominans er på vej til at uddø. Det er den bestemt ikke, siger databaseguruen Martin Fowler i bogen NoSQL Distilled, som han har skrevet sammen med kollegaen Pramod J. Sadalage.
Martin Fowler og Pramod J. Sadalage henviser til, at der stadig er mange opgaver, som relationelle databaser løser langt bedre end NoSQL-databaser. Dertil kommer, at NoSQL-databaseteknologierne stadig er meget umodne. Der er mange kanter, der mangler at blive slebet af, før de når samme gnidningsløse anvendelighedsniveau som relationelle databaser. Ligesom der stadig findes langt flere tools til relationelle databaser end til NoSQL-databaser. Med andre ord vil relationelle databaser fortsætte med at være den foretrukne databasetype til mange opgaver. Men foranlediget af fremkomsten af NoSQL-databaser er der blevet rusket op i default-tilgangen til databasesystemer.
For nogle år tilbage var udgangspunktet altid: Hvilken relationel database skal jeg bruge til denne specifikke opgave? Eller i en endnu værre variant: Denne relationelle database skal du bruge til denne specifikke opgave, for det er den, vi bruger her i firmaet! Disse grænser er ved at blive blødt op, argumenterer Fowler og Sadalage, så afsættet i dag i højere grad lyder: Hvad er den mest passende teknologi til min specifikke opgave? Det er først, når man kender svaret på det spørgsmål, at man er i stand til at vælge produkt uafhængigt af, om det tilhører gruppen af relationelle eller NoSQL-databaser. Denne nye tilgang omtaler forfatterne som “PolyglotPersistence”-tilgangen.
Flersprogede løsninger
‘Polyglot’ betyder flersproget – eller en person, der kan tale flere sprog. Og det er lige præcis, hvad fremtiden indenfor databasedesign byder på. Applikationer bør basere sig på flere forskellige sprog, siger Fowler og Sadalage, så man kan udnytte hver enkelt databasesystems evne til at løse en udfordring. Hvis der er noget, vi har lært af de sidste ti års ikke bare stigende datamængder, men også mere og mere komplekse datastrukturer, så er det, at der ikke findes en one-size-fits-all-løsning. Komplekse applikationer behøver tilsvarende komplekse løsninger på de indbyrdes forbundne problemstillinger. Det gælder ikke bare på tværs af applikationslaget i en virksomhed, men gør sig også gældende for hver enkelt applikation. En kompleks virksomheds-applikation benytter i dag allerede mange forskellige data og integrerer også data på tværs af kilder. Den virkelighed vil afspejle sig i et mere og mere polyglot design af fremtidens applikationer, siger Martin Fowler og Pramod J. Sadalage.
(se figur øverst)
Kompleksitet giver udfordringer
Kompleksitet er lig med nye muligheder. Men kompleksitet er også lig med nye udfordringer, advarer Fowler og Sadalage. For hver enkelt ny ukendt NoSQL-database, man introducerer i en virksomhed, kræves der adskillelige personressourcer og udviklingstimer til at lære teknologien ordentligt at kende. Mange af NoSQL-databaserne er også designet til at køre på store clusters, hvilket for nogle virksomheder betyder, at de pludselig skal forholde sig til spørgsmål om datakonsistens og tilgængelighed på en helt anden måde, end de er vant til.
Udfordringer er der med andre ord nok af, siger Martin Fowler og Pramod J. Sadalage, og kommer i samme vending med et godt råd til, hvilke typer af databaseprojekter der egner sig til en ‘PolyglotPersistence’-tilgang.
Hvis man skelner mellem strategiske databaseprojekter og rutineprægede databaseprojekter, så egner NoSQL-projekter sig bedst til strategiske databaseprojekter. Der er ingen grund til at bringe så mange ukendte faktorer i spil ved et rutineprojekt, som ikke har potentialet til at løfte forretningen. Til gengæld kan et strategisk databaseprojekt baseret på ‘PolyglotPersistence’-tilgangen være med til at øge produktiviteten blandt udviklerne markant og dermed øge time-to-market. En ‘PolyglotPersistence’-tilgang kan også vise sig gavnlig ved meget datatunge projekter, hvor der er meget datatrafik samt høje krav til tilgængelighed.
Tid præget af famleri
Hvad skal du tage med fra denne gennemgang af fremtidens polyvalente databasedesign? Du skal vide, at mange NoSQL-databaser stadig er relativt umodne teknologier sammenlignet med relationelle databaser, og at vi derfor befinder os i en fase, hvor mange famler sig frem. Du skal vide, at denne grundlæggende usikkerhed bør medregnes, hvis du selv overvejer, eller hvis du rådgiver andre til at benytte et miks af relationelle og NoSQL-databaser. Du skal også vide, at begrebet om ‘PolyglotPersistence’ ikke står uimodsagt i branchen. Man kan finde flere fagfolk, som opponerer mod Martin Fowler og Pramod J. Sadalages tankesæt, og som kalder ‘PolyglotPersistence’ for en kortsigtet tilgang til problemstillingen. Kritikerne mener, at det polyglote design efterlader softwareudviklerne med en større hovedpine, end da de begyndte. De så hellere, at man tacklede udfordringerne ved at bygge de nødvendige datamodeller baseret på én arkitektur i stedet for at integrere flere forskellige.
