Fra SQL til NoSQL – en saga

Det kode du skrev i går er legacy i dag, en floskel for softwareudviklere. Men det gælder ikke kun kode, det handler i høj grad også om de valg der foretages omkring infrastruktur; en verden der flytter sig mindst lige så hurtigt som udviklingstalent.

I 2010 startede vi et projekt der skulle indsamle, gemme og analysere data fra diverse sociale sites – vi var godt klar over at der var tale om store datamængder[1], men vi havde en fejlagtig optimisme og tiltro til de teknologier vi allerede kendte der skulle vise sig at være tidsmæssigt dyrt købt.

Gennem mit tidligere arbejde på bl.a. LEGO og DBA.DK er jeg blevet opflasket med Microsoft SQL Server, ikke fordi det altid var den rigtige løsning, men fordi det var til det, der allerede var opbygget infrastuktur, kompetencer og købt licenser til. Og da vi som startup havde mulighed for at blive medlem af Microsofts program for startups, BizSpark der bl.a. gav licens til at bruge SQL Server, var valget let; et så modent produkt som SQL server må da være perfekt til at gemme større datamængder i.

Det problematiske ved at arbejde med større indkomne datamængder over tid er at der går lang tid før at man ser problemerne. Det er først efter lang tid tingene går ned. I produktion. Juleaften. Omkring spisetid.

Vi voksede hurtigt ud af SQL Server; infrastrukturen var for lille, indexes kunne ikke følge med – ja data blev endda beskadiget.

I min tid ved Trifork havde jeg stiftet perifert bekendskab Apache CouchDB, så det blev hurtigt installeret, og vore produktionsdata blev overført. Det fungerede også ok i starten, det var på mange måder en lidt mere lavpraktisk database. Desværre havde den dengang en lidt uheldig måde at opdatere de interne indekses (materialisering af resultater fra map-reduce operationer); ikke som man skulle tro ved indsættelse af data, men først ved forespørgsel af data. Ud over dette, tog opdateringen ulidelig lang tid at afvikle – helt uacceptabelt for et website. Desuden gik CouchDB til tider ned og når den gjorde det præsenterede den da også en stacktrace, men da den er skrevet i Erlang kunne den med mine Erlang-kundskaber lige så godt blot have skrevet fejl 0x2A.

Efter denne katastrofe begyndte jeg at kigge efter en moden, ren .NET-løsning der var forberedt på realtime-forespørgsler; Lucene.

Lucene kan enten bruges til ren indeksering eller til både indeksering og persistering, valget faldt på sidstnævnte, for at kunne komme helt af med CouchDB. Og det fungerede faktisk godt, Lucene indekserer dokumenter når de bliver tilføjet, og selve indekseringen bliver ikke synderligt påvirket af nye felter, så man har mulighed for at konstruere nye søgninger hen af vejen. Der var dog stadig problemer, når indekset nåede en vis størrelse gik ydelsen ned når der blev både skrevet og læst. Første afhjælpning blev at lave et nyt indeks hver dag, dermed blev der kun skrevet til et ganske lille indeks men det blev et værre hyr at administrere de mange indekses og det krævede også mere og mere ram.

Nu da Lucene næsten virkede begyndte vi at kigge efter en måde at få størrelsen af indekset ned. Ideén gik på at, hvis man nu kun brugte Lucene til indeksering og ikke persistering, så kunne ydelsen måske forbedres og pladsforbruget mindskes. I princippet skulle data aldrig kunne ændre sig, så langsomt opstod en idé om blot at gemme data binært og komprimeret i fysiske filer og så blot notere positionen i Lucene; Vores hjemmelavede database, ConcreteDB var født.

Heldigvis nåede vi aldrig langt med ConcreteDB for via Twitter stødte vi på en ny lovende platform, Elasticsearch. Man har i princippet taget det bedste fra Lucene, tilføjet en smart måde at persistere, et REST-interface, distribuering og meget andet. Og så er problemet fra tidligere med de store indexes også blevet adresseret med bl.a. sharding og aliases.

Kunne man have sprunget nogle trin over? Jeg tror personligt at jeg var nød til gennemgå denne dannelsesrejse for præcist at forstå teknologiernes begrænsninger.

Hvad er din strategi for de stadig stigende datamængder?

I mine fremtidge indlæg vil jeg blandt andet kigge mere på kernen i Elasticsearch og de arkitekturvalg der ligger bag.

_{1.Så fornyligt en defination på hvad big data er; hvis dine data kan være på et SD kort er der ikke tale om big data. Smart defination, da begrebet dermed følger Moore’s lov.}