streamalism.org

1. Overzicht

Solr is een van de meest populaire op Lucene gebaseerde zoekoplossingen. Het is snel, gedistribueerd, robuust, flexibel en er zit een actieve ontwikkelaarsgemeenschap achter. SolrCloud is de nieuwe, gedistribueerde versie van Solr.

Een van de belangrijkste kenmerken hiervan is het zoeken in bijna realtime (NRT), d.w.z. documenten die kunnen worden doorzocht als spoedig zoals ze worden geïndexeerd.

2. Indexeren in SolrCloud

Een verzameling in Solr bestaat uit meerdere shards en elke shard heeft verschillende replica's. Een van de replica's van een shard wordt geselecteerd als de leider voor die shard wanneer een verzameling wordt gemaakt:

• Wanneer een client een document probeert te indexeren, krijgt het document eerst een shard toegewezen op basis van de hash van het ID kaart van het document
• De client krijgt de URL van de leider van die scherf van de dierenverzorger, en ten slotte wordt het indexverzoek naar die URL gestuurd
• De Shard-leider indexeert het document lokaal voordat het naar replica's wordt verzonden
• Zodra de leider een bevestiging heeft ontvangen van alle actieve en herstellende replica's, stuurt deze een bevestiging terug naar de indexerende clienttoepassing

Wanneer we een document in Solr indexeren, gaat het niet rechtstreeks naar de index. Het is geschreven in wat een tlog (transactielogboek). Solr gebruikt het transactielogboek om ervoor te zorgen dat documenten niet verloren gaan voordat ze worden vastgelegd, in geval van een systeemcrash.

Als het systeem crasht voordat de documenten in het transactielogboek zijn vastgelegd, d.w.z. op schijf blijven staan, wordt het transactielogboek opnieuw afgespeeld wanneer het systeem weer opstart, waardoor er geen documenten verloren gaan.

Elk index- / updateverzoek wordt geregistreerd in het transactielogboek dat blijft groeien totdat we een vastlegging uitvoeren.

3. Commits in SolrCloud

EEN plegen operatie betekent het afronden van een wijziging en het voortzetten van die wijziging op schijf. SolrCloud biedt twee soorten vastleggingsbewerkingen, namelijk. een commit en een zachte commit.

3.1. Commit (harde toezegging)

Een commit of harde commit is er een waarbij Solr alle niet-gecommitteerde documenten in een transactielogboek naar schijf wist. Het actieve transactielogboek wordt verwerkt en vervolgens wordt een nieuw transactielogboekbestand geopend.

Het vernieuwt ook een component die een zoeker wordt genoemd, zodat de nieuw vastgelegde documenten beschikbaar komen voor doorzoeken. Een zoeker kan worden beschouwd als een alleen-lezenweergave van alle vastgelegde documenten in de index.

De vastlegbewerking kan uitsluitend door de client worden uitgevoerd door het plegen API:

String zkHostString = "zkServer1: 2181, zkServer2: 2181, zkServer3: 2181 / solr"; SolrClient solr = nieuwe CloudSolrClient.Builder () .withZkHost (zkHostString) .build (); SolrInputDocument doc1 = nieuwe SolrInputDocument (); doc1.addField ("id", "123abc"); doc1.addField ("date", "14/10/2017"); doc1.addField ("boek", "Om een ​​spotvogel te doden"); doc1.addField ("auteur", "Harper Lee"); solr.add (doc1); solr.commit ();

Evenzo kan het worden geautomatiseerd als autoCommit door het op te geven in het solrconfig.xml -bestand, zie paragraaf 3.4.

3.2. SoftCommit

Softcommit is toegevoegd vanaf Solr 4, voornamelijk om de NRT-functie van SolrCloud te ondersteunen. Het is een mechanisme om documenten bijna in realtime doorzoekbaar te maken door de kostbare aspecten van harde commits over te slaan.

Tijdens een softcommit wordt het transactielogboek niet afgekapt, het blijft groeien. Er wordt echter een nieuwe zoeker geopend, waardoor de documenten sinds de laatste softcommit zichtbaar zijn voor zoeken. Ook zijn sommige van de caches op het hoogste niveau in Solr ongeldig, dus het is niet helemaal gratis.

Wanneer we het maxTime voor softcommit als 1000, betekent dit dat het document niet later dan 1 seconde vanaf het moment dat het werd geïndexeerd beschikbaar zal zijn in queries.

Deze functie geeft SolrCloud de kracht van bijna realtime zoeken, omdat nieuwe documenten doorzoekbaar kunnen worden gemaakt, zelfs zonder ze vast te leggen. Softcommit kan alleen worden geactiveerd als autoSoftCommit door het op te geven in solrconfig.xml -bestand, zie paragraaf 3.4.

3.3. Autocommit en Autosoftcommit

De solrconfig.xml bestand is een van de belangrijkste configuratiebestanden in SolrCloud. Het wordt gegenereerd op het moment dat de collectie wordt gemaakt. In staat te stellen autoCommit of autoSoftCommit, we moeten de volgende secties in het bestand bijwerken:

 10000 30000 waar 6000 1000 

maxTime: Het aantal milliseconden sinds de eerste niet-gecommitteerde update waarna de volgende commit / softcommit zou moeten plaatsvinden.

maxDocs: Het aantal updates dat heeft plaatsgevonden sinds de laatste commit en waarna de volgende commit / softcommit zou moeten plaatsvinden.

openSearcher: Deze eigenschap vertelt Solr of er een nieuwe zoeker moet worden geopend na een vastlegbewerking of niet. Als het is waar, na een vastlegging, wordt de oude zoeker gesloten en wordt een nieuwe zoeker geopend, waardoor het vastgelegde document zichtbaar wordt voor zoeken, Als het is false, is het document niet beschikbaar om te zoeken na het vastleggen.

4. Bijna realtime zoeken

Near Real-Time Searching wordt bereikt in Solr met een combinatie van commit en softcommit. Zoals eerder vermeld, wordt een document dat aan Solr wordt toegevoegd, pas zichtbaar in zoekresultaten als het is vastgelegd in de index.

Normale commits zijn duur, daarom zijn softcommits handig. Maar omdat softcommit de documenten niet vasthoudt, moeten we wel de autocommit instellen maxTime interval (of maxDocs) tot een redelijke waarde, afhankelijk van de belasting die we verwachten.

4.1. Realtime Gets

Er is nog een andere functie van Solr die in feite realtime is: de krijgen API. De krijgen API kan ons een document terugsturen dat nog niet eens soft-commited is.

Het zoekt rechtstreeks in de transactielogboeken als het document niet in de index wordt gevonden. Zodat we een krijgen API-oproep, onmiddellijk nadat de indexoproep is teruggekeerd en we het document nog steeds kunnen ophalen.

Maar zoals bij al te goede dingen, zit hier een addertje onder het gras. We moeten de ID kaart van het document in het krijgen API-oproep. Natuurlijk kunnen we naast de ID kaart, maar zonder ID kaart, de oproep werkt niet:

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

5. Conclusie

Solr biedt ons nogal wat flexibiliteit met betrekking tot het aanpassen van de NRT-mogelijkheid. Om de beste prestaties uit de server te halen, moeten we experimenteren met de waarden van commits en softcommits, gebaseerd op onze use case en verwachte belasting.

We moeten ons commit-interval niet te lang houden, anders groeit ons transactielogboek aanzienlijk. We moeten onze softcommits echter niet te vaak uitvoeren.

Het wordt ook aangeraden om een ​​goede prestatietest van ons systeem uit te voeren voordat we naar productie gaan. We moeten controleren of de documenten doorzoekbaar worden binnen ons gewenste tijdsinterval.