streamalism.org

1. Oversikt

Solr er en av de mest populære Lucene-baserte søkeløsningene. Det er raskt, distribuert, robust, fleksibelt og har et aktivt utviklermiljø bak seg. SolrCloud er den nye, distribuerte versjonen av Solr.

En av hovedtrekkene her er det nærmeste sanntids-søket (NRT), dvs. at dokumenter er tilgjengelige for søk som snart slik de er indeksert.

2. Indeksering i SolrCloud

En samling i Solr består av flere skjær, og hver skjær har forskjellige kopier. En av kopiene til en skjær er valgt som leder for skjæringen når en samling opprettes:

• Når en klient prøver å indeksere et dokument, tildeles dokumentet først en skjær basert på hash av id av dokumentet
• Klienten får URL-en til lederen for den skjæringen fra dyrehagen, og til slutt blir indeksforespørselen gjort til den URL-en
• Skårlederen indekserer dokumentet lokalt før det sendes til replikaer
• Når lederen mottar en bekreftelse fra alle aktive og gjenopprettende replikaer, returnerer den bekreftelsen til indekseringsklientprogrammet

Når vi indekserer et dokument i Solr, går det ikke direkte til indeksen. Det står skrevet i det som kalles a tlog (transaksjonslogg). Solr bruker transaksjonsloggen for å sikre at dokumenter ikke går tapt før de blir begått, i tilfelle et systemkrasj.

Hvis systemet krasjer før dokumentene i transaksjonsloggen er begått, dvs. vedvarer til disk, blir transaksjonsloggen avspilt når systemet kommer opp igjen, noe som fører til null tap av dokumenter.

Hver indeks / oppdateringsforespørsel logges i transaksjonsloggen som fortsetter å vokse til vi utsteder en forpliktelse.

3. Forplikter i SolrCloud

EN begå operasjon betyr å fullføre en endring og vedvare den endringen på disken. SolrCloud tilbyr to typer forpliktelsesoperasjoner, nemlig. en forpliktelse og en myk forpliktelse.

3.1. Commit (Hard Commit)

En commit eller hard commit er en der Solr skyller alle uforpliktende dokumenter i en transaksjonslogg til disk. Den aktive transaksjonsloggen behandles, og deretter åpnes en ny transaksjonsloggfil.

Den oppdaterer også en komponent som kalles en søker, slik at de nylig forpliktede dokumentene blir tilgjengelige for søk. En søker kan betraktes som en skrivebeskyttet visning av alle forpliktede dokumenter i indeksen.

Forpliktelsen kan utelukkende gjøres av klienten ved å ringe begå API:

String zkHostString = "zkServer1: 2181, zkServer2: 2181, zkServer3: 2181 / solr"; SolrClient solr = ny CloudSolrClient.Builder () .withZkHost (zkHostString) .build (); SolrInputDocument doc1 = nytt SolrInputDocument (); doc1.addField ("id", "123abc"); doc1.addField ("dato", "14/10/2017"); doc1.addField ("book", "To kill a mockingbird"); doc1.addField ("forfatter", "Harper Lee"); solr.add (doc1); solr.commit ();

Tilsvarende kan den automatiseres som autoCommit ved å spesifisere det i solrconfig.xml fil, se avsnitt 3.4.

3.2. SoftCommit

Softcommit er lagt til fra Solr 4 og fremover, hovedsakelig for å støtte NRT-funksjonen til SolrCloud. Det er en mekanisme for å gjøre dokumenter søkbare i nærmest sanntid ved å hoppe over de kostbare aspektene ved harde forpliktelser.

I løpet av en softcommit blir ikke transaksjonsloggen avkortet, den fortsetter å vokse. Imidlertid åpnes en ny søker, som gjør dokumentene siden forrige softcommit synlig for søk. Også noen av toppnivåbufferne i Solr er ugyldige, så det er ikke en helt gratis operasjon.

Når vi spesifiserer maxTime for softcommit som 1000, betyr det at dokumentet vil være tilgjengelig i spørsmål senest 1 sekund fra det ble indeksert.

Denne funksjonen gir SolrCloud muligheten for nær sanntidssøk, ettersom nye dokumenter kan gjøres søkbare selv uten å forplikte dem. Softcommit kan bare utløses som autoSoftCommit ved å spesifisere det i solrconfig.xml fil, se avsnitt 3.4.

3.3. Autocommit og Autosoftcommit

De solrconfig.xml filen er en av de viktigste konfigurasjonsfilene i SolrCloud. Den genereres på tidspunktet for opprettelsen av samlingen. For å aktivere autoCommit eller autoSoftCommit, må vi oppdatere følgende seksjoner i filen:

 10000 30000 ekte 6000 1000 

maxTime: Antall millisekunder siden den tidligste uforpliktende oppdateringen, hvoretter neste commit / softcommit skulle skje.

maxDocs: Antall oppdateringer som har skjedd siden forrige forpliktelse, og etter som neste forpliktelse / softforpliktelse skal skje.

openSearcher: Denne egenskapen forteller Solr om den skal åpne en ny søker etter en forpliktelse eller ikke. Hvis det er ekte, etter en forpliktelse, lukkes den gamle søkeren, og en ny søker åpnes, noe som gjør det forpliktede dokumentet synlig for søk, Hvis det er falsk, vil dokumentet ikke være tilgjengelig for søk etter commit.

4. Nær sanntidssøk

Nær sanntidssøk oppnås i Solr ved hjelp av en kombinasjon av commit og softcommit. Som nevnt før, når et dokument legges til i Solr, vil det ikke være synlig i søkeresultatene før det er forpliktet til indeksen.

Normale forpliktelser er kostbare, og det er derfor myke forpliktelser er nyttige. Men ettersom softcommit ikke vedvarer dokumentene, trenger vi å angi autocommit maxTime intervall (eller maxDocs) til en rimelig verdi, avhengig av belastningen vi forventer.

4.1. Sanntid Gets

Det er en annen funksjon levert av Solr som faktisk er sanntid - få API. De få API kan gi oss et dokument som ikke engang er mykt forpliktet ennå.

Den søker direkte i transaksjonsloggene hvis dokumentet ikke finnes i indeksen. Så vi kan fyre a få API-anrop, umiddelbart etter at indeksanropet returnerer, og vi vil fortsatt kunne hente dokumentet.

Imidlertid, som alle altfor gode ting, er det en fangst her. Vi må passere id av dokumentet i få API-anrop. Selvfølgelig kan vi gi andre filterspørsmål sammen med id, men uten id, samtalen fungerer ikke:

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

5. Konklusjon

Solr gir oss litt fleksibilitet for å justere NRT-muligheten. For å få best mulig ytelse fra serveren, må vi eksperimentere med verdiene til forpliktelser og softcommits, basert på brukssaken og forventet belastning.

Vi bør ikke holde forpliktelsesintervallet vårt for lenge, ellers vil transaksjonsloggen vokse til en betydelig størrelse. Vi bør ikke utføre myke forpliktelser for ofte.

Det anbefales også å gjøre en ordentlig ytelsestesting av systemet vårt før vi går i produksjon. Vi bør sjekke om dokumentene blir søkbare innen ønsket tidsintervall.