Kas tas ElasticSearch ir kodėl apie jį visi kalba
Jei dirbate su duomenimis ar kuriate bet kokią aplikaciją, kur reikia ieškoti informacijos, tikriausiai girdėjote apie ElasticSearch. Šis paieškos variklis pastaraisiais metais tapo vienu populiariausių sprendimų, kai kalbama apie greitą ir efektyvų duomenų paiešką. Bet ar tikrai jums jo reikia? Ar gal tai tiesiog dar vienas hype’inamas įrankis, kurį visi naudoja, nes taip daro kiti?
ElasticSearch yra atvirojo kodo paieškos ir analitikos variklis, pastatytas ant Apache Lucene bibliotekos. Jis skirtas dideliems duomenų kiekiams indeksuoti, ieškoti ir analizuoti beveik realiuoju laiku. Skamba įspūdingai, bet praktikoje tai reiškia, kad galite per sekundes persijodinėti milijonus įrašų ir gauti relevantiškus rezultatus greičiau nei spėtumėte sumirkčioti.
Tačiau čia slypi ir pavojus – daugelis įmonių ir kūrėjų įdiegia ElasticSearch tiesiog todėl, kad „taip reikia” arba „visi naudoja”. Rezultatas? Pernelyg sudėtinga infrastruktūra paprastoms užduotims, kurias puikiausiai atliktų ir tradicinė reliacinė duomenų bazė su tinkamais indeksais.
Kai jūsų PostgreSQL ar MySQL nebepakanka
Tradicinės SQL duomenų bazės puikiai tvarko paieškos užklausas, kai kalbame apie struktūruotus duomenis ir paprastas LIKE užklausas. Bet kas nutinka, kai jums reikia ieškoti tekste su klaidomis, sinonimais, skirtingomis žodžių formomis? Arba kai norite reitinguoti rezultatus pagal relevantišką?
Štai kur prasideda skausmas. Bandymas implementuoti sudėtingą full-text paiešką SQL duomenų bazėje tampa košmaru. Taip, PostgreSQL turi full-text search galimybes, ir jos neblogos, bet jos turi savo ribas. Kai jūsų duomenų kiekis auga iki milijonų įrašų, o paieškos užklausos tampa sudėtingesnės, tradicinės duomenų bazės pradeda lėtėti.
ElasticSearch čia spindi dėl kelių priežasčių. Pirma, jis naudoja invertuotus indeksus (inverted indexes), kurie specialiai optimizuoti teksto paieškai. Antra, jis palaiko distributed architektūrą – galite horizontaliai plėsti savo klasterį pridėdami daugiau mazgų. Trečia, jis turi įmontuotą relevantišką skaičiavimą, kuris naudoja TF-IDF ir kitus algoritmus rezultatams reitinguoti.
Praktiškai tai reiškia, kad jei kuriate e-komercijos platformą su tūkstančiais produktų, naujienų portalą su milijonais straipsnių, arba bet kokią aplikaciją, kur paieška yra kritinė funkcija – ElasticSearch turėtų būti jūsų radare.
Real-time analitika ir log’ų valdymas
Viena iš sričių, kur ElasticSearch tikrai blizga, yra log’ų agregavimas ir analizė. Jei kada nors bandėte surasti konkretų įvykį tarp milijonų log’ų eilučių, žinote, kokia tai kančia. Čia ir atsiranda garsusis ELK stack’as (ElasticSearch, Logstash, Kibana), kuris tapo de facto standartu log’ų valdymui.
Logstash surenka log’us iš įvairių šaltinių, juos apdoroja ir siunčia į ElasticSearch. ElasticSearch juos indeksuoja ir leidžia greitai ieškoti. Kibana suteikia vizualizacijos sąsają, kur galite kurti dashboard’us ir analizuoti duomenis. Viskas veikia beveik realiuoju laiku, o tai reiškia, kad galite stebėti savo sistemą ir reaguoti į problemas iškart.
Bet štai ką svarbu suprasti – jei jūsų aplikacija generuoja 100 log’ų eilučių per dieną, jums tikrai nereikia ElasticSearch. Tai būtų kaip naudoti tanką riešutui sulaužyti. Tačiau jei kalbame apie tūkstančius ar milijonus įrašų per minutę, jei reikia greitai filtruoti, agregoti ir analizuoti – tada ElasticSearch tampa ne prabanga, o būtinybe.
Realus pavyzdys: vienas mano klientas turėjo mikroservisų architektūrą su 50+ servisų. Kiekvieną kartą, kai kažkas sugesdavo, kūrėjai praleisdavo valandas bandydami suprasti, kas nutiko, naršydami po atskirus log’ų failus. Po ELK stack’o įdiegimo tas pats procesas užtrukdavo minutes. Galėjai pamatyti visą request’o kelią per visus servisus, filtruoti pagal session ID, error level’ą, laiko intervalą – viskas vienoje vietoje.
Sudėtingos paieškos scenarijai, kuriems reikia daugiau
ElasticSearch tikrai sušvinta, kai reikia implementuoti sudėtingas paieškos funkcijas, kurios tradicinėse duomenų bazėse būtų arba neįmanomos, arba labai lėtos. Kalbame apie tokius dalykus kaip fuzzy search (paieška su klaidomis), autocomplete, geo-spatial paieška, faceted search ir daugiau.
Fuzzy search leidžia rasti rezultatus net jei vartotojas padarė rašybos klaidą. Ieškote „elasticsarch”? Jokių problemų, sistema supranta, kad turėjote omeny „elasticsearch”. Tai veikia naudojant Levenshtein distance algoritmą, kuris skaičiuoja, kiek simbolių reikia pakeisti, kad vienas žodis taptų kitu.
Autocomplete funkcionalumas, kurį matote Google paieškoje ar Amazon produktų paieškoje, taip pat puikiai implementuojamas su ElasticSearch. Galite naudoti edge n-grams arba completion suggester’į, kad pasiūlytumėte vartotojui galimus variantus jau po pirmų įvestų simbolių.
Geo-spatial paieška leidžia ieškoti pagal geografinę lokaciją. Pavyzdžiui, rasti visas kavines 2 km spinduliu nuo jūsų esamos pozicijos. ElasticSearch palaiko įvairius geo užklausų tipus – geo_distance, geo_bounding_box, geo_polygon ir kitus.
Faceted search – tai filtravimo mechanizmas, kurį matote beveik kiekviename e-komercijos puslapyje. Kairėje pusėje filtrai pagal kategoriją, kainą, prekės ženklą, spalvą ir t.t., o šalia kiekvieno filtro matote, kiek rezultatų atitinka tą kriterijų. ElasticSearch aggregations funkcionalumas leidžia tai implementuoti efektyviai net su milijonais produktų.
Kada ElasticSearch yra overkill
Dabar apie tai, ko niekas nemėgsta kalbėti – kada ElasticSearch yra per daug. Nes tiesą sakant, daugeliui projektų jis tikrai yra per daug.
Jei jūsų duomenų bazėje yra kelios dešimtys tūkstančių įrašų ir paieška naudojama retai, jums tikriausiai pakaks paprastos SQL LIKE užklausos ar PostgreSQL full-text search. Taip, tai gali būti šiek tiek lėčiau, bet skirtumas bus nepastebiamas vartotojui, o jūs išvengsite papildomos infrastruktūros sudėtingumo.
ElasticSearch reikalauja resursų – tiek serverio, tiek žmogiškųjų. Jums reikės bent 2-4 GB RAM minimumui (production’e rekomenduojama 16-32 GB ar daugiau), reikės mokėti konfigūruoti klasterį, monitorinti jo sveikatą, daryti backup’us, atnaujinimus. Tai nėra „įdiegiau ir pamiršau” sprendimas.
Be to, ElasticSearch nėra transakcinis. Jis nėra ACID compliant kaip tradicinės duomenų bazės. Tai reiškia, kad jūs neturėtumėte jo naudoti kaip pirminį duomenų šaltinį. Įprasta architektūra yra turėti pagrindinę duomenų bazę (PostgreSQL, MySQL, MongoDB) ir sinchronizuoti duomenis į ElasticSearch indeksavimui ir paieškai.
Dar vienas dalykas – learning curve. ElasticSearch turi savo DSL (Domain Specific Language) užklausoms, kuris gali atrodyti gąsdinantis pradžioje. Paprastos užklausos yra nesudėtingos, bet kai tik pradedi naudoti aggregations, nested queries, scripting – reikia gerai suprasti, kaip viskas veikia.
Praktiniai patarimai prieš įdiegiant
Jei nusprendėte, kad ElasticSearch tikrai jums reikalingas, štai keletas patarimų, kurie padės išvengti įprastų klaidų.
Pradėkite nuo mažo. Nebandykite iškart migruoti visų savo duomenų į ElasticSearch. Pasirinkite vieną use case’ą – pavyzdžiui, produktų paiešką – ir pradėkite nuo to. Išmoksite, kaip viskas veikia, be didžiulės rizikos.
Planuokite savo indeksų struktūrą. Tai vienas svarbiausių dalykų. Kaip jūs struktūruosite savo duomenis, kokie bus field’ų tipai, ar naudosite nested objects ar parent-child relationships – visa tai turi būti apgalvota iš anksto. Pakeisti mapping’ą vėliau yra skausminga – dažniausiai reikia reindeksuoti visus duomenis.
Naudokite aliases. Vietoj to, kad tiesiogiai rašytumėte į indeksą „products”, sukurkite alias’ą. Tai leis jums lengvai perjungti į naują indeksą be downtime, kai reikės pakeisti mapping’ą ar atlikti major update’ą.
Monitorinkite resursų naudojimą. ElasticSearch gali suėsti daug RAM ir disk space. Naudokite Kibana Monitoring ar kitus įrankius, kad stebėtumėte klasterio sveikatą, JVM heap naudojimą, disk space ir kitus metrikų.
Optimizuokite shard’ų skaičių. Per daug shard’ų gali pakenkti performance’ui, per mažai – ribos skalabilumą. Bendras rule of thumb: vieno shard’o dydis turėtų būti 20-50 GB. Jei jūsų indeksas yra 100 GB, 2-5 shard’ai būtų optimalus pasirinkimas.
Įdiekite tinkamą backup strategiją. ElasticSearch palaiko snapshot’us, kurie leidžia daryti backup’us į shared file system, S3, Azure Blob Storage ar kitus repository tipus. Konfigūruokite automatinius snapshot’us nuo pat pradžių.
Alternatyvos, į kurias verta pažiūrėti
Nors ElasticSearch yra populiariausias, jis nėra vienintelis žaidėjas šioje erdvėje. Priklausomai nuo jūsų poreikių, kitos alternatyvos gali būti tinkamesnės.
Apache Solr yra kitas paieškos variklis, pastatytas ant Lucene. Jis senesnis už ElasticSearch ir kai kurie sako, kad stabilesnis. Solr turi galingesnę konfigūraciją per XML failus, bet kai kuriems tai atrodo sudėtingiau nei ElasticSearch REST API. Jei jums reikia labai specifinių paieškos funkcijų ar jūsų organizacija jau turi Solr patirties – verta apsvarstyti.
Algolia yra managed paieškos servisas, kuris puikiai tinka, jei nenorite patys valdyti infrastruktūros. Jis ypač populiarus front-end kūrėjų tarpe dėl puikių JavaScript bibliotekų ir lengvo integravimo. Minusas – kaina gali greitai išaugti su duomenų kiekiu ir užklausų skaičiumi.
Meilisearch yra naujesnis open-source paieškos variklis, parašytas Rust kalba. Jis orientuotas į paprastumą ir greitį. Jei jums reikia paprastos, bet greitos paieškos ir nenorite ElasticSearch sudėtingumo – verta pažiūrėti.
Typesense – dar viena alternatyva, kuri teigia esanti lengvesnė ir greitesnė už ElasticSearch. Taip pat parašyta su performance’u galvoje ir orientuota į developer experience.
PostgreSQL su full-text search ir trigram indeksais gali būti visiškai pakankamas sprendimas daugeliui projektų. Jei jau naudojate PostgreSQL ir jūsų paieškos poreikiai nėra labai sudėtingi – pradėkite nuo to, ką jau turite.
Realūs scenarijai, kur ElasticSearch išgelbėjo situaciją
Teorija yra gera, bet realūs pavyzdžiai parodo tikrąją vertę. Štai keletas situacijų, kur ElasticSearch padarė realų skirtumą.
Viena e-komercijos platforma turėjo 5 milijonus produktų ir jų paieška MySQL bazėje trukdavo 3-5 sekundes. Vartotojai pabėgdavo prieš pamatydami rezultatus. Po migracijos į ElasticSearch paieška pradėjo veikti per 50-100 milisekundžių. Bet svarbiausia – galėjo pridėti faceted search, autocomplete, typo tolerance – funkcijas, kurios buvo neįmanomos su MySQL.
Kitas pavyzdys – SaaS platforma, kuri teikia dokumentų valdymo sistemą. Klientai turėjo milijonus PDF, Word, Excel failų. Reikėjo ieškoti teksto viduje šių dokumentų. Bandymai daryti tai su tradicine duomenų baze buvo nevykę. ElasticSearch su ingest attachment plugin’u leido indeksuoti dokumentų turinį ir ieškoti per sekundes.
Dar vienas įdomus case – real-time monitoring sistema, kuri renka metrikas iš tūkstančių serverių. Reikėjo ne tik saugoti šiuos duomenis, bet ir greitai juos analizuoti, kurti alert’us, vizualizuoti. ElasticSearch su Kibana leido sukurti dashboard’us, kurie atnaujinami kas kelias sekundes, ir alert’us, kurie reaguoja į anomalijas beveik iškart.
Ką reikia žinoti apie kaštus ir maintenance
Kalbėkime apie pinigus ir laiką, nes tai svarbu. ElasticSearch yra nemokamas (jei naudojate open-source versiją), bet tai nereiškia, kad jis nieko nekainuoja.
Infrastruktūros kaštai gali būti reikšmingi. Production klasteriui rekomenduojama turėti bent 3 master nodes, kelis data nodes, galbūt koordinating nodes. Kiekvienas node’as turėtų turėti pakankamai RAM (16-32 GB minimumas production’e), greitą SSD storage, gerą network connectivity. Jei naudojate cloud (AWS, GCP, Azure), tai gali kainuoti nuo kelių šimtų iki kelių tūkstančių dolerių per mėnesį, priklausomai nuo masto.
Yra ir managed variantai – Elastic Cloud (oficialus), AWS Elasticsearch Service (dabar vadinamas OpenSearch Service), Elastic Cloud on Kubernetes. Jie supaprastina valdymą, bet kainuoja daugiau nei self-hosted sprendimas.
Žmogiškųjų resursų kaštai taip pat svarbūs. Jums reikės žmonių, kurie supranta ElasticSearch – kaip jį konfigūruoti, optimizuoti, troubleshoot’inti. Jei neturite tokių žmonių komandoje, reikės arba samdyti, arba mokytis. Mokymosi kreivė nėra labai stačia, bet reikia laiko.
Maintenance darbai apima: reguliarius update’us (security patches, version upgrades), backup’ų valdymą, performance tuning’ą, index lifecycle management, monitoring’ą. Tai nėra „set and forget” sistema.
Kaip suprasti, kad laikas migruoti į ElasticSearch
Yra keletas aiškių ženklų, kad jūsų dabartinis paieškos sprendimas nebepakanka ir laikas žiūrėti į ElasticSearch ar panašius įrankius.
Pirmas ženklas – lėta paieška. Jei jūsų paieškos užklausos trunka ilgiau nei sekundę ar dvi, vartotojai pradeda jaustis nepatogiai. Kai tai tampa 5-10 sekundžių, jie tiesiog išeina. Jei optimizavote savo duomenų bazės indeksus, query’us, bet vis tiek per lėta – laikas galvoti apie specializuotą paieškos sprendimą.
Antras ženklas – funkcionalumo trūkumas. Jei vartotojai prašo autocomplete, typo tolerance, faceted search, relevance ranking ir jūs negalite to efektyviai implementuoti su dabartine sistema – ElasticSearch tai gali.
Trečias ženklas – skalabilumo problemos. Jei jūsų duomenų kiekis auga ir matote, kad paieška darosi vis lėtesnė, o vertical scaling (didesnis serveris) tampa per brangus ar nebepadeda – horizontal scaling su ElasticSearch gali būti atsakymas.
Ketvirtas ženklas – analitikos poreikiai. Jei reikia ne tik ieškoti, bet ir analizuoti duomenis, kurti agregacijas, vizualizacijas – ElasticSearch su Kibana suteikia galingas galimybes.
Penktas ženklas – log’ų chaosas. Jei turite distributed sistemą su daugybe servisų ir log’ai yra išsibarstę po skirtingus serverius, failus, ir jūs praleidžiate valandas bandydami suprasti, kas nutiko – ELK stack’as gali dramatiškiai pagerinti situaciją.
Paskutiniai žodžiai apie paieškos variklio pasirinkimą
ElasticSearch yra galingas įrankis, bet kaip ir bet kuris įrankis, jis turi savo vietą ir laiką. Nėra universalaus atsakymo, ar jums jo reikia – viskas priklauso nuo jūsų specifinių poreikių, duomenų kiekio, komandos įgūdžių ir biudžeto.
Jei kuriate MVP ar mažą projektą, pradėkite nuo paprastesnių sprendimų. PostgreSQL full-text search ar net paprasta LIKE užklausa gali būti visiškai pakankama. Nepridėkite sudėtingumo, kol tikrai jo nereikia. Tai vadinama YAGNI principu – You Aren’t Gonna Need It – ir jis ypač aktualus infrastruktūros sprendimuose.
Tačiau jei matote aiškius ženklus, kad jūsų dabartinis sprendimas nebepakanka – jei paieška lėta, funkcionalumo trūksta, duomenų kiekis auga – tada ElasticSearch tikrai verta rimtai apsvarstyti. Tiesiog įsitikinkite, kad suprantate, į ką leidžiatės: ne tik galingą paieškos variklį, bet ir papildomą infrastruktūrą, kurią reikės valdyti.
Geriausias patarimas – pradėkite mažai, išmokite pagrindus, eksperimentuokite su development aplinkoje prieš eidami į production. Skaitykite dokumentaciją (ji tikrai gera), sekite best practices, ir nebijokite klausti community – ElasticSearch turi labai aktyvią bendruomenę, kuri mielai padeda.
Ir atminkite – technologijos yra tik įrankiai. Svarbiausia yra išspręsti realią problemą, o ne naudoti naujausią ir šauniausią technologiją vien dėl to, kad ji šauni. Kartais paprasčiausias sprendimas yra geriausias sprendimas.
