Hvad afgør dit valg af NoSQL-database?

Der er ikke noget kedeligere end at sidde til en konference og høre en sælger stå for at promovere sit produkt. Får man derimod 5 udviklere, der repræsenterer hvert sit produkt, til at deltage i en paneldebat kommer der derimod liv i tingene.

Et af tidens centrale spørgsmål er hvem arvtageren for den relationelle database er. De førende kandidater i øjeblikket er MongoDB, CouchDB, Neo4J, Riak og Casandra. På GOTO-konferencen havde man inviteret en repræsentat fra hvert projekt samt Martin Fowler, for at afgøre sagen.

Diskussionen var livlig og drejer sig mest om hvorvidt man vil opgive konsistens eller tilgængelighed af data (se CAP-teoremet). Meningerne er delte, men alle argumenterer for at netop deres designvalg er Det Rigtige(tm) og for enden af rækken sidder Martin Fowler, som fornuftens stemme, og stiller spørgsmål ved hvor mange systemer der overhovedet har brug for den perfekte løsning.

Med tiden vil markedet afgøre hvilket produkt der skal erstatte de relationelle databaser som standarden for data-storage. Alle kandidater er tilgængelige som open source, så de er tilgængelige og har alle et levende community. Der er kun en afgørende faktor: Det produkt der er lettest at installere vil i længden vinde.

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Ole Belhage

Hmm, jeg var nervøs allerede dengang man ville gå fra ISAM til RDB!
Det største problem er vel om programmøren forstår det...
Jeg ville aldrig overlade min bankkonto til et system som svarer: "der er ca. 100kr på kontoen - måske"
(selvom jeg næsten har indtryg af at bankerne allerede bruger det ;) )

Men til alle andre svartyper er det sikkert fint. Og endda overkill - flad fil med data vil nok performe lige så godt (casandra - hadoop)

  • 3
  • 2
Henning Makholm

Jeg ville aldrig overlade min bankkonto til et system som svarer: "der er ca. 100kr på kontoen - måske"

Nu er bankkonti jo lige netop et eksempel på et system som allerede kun leverer før-eller-senere-konsistens. Jeg tror ikke der er nogen danske banker som leverer en anfordringskonto det er teknisk umuligt at overtrække. De fysiske dankortfluesmækkere er vist afskaffet alle steder, men der er stadig systemer der (enten som standard eller som fallback ved kommunikationsproblemer) behandler transaktioner i gem-og-videresend batches. Når endelig transaktionen når frem til den konto pengene skal trækkes fra, bliver de trukket hvad end der er positiv saldo til det eller ej.

(Bankerne har også kun begrænset interesse i at udvikle et ægte realtidssystem som effektivt forhindrer klatovertræk -- så længe det kun er et fåtal af kunderne som går konkurs så hurtigt at de aldrig når at betale overtræksgebyret, kan det bedre betale sig for banken at lade folk fumle).

  • 5
  • 0
Jacob Christian Munch-Andersen

Umiddelbart ser jeg det ikke sådan at noget skal overtage relationelle databasers rolle, de gør egentlig deres job udenmærket, det er bare synd at de også bliver brugt i situationer hvor behovet er et helt andet.

SQL databaser excellerer når der er behov at kunne foretage arbitrære komplicerede søgninger, samt i situationer hvor det ikke er praktisk at tilpasse datastrukturen til de forventede forespørgsler.

Problemet er blot at rigtigt mange SQL databasers faktiske job er lidt mere kedeligt. Der er rigtigt mange af de helt simple forespørgsler, og størstedelen af de komplekse er funktionelt identiske med en kort serie af simple forespørgsler.

Der bør være plads til mere end en type database på markedet, simpelthen fordi opgaverne er så forskellige at et enkelt paradigme ikke kan excellere i det hele. I den udvikling vil det hjælpe gevaldigt at få drejet debatten fra hvilken database der er bedst, til at omhandle hvad de enkelte databaser faktisk er gode og dårlige til.

  • 9
  • 0
Peter Makholm Blogger

Jeg ville aldrig overlade min bankkonto til et system som svarer: "der er ca. 100kr på kontoen - måske"

Rick Falkvinge fra det svenske piratparti havde tidligere på daget givet en keynote hvor han blandt andet nævnte kryptopenge som en teknologi der helt ville ændre behovet for banker. BitCoin, som nok er det mest udbredte eksempel, gør netop sådan: "Du har modtaget 100 kr - måske, men der er 4 nabo-maskiner der tror på det".

Det er egentlig ikke noget problem at vores transaktionslog i kortere tidsrum ikke er helt konsistent. Sålænge vi over tid kan overbevises med en stor nok sikkerhed om en transaktion er gennemført eller afvist.

  • 1
  • 0
Peter Makholm Blogger

I den udvikling vil det hjælpe gevaldigt at få drejet debatten fra hvilken database der er bedst, til at omhandle hvad de enkelte databaser faktisk er gode og dårlige til.

Det kan vi som oplyste udviklere godt blive enige om. Det ville også være rart hvis vi bare tilføjede 5 nye værktøjer til vores værktøjskasse. Men nogle af forskellene er så små og meget komplicerede at gøre rede for at jeg tror at der vil ske en udtyning af markedet.

På samme måde med andre teknologivalg tror jeg der vil ske efter helt andre kriterier end hvad vi oplyste udviklere ville ønske der blev fokuseret på. For eksemple netop hvilken database der er lettest at installerer, administrerer eller at skrive sin første applikation i. Jeg kan da også se det for mig selv, hvis min chef spørger mig hvilket standardværktøj vi skal tilføje til vores system og jeg derfor undersøger 10 forskellige systemer, så er vinderen da helt klart det hvor jeg ikke skal kæmpe en halv dag med at lave et proof-of-concept eksempel.

  • 2
  • 0
Kim Bahir Andersen

Peter, jeg må tilstå at jeg ikke tror du kan stille det så simpelt op, at vinderen er den der er lettest at installere. Nuvel, det går ikke så godt for Oracle lige nu, men det er trods alt en database og en virksomhed der har haft succes, på trods af at den er alt andet end nem at installere...

Det er naturligvis vigtigt at kunne skabe et community, men at gøre det til et spørgsmål om at man "vinder pladsen som arvtager", fordi en hvilken som helst person der kan stave til IT på en god dag kan installere en database på 5 minutter, kompenserer ikke for performance, data sikkerhed, features osv osv.

  • 0
  • 0
Therese Hansen

Jeg snakkede med en arkitekt efter database-panelet, som havde den indsigt at det kommer an på hvem der tager beslutningen om hvilken database der skal bruges. Hvis det er udvikleren, så betyder en lav startbarriere såsom let install sikkert noget, men hvis det er en beslutning, der bliver taget længere oppe i hierakiet, så handler det om hvorvidt man kan få de rigtige folk (og nok af dem) og den rigtige support.

I sidste ende hænger det hele sammen.

  • 1
  • 0
Morten Hindsholm

Et andet problemscenarie er dette: En webshop har kun et stk af en bestemt vare tilbage. To brugere køber begge denne vare - på hver sin node. Før-eller-senere konsistens sikrer at begge noder til sidst når frem til samme tilstand: nemlig at beholdningen af den pågældende vare nu er -1 :-)

  • 0
  • 0
Jørgen Elgaard Larsen

Der er kun en afgørende faktor: Det produkt der er lettest at installere vil i længden vinde.

Jeg er ikke enig. De fleste kan efterhånden installeres med diverse pakkesystemer. Same same.

Efter at have arbejdet med NoSQL-databaser (især CouchDB) et stykke tid, ser jeg andre afgørende faktorer:

  • Modenhed. Der er stadig nogle få børnesygdomme hist og her i mange af produkterne, og der er stadig uslebne kanter i brugervenligheden. Det vil betyde en del, hvilke produkter, der først bliver helt modne.
  • Brugsscenarier. De forskellige produkter har forskellige fordele og ulemper, og det afhænger derfor af opgaven, hvilket produkt, der er det bedste. Så spørgsmålet er, hvad folk vil bruge NoSQL-databaser til fremover.
  • Integration. Det er oplagt, at de produkter, der har god integration til mange platforme og er nemme at bruge i f.x. PHP, vil have en fordel.
  • Dokumentation. De produkter, det er nemmest at forstå og lære og bruge, vil have en fordel.
  • Tilfældigheder. Også kaldet mode.
  • 2
  • 0
Jacob Christian Munch-Andersen

Det kan vi som oplyste udviklere godt blive enige om. Det ville også være rart hvis vi bare tilføjede 5 nye værktøjer til vores værktøjskasse. Men nogle af forskellene er så små og meget komplicerede at gøre rede for at jeg tror at der vil ske en udtyning af markedet.

Dit blogindlæg kunne godt forstås således at kun en vil overleve. Men givet ovenstående udsagn er vi sådan set nok enige, der bliver nogle få store, nogle nicheprodukter som de fleste udviklere aldrig når at overveje, men som alligevel får en stabil brugerskare, og så en del som bliver glemt.

@Kim Bahir Andersen og Jørgen Elgaard Larsen, jeg tror vi skal forstå begrebet "installation" bredt i Peters udsagn, lad os sige alt hvad der skal til for at man kan sende et par simple indsæt og læs kommandoer fra den platform man arbejder med. Det er nok deromkring de fleste af os vil tage beslutningen om at bruge produktet i et projekt, efterfølgende skal det skuffe ret slemt for at ryge ud af projektet igen.

  • 0
  • 0
Log ind eller Opret konto for at kommentere