Forpligter sig og NRT-søgning i SolrCloud

1. Oversigt

Solr er en af ​​de mest populære Lucene-baserede søgeløsninger. Det er hurtigt, distribueret, robust, fleksibelt og har et aktivt udviklerfællesskab bag sig. SolrCloud er den nye distribuerede version af Solr.

En af dens nøglefunktioner her er den nærmeste realtids (NRT) søgning, dvs. at dokumenter er tilgængelige til søgning som snart som de er indekseret.

2. Indeksering i SolrCloud

En samling i Solr består af flere skår, og hver skår har forskellige replikaer. En af replikerne af en shard vælges som leder for den shard, når en samling oprettes:

  • Når en klient forsøger at indeksere et dokument, tildeles dokumentet først en shard baseret på hash af id af dokumentet
  • Klienten henter URL'en til lederen af ​​det skår fra zookeeper, og endelig foretages indeksanmodningen til den URL
  • Shard-lederen indekserer dokumentet lokalt, inden det sendes til replikaer
  • Når lederen modtager en bekræftelse fra alle aktive og gendannende replikaer, returnerer den bekræftelse til indekseringsklientapplikationen

Når vi indekserer et dokument i Solr, går det ikke direkte til indekset. Det er skrevet i det, der kaldes a tlog (transaktionslog). Solr bruger transaktionsloggen til at sikre, at dokumenter ikke går tabt, før de begås, i tilfælde af et systemnedbrud.

Hvis systemet går ned, før dokumenterne i transaktionsloggen er begået, dvs. fortsætter til disk, afspilles transaktionsloggen igen, når systemet kommer op igen, hvilket fører til nul tab af dokumenter.

Hver indeks / opdateringsanmodning logges i transaktionsloggen, som fortsætter med at vokse, indtil vi udsteder en forpligtelse.

3. Forpligter sig i SolrCloud

EN begå operation betyder at færdiggøre en ændring og fortsætte den ændring på disken. SolrCloud leverer to slags forpligtelsesoperationer, nemlig. en begå og en blød begå.

3.1. Commit (Hard Commit)

En commit eller hard commit er en, hvor Solr skyller alle ikke-forpligtede dokumenter i en transaktionslog til disk. Den aktive transaktionslog behandles, og derefter åbnes en ny transaktionslogfil.

Det opdaterer også en komponent kaldet en søger, så de nyligt forpligtede dokumenter bliver tilgængelige til søgning. En søger kan betragtes som en skrivebeskyttet visning af alle forpligtede dokumenter i indekset.

Forpligtelsesoperationen kan udelukkende udføres af klienten ved at ringe til begå API:

String zkHostString = "zkServer1: 2181, zkServer2: 2181, zkServer3: 2181 / solr"; SolrClient solr = ny CloudSolrClient.Builder () .withZkHost (zkHostString) .build (); SolrInputDocument doc1 = nyt SolrInputDocument (); doc1.addField ("id", "123abc"); doc1.addField ("dato", "14/10/2017"); doc1.addField ("bog", "At dræbe en mockingbird"); doc1.addField ("forfatter", "Harper Lee"); solr.add (doc1); solr.commit ();

Tilsvarende kan det automatiseres som autoCommit ved at specificere det i solrconfig.xml fil, se afsnit 3.4.

3.2. SoftCommit

Softcommit er blevet tilføjet fra Solr 4 og fremefter, primært for at understøtte NRT-funktionen i SolrCloud. Det er en mekanisme til at gøre dokumenter søgbare i næsten realtid ved at springe over de dyre aspekter af hårde forpligtelser.

Under en softcommit er transaktionsloggen ikke afkortet, den fortsætter med at vokse. En ny søger åbnes dog, hvilket gør dokumenterne siden sidste softcommit synlige til søgning. Nogle af de øverste cacher i Solr er også ugyldige, så det er ikke en helt gratis operation.

Når vi specificerer maxTime for softcommit som 1000 betyder det, at dokumentet vil være tilgængeligt i forespørgsler senest 1 sekund fra det tidspunkt, det blev indekseret.

Denne funktion giver SolrCloud muligheden for næsten realtids søgning, da nye dokumenter kan gøres søgbare, selv uden at forpligte dem. Softcommit kan kun udløses som autoSoftCommit ved at specificere det i solrconfig.xml fil, se afsnit 3.4.

3.3. Autocommit og Autosoftcommit

Det solrconfig.xml fil er en af ​​de vigtigste konfigurationsfiler i SolrCloud. Det genereres på tidspunktet for oprettelsen af ​​samlingen. At muliggøre autoCommit eller autoSoftCommit, skal vi opdatere følgende sektioner i filen:

 10000 30000 sand 6000 1000 

maxTime: Antallet af millisekunder siden den tidligste ikke-forpligtede opdatering, hvorefter den næste commit / softcommit skulle ske.

maxDocs: Antallet af opdateringer, der er sket siden den sidste forpligtelse, og hvorefter den næste forpligtelse / softcommit skal ske.

openSearcher: Denne egenskab fortæller Solr, om den skal åbne en ny søger efter en begivenhedshandling eller ej. Hvis det er rigtigt, efter en forpligtelse, lukkes den gamle søger, og en ny søger åbnes, hvilket gør det forpligtede dokument synligt til søgning, Hvis det er falsk, dokumentet er ikke tilgængeligt til søgning efter commit.

4. Nær realtidssøgning

Næsten realtidssøgning opnås i Solr ved hjælp af en kombination af commit og softcommit. Som nævnt før, når et dokument føjes til Solr, vil det ikke være synligt i søgeresultaterne, før det er forpligtet til indekset.

Normale forpligtelser er dyre, hvorfor softcommits er nyttige. Men da softcommit ikke vedvarer dokumenterne, er vi nødt til at indstille autocommit maxTime interval (eller maxDocs) til en rimelig værdi afhængigt af den belastning, vi forventer.

4.1. Realtid Gets

Der er en anden funktion leveret af Solr, som faktisk er realtid - API. Det API kan returnere os til et dokument, der ikke engang er begået blødt endnu.

Det søger direkte i transaktionslogfiler, hvis dokumentet ikke findes i indekset. Så vi kan fyre en API-opkald, umiddelbart efter indeksopkaldet vender tilbage, og vi kan stadig hente dokumentet.

Men som alt for gode ting er der en fangst her. Vi er nødt til at passere id af dokumentet i API-opkald. Selvfølgelig kan vi levere andre filterforespørgsler sammen med id, men uden id, opkaldet fungerer ikke:

// localhost: 8985 / solr / myCollection / get? id = 1234 & fq = name: baeldung

5. Konklusion

Solr giver os en smule fleksibilitet for os med hensyn til tilpasning af NRT-kapaciteten. For at få den bedste ydelse ud af serveren er vi nødt til at eksperimentere med værdierne for forpligtelser og softcommits baseret på vores brugstilfælde og forventede belastning.

Vi bør ikke holde vores forpligtelsesinterval for længe, ​​ellers vokser vores transaktionslog til en betydelig størrelse. Vi bør dog ikke udføre vores softcommits alt for ofte.

Det tilrådes også at udføre en ordentlig test af vores system, inden vi går i produktion. Vi bør kontrollere, om dokumenterne bliver søgbare inden for vores ønskede tidsinterval.