&w=3840&q=75)
REST API out of the box
Om man tittar på hur data lagras i ElasticSearch så ser man att det mesta är uppsatt på ett sätt som underlättar förfrågningar genom ett REST API. Därmed behöver man inte lägga tid på att skriva vyer som är anpassade efter REST. Det enda du behöver göra är att ladda in data i det format/struktur som det är tänkt att frontend skall konsumera informationen så sköter ElasticSearch resten.
Filtrera och sortera i listvyer
De flesta appar innehåller listvyer av något slag. Den vanligaste anledningen till att man använder ElasticSearch är att man har för långa listor och då behöver man förenkla flödet för användarna genom att introducera fritextsök. Eftersom de flesta appar börjar med att enbart ha databasen som enda datakälla så ser man tidigt i de flesta projekt att fritextsöket tynger ner databasen och därmed så blir hela sajten väldigt tungrodd. Här passar ElasticSearch som handen i handsken, du kan både avlasta databasen generellt men även sköta filtrering och sortering direkt via ElasticSearch.
Fasetterade menyer
Har ni funktionalitet på er plattform som kräver både sök, sortering och filtrering? I ElasticSearch kan man göra allt detta genom ett enda anrop och dessutom få till snabba svarstider.
Fasetterade menyer används av de flesta plattformar som kräver att man kan filtrera på flera nivåer och få en överskådlighet kring vissa filters och antal resultat per valt filter. Denna typ av funktionalitet är vanligt hos sidor/appar som sysslar med e-handel.
Aggregerad data
Med ElasticSearch kan man derivera och sammanställa aggregerad data rätt snabbt och enkelt. Har ni data och aggregerade vyer som tynger databasen och ofta blir en flaskhals så ska ni definitivt undersöka möjligheten att använda ElasticSearch som ett lager för aggregerad data. Speciellt om aggregationerna kräver olika typer av skärningar beroende på de val som användaren gör.
Cache lager
ElasticSearch lämpar sig väldigt bra för sådan data som sällan ändras. Det vill säga data som är lästungt. Data läses väldigt ofta och uppdateras väldigt sällan. Det hör till sakens natur och därmed bör man överväga hur man servar data på ett enkelt och snabbt sätt utan att behöva skriva skräddarsydd kod för detta. Eftersom ElasticSearch kommer med ett JSON baserat REST API så tycker vi att det lämpar sig väldigt väl för att agera cache lager. Här kan du även ha ett lager som sitter på denormaliserad data så att du harmoniserar datat i ElasticSearch så att tunga databasen slipper göra tunga JOINs vid varje anrop.
Varför bör man använda ElasticSearch istället för något som t ex Redis för att cachea data?
På Will & Skill använder vi Redis i de flesta projekt och vi tycker att Redis är en fantastisk teknologi men ElasticSearch lämpar sig väldigt väl för sådan data som behöver filtreras, sorteras och eventuellt kombineras med aggregerad data. Ett konkret exempel är att ElasticSearch kan hantera en listvy medan Redis får hantera en detaljvy i ett REST API.
Horisontell skalbarhet
Det är väldigt enkelt att skapa kluster i ElasticSearch och det medför att man kan öka kapacitet efter behov genom att addera noder i ett kluster horisontellt. Ser man till exempel att nuvarande kluster inte kan hantera den last som man får inför t ex Black Friday eller Julruschen kan man snabbt addera fler noder som får dela på lasten.
Ta det till nästa steg!
Vi på Will & Skill har gedigen erfarenhet kring ElasticSearch och pratar gärna mer med dig och dina kollegor kring hur ni kan nyttja dess potential till fullo i er organisation. Tveka inte att höra av er till oss på Will & Skill för att diskutera hur ni tillämpar ovanstående funktionalitet i era projekt.