Elasticsearch – fordele og ulemper

Elasticsearch har på det seneste fået meget opmærksomhed; en del store websites som fx. SoundCloud og Foursqare bruger det, og firmaet bag modtog i februar 2013 $24 mio. i ekstra funding og lige pt. nærmer produktet sig version 1.0.

Men handler Elasticsearch ikke kun om søgning?

Jeg er ikke sikker på at Elasticsearch er et velvalgt navn. Det er rigtigt at produktet er eminent til fritekstsøgning, men allerede implementerede features og udviklingsretningen giver en fuld funktionel dokumentorienteret database.

Hvorfor har Elasticsearch fået så stor succes på så relativt kort tid?

Jeg tror at en stor del af forklaringen skal findes i den erfaring og de filosofier hovedmanden bag, Shay Banon, har tilført produktet:

Bygget på et stærkt fundament
I stedet for at bygge persistering fra bunden, er Elasticsearch bygget oven på Lucene. Det er velafprøvet teknologi, og det kan mærkes på hele produktet.

ElasticSearch er…

Fritekst fantastic
Det er det Lucene er bygget til – at finde frem til dokumenter baseret på et eller flere nøgleord.

Distribueret fra starten
Starter man mere end en instans på samme netværk vil de automatisk finde hinanden, begynde at udveksle data og arbejdsopgaver.

Ren snitflade
Alt kommunikation med Elasticsearch, om det er tilføjelse af nye data eller komplekse forespørgsler, så foregår det via et simpelt REST-baseret API og sproget er ren JSON.

Schema dynamisk
Når Elasticsearch møder nye felter i et dokument bliver typen genkendt og schemaet udvidet. Det kan dog også være en ulempe, da værdier som udgangspunkt bliver analyseret med Lucene’s standard analyzer, og fx. ordet ‘binde-streg’ bliver til to nøgleord ‘binde’ og ‘streg’.

Men der er også ulemper …

Ikke “safe by default”
For at kunne tilbyde lynhurtige svar på forespørgsler, lægger Elasticsearch mange ting i ram og den antager at der er nok af det. Så frem den løber tør kan hele noden få problemer. Forbedringer på dette er i støbeskeen.

Split-brain situationer
En node i clustret bliver automatisk valgt til at være master. Det betyder, at den får en række vigtige opgaver omkring allokering m.v. for hele clusteret. Hvis masteren går ned eller har for travlt bliver der valgt en ny. Hvis der opstår segmentering af netværket kan man risikere split-brain, hvor der bliver valgt to masters, hvilket kan gå ud over hele clusterets stabilitet. For at undgå dette konfigurerer man et minimum af noder der skal være tilgængelige før at der bliver udført en master-afstemning.

Transaktioner
Transaktioner som vi kender dem fra relationelle databaser findes ikke i Elasticsearch, i stedet er der en række operationer der kan udføres atomart samt optimistisk låsning.

Joins
Elementært i relationelle databaser men joins er ikke noget Elasticsearch blev født med. Dog er der nogle funktioner der kan erstatte det såsom parent/child-dokumenter og social-graph-filtre. Men det er stadig lidt kringlet.

Elasticsearch er en stærk teknologi, der dog til tider stadig føles lidt umoden. Heldigvis er der så meget opmærksomhed og funding omkring den og dens økosystem at modenheden er godt på vej.

Denne liste er langt fra udtømmende, har du bud på flere fordele og ulemper?