streamalism.org

1. Áttekintés

A Solr az egyik legnépszerűbb Lucene-alapú keresési megoldás. Gyors, elosztott, robusztus, rugalmas és egy aktív fejlesztői közösség áll a háttérben. A SolrCloud a Solr új, terjesztett verziója.

Az egyik legfontosabb jellemzője a közel valós idejű (NRT) keresés, azaz a dokumentumok kereshetők hamar ahogy indexelik.

2. Indexelés a SolrCloud-ban

A Solr-gyűjtemény több szilánkból áll, és minden szilánk különféle másolatokkal rendelkezik. Egy szilánk egyik másolatát választják az adott szilánk vezetőjévé, amikor egy gyűjtemény létrejön:

• Amikor az ügyfél megpróbálja indexelni a dokumentumot, akkor a dokumentumhoz először egy szilánkot rendelnek a hash alapján id a dokumentum
• Az ügyfél megkapja a szilánk vezetőjének URL-jét a zookeeper-től, és végül az indexkérést erre az URL-re küldik
• A szilánkok vezetője a dokumentumot helyben indexeli, mielőtt másolatokba küldené
• Miután a vezető nyugtázást kapott az összes aktív és helyreállító replikától, visszaigazolja az indexelő ügyfélalkalmazást

Amikor egy dokumentumot indexelünk a Solr-ban, az nem közvetlenül megy az indexhez. Az úgynevezett a-ra van írva tlog (tranzakciónapló). A Solr a tranzakciónapló segítségével gondoskodik arról, hogy a dokumentumok elveszésük előtt ne történhessenek el, rendszerösszeomlás esetén.

Ha a rendszer összeomlik, mielőtt a tranzakciós naplóban szereplő dokumentumok elköteleződnének, azaz fennmaradnának a lemezen, a tranzakciónaplót a rendszer újbóli fellépésekor újra lejátszják, ami nulla dokumentumvesztést eredményez.

Minden index / frissítési kérelem naplózásra kerül a tranzakciós naplóba, amely tovább nő, amíg nem adunk ki egy kötelezettségvállalást.

3. Kötelez a SolrCloudban

A elkövetni A művelet azt jelenti, hogy véglegesíteni kell a változást, és a változást a lemezen fenn kell tartani. A SolrCloud kétféle végrehajtási műveletet biztosít, nevezetesen. elkötelezettség és halk elkötelezettség.

3.1. Vállalás (kemény elkötelezettség)

Elkötelezettség vagy kemény kötelezettségvállalás az, amelyben a Solr a tranzakciós napló összes el nem kötött dokumentumát lemezre mossa. Az aktív tranzakciónapló feldolgozásra kerül, majd egy új tranzakciónaplófájl nyílik meg.

Frissíti a kereső nevű összetevőt is, hogy az újonnan lekötött dokumentumok elérhetővé váljanak a kereséshez. A kereső az index összes lekötött dokumentumának csak olvasható nézetének tekinthető.

A végrehajtási műveletet kizárólag az ügyfél hajthatja végre a elkövetni API:

Karakterlánc zkHostString = "zkServer1: 2181, zkServer2: 2181, zkServer3: 2181 / solr"; SolrClient solr = új CloudSolrClient.Builder () .withZkHost (zkHostString) .build (); SolrInputDocument doc1 = új SolrInputDocument (); doc1.addField ("id", "123abc"); doc1.addField ("dátum", "2017.10.14."); doc1.addField ("könyv", "Gúnymadár megölése"); doc1.addField ("szerző", "Harper Lee"); solr.add (doc1); solr.commit ();

Ezzel egyenértékű módon automatizálható autoCommit megadásával a solrconfig.xml fájlt, lásd a 3.4 szakaszt.

3.2. SoftCommit

A Softcommit a Solr 4-től kezdődően került hozzá, elsősorban a SolrCloud NRT funkciójának támogatásához. Ez egy olyan mechanizmus, amellyel a dokumentumok csaknem valós időben kereshetővé válnak a kemény elkövetések költséges szempontjainak kihagyásával.

A softcommit során a tranzakciós napló nem csonka, tovább növekszik. Új kereső azonban megnyílik, amely láthatóvá teszi a dokumentumokat a legutóbbi szoftverkövetés óta a kereséshez. Továbbá a Solr legfelső szintű gyorsítótárai érvénytelenek, így nem teljesen ingyenes művelet.

Amikor megadjuk a maxTime 1000-es softcommit esetén ez azt jelenti, hogy a dokumentum az indexelésétől számított 1 másodpercen belül elérhető lesz lekérdezésekben.

Ez a szolgáltatás a SolrCloud számára biztosítja a szinte valós idejű keresés erejét, mivel az új dokumentumok keresés nélkül is elérhetővé tehetők. A Softcommit csak úgy indítható autoSoftCommit s-ben való megadásávalolrconfig.xml fájlt, lásd a 3.4 szakaszt.

3.3. Autocommit és Autosoftcommit

A solrconfig.xml fájl a SolrCloud egyik legfontosabb konfigurációs fájlja. A gyűjtemény létrehozásakor keletkezik. Engedélyezni autoCommit vagy autoSoftCommit, frissítenünk kell a fájl következő szakaszait:

 10000 30000 igaz 6000 1000 

maxTime: Az ezredmásodpercek száma a legkorábbi el nem hajtott frissítés óta, amely után a következő kötelezettségvállalásnak / softcommitnak meg kell történnie.

maxDocs: Az utolsó elkötelezettség óta bekövetkezett frissítések száma, amelyek után a következő kötelezettségvállalásnak / softcommitnak meg kell történnie.

openSearcher: Ez a tulajdonság megmondja a Solrnak, hogy új keresőt nyit-e meg egy végrehajtási művelet után vagy sem. Ha ez igaz, egy elkötelezettség után a régi kereső bezárul, és egy új kereső nyílik meg, ami láthatóvá teszi az elkötelezett dokumentumot a kereséshez, Ha ez hamis, a dokumentum nem lesz elérhető a lekérdezés után.

4. Közel a valós idejű kereséshez

A közel valós idejű keresés a Solr-ban érhető el az elkötelezettség és a softcommit kombinációjával. Mint korábban említettük, amikor egy dokumentum hozzáadódik a Solr-hoz, az csak akkor jelenik meg a keresési eredmények között, ha elkötelezi magát az index mellett.

A normál vállalások költségesek, ezért hasznosak a softcommitek. De mivel a softcommit nem őrzi meg a dokumentumokat, be kell állítanunk az automatikus bekapcsolást maxTime intervallum (vagy maxDocs) elfogadható értékre, a várt terheléstől függően.

4.1. Valós idejű Gets

Van egy másik, a Solr által nyújtott szolgáltatás, amely valójában valós idejű - a kap API. A kap Az API visszaadhat nekünk egy olyan dokumentumot, amely még nem is kötelező érvényű.

Közvetlenül a tranzakciós naplókban keres, ha a dokumentum nem található az indexben. Tehát lőhetünk a kap API-hívás, közvetlenül az indexhívás visszatérése után, és továbbra is képesek leszünk a dokumentum beolvasására.

Mint minden túl jó dolog, itt is van fogás. Át kell adnunk a id a dokumentumnak a kap API hívás. Természetesen a szűrővel együtt további szűrő lekérdezéseket is biztosíthatunk id, de anélkül id, a hívás nem működik:

// localhost: 8985 / solr / myCollection / get? id = 1234 & fq = név: baeldung

5. Következtetés

A Solr elég sok rugalmasságot biztosít számunkra az NRT képességek módosítása tekintetében. A kiszolgáló legjobb teljesítményének kiaknázása érdekében kísérleteznünk kell a vállalások és a softcommits értékeivel, felhasználási esetünk és várható terhelésünk alapján.

Nem szabad túl hosszú ideig tartanunk az elkötelezettség időtartamát, különben a tranzakciós naplónk jelentős méretre nő. Nem szabad azonban túl gyakran végrehajtani a softcomminket.

Azt is javasoljuk, hogy a gyártás megkezdése előtt végezze el rendszerünk megfelelő tesztelését. Ellenőriznünk kell, hogy a dokumentumok a kívánt időintervallumon belül kereshetővé válnak-e.