Kas yra Apache Solr ir kodėl tai svarbu
Jei kada nors kūrėte projektą, kuriame reikėjo įdiegti paiešką, tikriausiai supratote, kad paprastas SQL LIKE užklausas naudoti – tai kaip bandyti valgyti sriubą šakute. Veikia, bet labai neefektyviai. Čia ir ateina į pagalbą Apache Solr – galinga atvirojo kodo paieškos platforma, pastatyta ant Apache Lucene bibliotekos.
Solr nėra tik paprastas paieškos variklis. Tai pilnavertė platforma, kuri gali indeksuoti milijonus dokumentų, grąžinti rezultatus per milisekundes ir dar pridėti tokių funkcijų kaip faceted search, highlighting, spell checking ir daug kitų dalykų, kuriuos paprastai matote didžiuosiuose e-commerce projektuose.
Įsivaizduokite situaciją: turite internetinę parduotuvę su 100,000 produktų. Vartotojas įveda „raudona vasarinė suknelė”. Tradicinė SQL duomenų bazė čia pradėtų prakaituoti – reikėtų ieškoti keliuose laukuose, tvarkyti skirtingas žodžių formas, rankiniu būdu kurti relevance scoring. Solr daro visa tai iš dėžės, dar ir greičiau nei spėsite pasakyti „full-text search”.
Architektūra ir pagrindiniai komponentai
Solr veikia kaip standalone serveris, su kuriuo bendraujate per HTTP REST API. Tai reiškia, kad jūsų aplikacija gali būti parašyta Python, Java, JavaScript ar bet kuria kita kalba – jums tiesiog reikia siųsti HTTP užklausas.
Pagrindinis Solr komponentas yra core arba collection (jei naudojate SolrCloud režimą). Galite mąstyti apie core kaip apie atskirą paieškos indeksą su savo schema ir konfigūracija. Viename Solr serveryje galite turėti kelis core’us – pavyzdžiui, vieną produktams, kitą straipsniams, trečią vartotojų duomenims.
Schema apibrėžia, kokius laukus turite savo dokumentuose ir kaip jie turėtų būti indeksuojami. Čia galite nurodyti field types – ar tai tekstas, skaičius, data, geografinė lokacija. Kiekvienas tipas turi savo analizatorius, kurie nusprendžia, kaip duomenys bus apdorojami prieš indeksavimą ir paiešką.
Pavyzdžiui, tekstinio lauko analizatorius gali:
- Pašalinti HTML tagus
- Konvertuoti visas raides į mažąsias
- Pašalinti stop words (kaip „ir”, „arba”, „bet”)
- Atlikti stemming (pavyzdžiui, „bėgimas” → „bėg”)
- Sukurti n-grams autosuggestion funkcijai
Visa ši magija vyksta automatiškai, kai indeksuojate dokumentus ir kai vykdote paiešką.
SolrCloud ir mastelio didinimas
Kai jūsų duomenų kiekis pradeda augti iki milijonų įrašų, o paieškos užklausų skaičius viršija tūkstančius per sekundę, paprastas standalone Solr serveris nebepakanka. Čia į sceną įžengia SolrCloud.
SolrCloud – tai Solr režimas, leidžiantis kurti paskirstytas sistemas su automatine duomenų replikacija, load balancing ir fault tolerance. Jis naudoja Apache ZooKeeper koordinavimui tarp mazgų.
Pagrindinės SolrCloud sąvokos:
- Shard – tai jūsų duomenų dalis. Jei turite 10 milijonų dokumentų, galite juos padalinti į 10 shardų po 1 milijoną
- Replica – kiekvieno shard kopija. Jei vienas serveris nukrenta, kitas replica gali perimti darbą
- Leader – viena replica kiekviename shard, kuri koordinuoja indeksavimo operacijas
Praktiškai tai atrodo taip: sukuriate collection su 4 shardais ir 2 replikomis kiekvienam. Tai reiškia, kad turite 8 Solr core’us paskirstytus keliuose serveriuose. Kai indeksuojate dokumentą, Solr automatiškai nusprendžia, į kurį shard jis turėtų patekti (paprastai naudojant hash funkciją). Kai ieškote, užklausa siunčiama į visus shardus lygiagrečiai, rezultatai sujungiami ir grąžinami.
Pats diegiau SolrCloud klasterį projektui, kuris turėjo apdoroti apie 50 milijonų dokumentų. Pradžioje bandėme su vienu serveriu – paieška užtrukdavo 5-10 sekundžių. Po migracijos į 6 mazgų klasterį su 12 shardų, tas pats query’is pradėjo grąžinti rezultatus per 200-300 milisekundžių. Skirtumas kaip diena ir naktis.
Indeksavimas ir duomenų importavimas
Yra keletas būdų, kaip galite gauti duomenis į Solr. Paprasčiausias – siųsti JSON ar XML dokumentus per HTTP POST užklausą. Tai puikiai veikia, kai turite nedidelį duomenų kiekį arba realtime updates.
Tačiau kai reikia importuoti milijonus įrašų iš SQL duomenų bazės, CSV failų ar kitų šaltinių, naudojate Data Import Handler (DIH). Sukonfiguruojate XML failą, kuris aprašo, iš kur imti duomenis, kaip juos transformuoti ir į kokius Solr laukus mapinti.
Štai paprastas pavyzdys DIH konfigūracijos:
„`xml
„`
Vienas svarbus dalykas apie indeksavimą – commit operacija. Kai siunčiate dokumentus į Solr, jie iš pradžių pateka į atmintį ir nėra iš karto prieinami paieškai. Tik po commit operacijos jie tampa matomi. Galite konfigūruoti auto-commit intervalus arba iškviesti commit rankiniu būdu.
Didelių duomenų kiekių indeksavimui rekomenduoju:
- Siųsti dokumentus batch’ais po 1000-5000 vnt.
- Išjungti auto-commit indeksavimo metu
- Padidinti RAM buffer size
- Atlikti commit tik pabaigoje
- Po viso proceso paleisti optimize komandą (bet atsargiai – ji resursų imlus)
Query sintaksė ir paieškos galimybės
Solr palaiko kelias query sintakses, bet populiariausia yra Lucene query syntax. Ji gana intuityvi ir galinga.
Paprasčiausi pavyzdžiai:
laptop– ieško žodžio „laptop” visuose laukuosename:laptop– ieško tik name laukename:"gaming laptop"– ieško tikslios frazėsprice:[100 TO 500]– range paieškalaptop AND (dell OR hp)– boolean operatoriailapt*– wildcard paieška
Bet tikroji galia slypi sudėtingesnėse funkcijose. Faceting leidžia gauti agregacijas – pavyzdžiui, kiek produktų yra kiekvienos kategorijos, koks vidutinis kiekvieno gamintojo produktų kiekis ir pan. Tai tas funkcionalumas, kurį matote kairiajame e-commerce puslapių šone su checkbox’ais ir skaičiais šalia.
Highlighting grąžina fragmentus iš dokumento su paryškintu ieškotu tekstu. Labai naudinga, kai norite parodyti vartotojui kontekstą, kodėl konkretus rezultatas buvo rastas.
Spell checking ir suggestions padeda vartotojams, kai jie padarė rašybos klaidą arba nežino tikslaus termino. „Ar turėjote omenyje: laptop?” – matėte tokius pranešimus šimtus kartų.
Vienas mano mėgstamiausių feature’ų yra More Like This. Perduodate dokumento ID ir Solr grąžina panašius dokumentus. Puikiai tinka „Jums taip pat gali patikti” sekcijoms.
Praktinis patarimas: nenaudokite wildcard paieškos pradžioje žodžio (*aptop), jei galite išvengti. Tai labai lėta operacija, nes Solr negali naudoti indekso efektyviai. Vietoj to, konfigūruokite ngram tokenizer’į schemoje.
Performance tuning ir optimizacija
Solr out-of-the-box yra gana greitas, bet tikrai galite jį dar labiau pagreitinti su tinkamomis konfigūracijomis.
Pirmiausia – RAM. Solr yra Java aplikacija ir labai mėgsta atmintį. Bet čia yra gudrybė: neduokite visos RAM JVM heap’ui. Palikite bent pusę sistemos RAM operacinei sistemai, nes Lucene labai priklauso nuo OS file system cache. Pavyzdžiui, jei turite 32GB serverį, duokite 12-16GB JVM heap’ui, likusią dalį paliekant OS.
Antra – cache konfigūracija. Solr turi kelis cache tipus:
- filterCache – talpina filter queries rezultatus
- queryResultCache – talpina pilnus query rezultatus
- documentCache – talpina užkrautus dokumentus
- fieldValueCache – naudojamas sorting ir faceting
Reikia rasti balansą – per maži cache’ai reiškia daugiau disk I/O, per dideli – less RAM kitoms operacijoms ir ilgesnis warming laikas po commit.
Trečia – schema dizainas. Nenaudokite stored=”true” laukams, kurių jums nereikia grąžinti paieškos rezultatuose. Nenaudokite indexed=”true” laukams, kuriuose niekada neieškote. Kiekvienas papildomas indeksuotas laukas didina indekso dydį ir lėtina indeksavimą.
Jei turite tekstinius laukus, kuriuose reikia ieškoti, bet nereikia faceting ar sorting, naudokite TextField su atitinkamais analyzers. Jei reikia tik exact match paieškos, naudokite StrField – jis daug greitesnis.
Ketvirta – sharding strategija. Jei naudojate SolrCloud, pagalvokite, kaip padalinti duomenis. Kartais logiškesnis sharding (pavyzdžiui, pagal kategoriją ar regioną) gali būti efektyvesnis nei random hash-based sharding, ypač jei jūsų queries dažnai filtruoja pagal tuos pačius kriterijus.
Penkta – warming queries. Galite sukonfigūruoti queries, kurie bus automatiškai paleisti po kiekvieno commit, kad užpildytų cache’us. Tai reiškia, kad pirmieji realūs vartotojų queries nepatirs „šalto starto” lėtumo.
Monitoring ir troubleshooting
Solr turi puikų admin UI, prieinamą per naršyklę. Ten rasite viską – nuo core statistikos iki query analizės įrankių. Bet production aplinkoje jums reikės daugiau.
Rekomenduoju integruoti Solr su monitoring sistemomis kaip Prometheus + Grafana arba ELK stack. Solr eksportuoja daug metrikų per JMX, kurias galite surinkti ir vizualizuoti.
Svarbiausi metrikas stebėti:
- Query response time (95th ir 99th percentiles, ne tik average)
- QPS (queries per second)
- Cache hit ratios
- JVM heap usage ir garbage collection pauzės
- Index size ir dokumentų skaičius
- Commit ir optimize trukmė
Kai kažkas eina ne taip, pirmiausia žiūrėkite į Solr logus. Jie paprastai gana informatyvūs. Dažniausios problemos:
Lėtos queries – naudokite debug=true parametrą query’yje, kad pamatytumėte, kaip Solr apdoroja jūsų užklausą. Galbūt kažkuris filter nepanaudoja cache, arba jūsų query turi wildcard pradžioje.
Out of Memory errors – arba per mažas heap, arba per dideli cache’ai, arba memory leak. Paimkite heap dump ir analizuokite su VisualVM ar Eclipse MAT.
Slow indexing – patikrinkite, ar neturite per dažnų commit’ų, ar jūsų schema neturi per daug copy fields ar complex analyzers.
Split brain SolrCloud – kai ZooKeeper praranda ryšį su dalimi mazgų. Čia svarbu turėti stabilų tinklą ir tinkamą ZooKeeper ensemble (visada nelyginį skaičių mazgų – 3, 5 ar 7).
Vienas patarimas iš patirties: visada turėkite staging aplinką, kuri kuo labiau atitinka production. Testinkite schema pakeitimus, naujus queries, performance tuning ten prieš rollout’inant į production. Solr yra stabilus, bet kai dirbi su milijonais dokumentų, net maži pakeitimai gali turėti netikėtų pasekmių.
Kai Solr tampa jūsų geriausiu draugu
Apache Solr nėra paprastas įrankis, kurį įdiegiate ir pamirštate. Tai platforma, kurią reikia suprasti, sukonfigūruoti ir nuolat optimizuoti. Bet kai tai padarote gerai, rezultatai būna įspūdingi.
Mačiau projektus, kurie migravo nuo SQL LIKE queries prie Solr ir sumažino paieškos laiką nuo 10 sekundžių iki 50 milisekundžių. Mačiau e-commerce platformas, kurios padidino konversijas 15-20% tiesiog pridėdamos faceted navigation ir spell checking. Mačiau content platformas, kurios tapo naudojamos dėl to, kad vartotojai galėjo greitai rasti tai, ko ieško.
Taip, yra ir alternatyvų – Elasticsearch yra didžiausias konkurentas, ir jis tikrai turi savo privalumų. Bet Solr turi brandžią ekosistemą, puikią dokumentaciją ir labai aktyvią community. Jei jums reikia enterprise-level paieškos sprendimo, kuris veikia ir yra patikrintas milijonuose projektų – Solr yra saugus pasirinkimas.
Pradėti galite su vienu standalone serveriu ir paprastu schema. Kai projektas auga, galite pereiti prie SolrCloud, pridėti daugiau shardų, optimizuoti queries. Solr auga kartu su jumis.
Ir dar vienas dalykas – nebijokite eksperimentuoti. Sukurkite dev aplinką, žaiskite su skirtingais analyzers, testuokite įvairias query sintakses, bandykite skirtingas caching strategijas. Solr dokumentacija yra puiki, bet tikrasis mokymasis ateina per praktiką. Ir kai pagaliau pamatysite tą query, kuris grąžina tiksliai tai, ko reikia, per 20 milisekundžių iš 50 milijonų dokumentų – suprasite, kodėl Solr vis dar yra vienas populiariausių paieškos sprendimų pasaulyje.
