Solr

[bodnarIQ]

Analyza moznych reseni aktualniho stavu

1. Spolocny solr index - spolecna data

   • problem s udrzitelnostou
   • problem pri reindexe
   • zasah do indexu krameria (nepřístupná varianta za inQool a Inovatiku)

2. Oddelene indexy - oddelene data

   1. Kramerius+ vlastny solr core

      • pre vyhladavanie sa vyuzije Solr JoinQuery parser
      • pri vyhladavani v specifickem shardu (vybranem)
        • dokumenty vo vysledku nie su spajane z jednotlivych shardov, takze vyhladavanie hlavneho obsahu v jednom core a obohatenych metadat v druhom core nefunguje
        • zvoleny dotaz sa vykona v oboch core - nie cast dotazu v jednom a cast dotazu v druhom core
      • pre joinQuery musi byt replica shardu krameria+ na kazdom node solru krameria
        • moznost iba filtrovat na zaklade vysledkov, v odpovedi sa nezobrazia vysledky z oboch shardov
        • tym, ze sa z prveho dotazu vrati iba mnozina ID pouzitych pre filtrovanie v druhom dotazu, nebude mozne facetovanie, vypocet relevancie a sorting na fieldoch z povodneho krameria
      • joinQuery vysveletene nizsie

   2. Kramerius+ vlastna solr kolekcia (pri vyuziti SolrCloud)

      • pre vyhladavanie sa vyuzije Solr JoinQuery parser
      • moznost iba filtrovat, v odpovedi sa nezobrazia vysledky z oboch kolekcii
      • Performance Join operace v Solr je linearne zavisla na pocte unikatnych termov vo fielde na ktorom sa spaja. Kedze my by sme joinovali na PID, → pocet unikatnych hodnot je pocet dokumentov
      • rovnaky princip ako pri Join Query vyssie

3. Oddelene indexy - spojene data

   • duplikovane data
   • problem s udrzanim dat synchronizovanych (zmeny v povodnom indexu mozu prebiehat radovo v minutach), hlavne pri vacsich indexoch

Solr Join Query

**Vyber z dokumentacie Solr Join Query prisposobeny pre kontext Krameria** [Joining across Single Shard Collections](https://solr.apache.org/guide/8_6/other-parsers.html#joining-across-single-shard-collections) Let’s consider an example where you want to use a Solr join query to filter publications by nameTag_persons that contain `Karol`. Specifically, imagine we have two collections with the following fields: kramerius: pid, title, text, ... kramerius_plus: pid, nameTag_persons, lemma, ... To filter documents by nameTag_persons that have `Karel` using a Solr join on the kramerius_plus collection, you can send the following filter query to the kramerius collection: /solr/search/select?fq={!join from=pid fromIndex=kramerius_plus to=pid}nameTag_persons:Karel Notice that the query criteria of the filter (`name_tag_persons:Karel`) is based on a field in the collection specified using `fromIndex`. Keep in mind that you cannot return fields from the `fromIndex` collection using join queries, you can only use the fields for filtering results in the "to" collection (`kramerius`). **Replica node of metadata index must exist on every node with original collection** Next, let’s understand how these collections need to be deployed in your cluster. Imagine the **kramerius** collection is deployed to a four node SolrCloud cluster and has two shards with a replication factor of two. Specifically, the **kramerius** collection has replicas on the following four nodes:
node 1: kramerius_shard1_replica1
node 2: kramerius_shard1_replica2
node 3: kramerius_shard2_replica1
node 4: kramerius_shard2_replica2 To use the **kramerius+** collection in Solr join queries with the **kramerius** collection, it needs to have a replica on each of the four nodes. In other words, **kramerius+** must have one shard and replication factor of four:
node 1: kramerius+_shard1_replica1
node 2: kramerius+_shard1_replica2
node 3: kramerius+_shard1_replica3
node 4: kramerius+_shard1_replica4 [Joining across multiple collections](https://solr.apache.org/guide/8_6/other-parsers.html#cross-collection-join) - The Cross Collection Join Filter is a method for the join parser that will execute a query against a remote Solr collection to get back a set of join keys that will be used to as a **filter query** against the local Solr collection. - remote Solr collection results only used as filter query - cant use for relevancy sorting - **Joins in Solr can't return results from both sides.**

Zaver a navrhy reseni

Z vyse uvedeneho plyne, ze ani jedna z moznosti neni idealna

Cestu nejmensiho odporu vnimame v 3. moznosti

• bylo by potreba se snazit drzet SOLR aktualni, i presto, ze se index obnovuje radove v minutach, je to opravdu klicove mit solr aktualni v kazdy jeden okamzik ??
• Nebo si muzeme dovolit zpozdeni mezi indexy - napr 1 denni zpozdeni vuci puvodnimu systemu Kramerius, synchronizovat kazdy den o polnoci

Zde vnimame moznou potrebu budouci soucinnosti ze strany Inovatiky

• bylo by potreba probrat moznosti, jaky by to melo dopad na kooperujici firmu Inovatika

Prosime o potvrzeni nasich pohledu na vyse zmineny obsah.

[bukovskyIQ]

Prosíme o vyjádření ze strany Inovatiky.

[hlageek]

Za uživatelské hledisko - smysl Feederu je přístup k datům, ne nutně k aktuálním datům. I kdyby se aktualizovala jednou za měsíc, stále je to ok. Tedy možnost 3) za mě nejvhodnější.

[vlahoda]

Muj komentar za Inovatiku: TLDR: souhlasim :-)

Podrobneji:

• Varianta 1 by byla mozna jedine za predpokladu, ze by udrzbu struktury smiseneho indexu plne prevzal administrator takoveto kombinovane instalace Krameria a Krameria+. V praxi tezko proveditelne.

• Varianta 2 je technicky nejschudnejsi, ale zrejme nepokryva vsechny use cases Krameria+

• U varianty 3 neumim posoudit, jak velky problem je zpozdena synchronizace indexu. Podle meho nazoru by synchronizace jednou denne mela stacit, ale neznam vsechny predpokladane use cases Krameria+. Synchronizace indexu by mela byt plne v rezii Krameria+, je tedy jen na administratorovi a celkove konfiguraci propojenych systemu, aby Kramerius+ mel pristup k indexu Krameria. Kvuli synchronizaci indexu nebude potreba uprava / rozsireni API Krameria.

[motyc]

Souhlasím, že v kontextu napsaného se řešení 3 jeví jako nejschůdnější, byť to jistě znamená nevětší nároky na infrastrukturu (zde musí říct knihovny, co je schůdné). Postup podle 2 je příliš omezující pro uživatele a postupu podle 1 (který by byl řešením ideálním) brání organizační otázky.

Se synchronizací je to tak, jak píše výše @hlageek - vzhledem k účelu systému jde o zanedbatelný problém.

[zabak]

Taky si myslím, že varianta 3 je nejschůdnější. U varianty 2.ii. se bojím té lineární závislosti (i když je jen lineární), protože 60 mil. stran je už hodně a systém by přece jen měl reagovat v rozumném čase. Což nevím jestli by bylo možné při spojování dosáhnout. Naopak jak už psal @hlageek tak vzhledem k tomu, že aktualizace tečou jedním směrem (Kramerius -> Kramerius+) tak se jen musíme naučit vypořádat s tím, že v jednom systému je něco co ve druhém ještě není. Trochu problém vidím v mazání a opravách: měli bychom automaticky v K+ mazat vše, co se smaže v Krameriu? Co když je ale na ta smazaná data navěšený nějaký existující výstup, třeba jsou součást nějakého datasetu?

[JanMeritus]

dobry den, celkove si myslim ze reseni c. 3 je idealni a soucasne situaci nejlepsi. S urcitym narokem na provozni prostredky a ztratou HA pro veci ktere se menili se bude nutno smirit, cenou ale bude lepsi variabilita a dostupnost obou systemu (jinde aktualizujeme v radu minut uz ted a je to ok)

• varianta 2 a jeji subvarianty zni zaujimave, ale bylo by to nutno mit velice dobre nastaveno a nevim jaky dopad by to melo na provoz standardniho Kram. Do budoucna to je mozna cesta, zatim ale nevim.

• @zabak mazani a opravy je vec ktera je obecnejsi a podle mne na samostatny tiket, je tu nekolik problemu se sbirkami a datasety

[MLhotak]

Sice se mi po schůzce zdála jako nejzajímavější varianta 1 solr a 2 shardy, ale očividně to má své nevýhody. Takže se zdá, že varianta 3 je nejschůdnější řešení. Můžeme narazit na problém při přenášení dotazu z klienta Krameria do klienta Feederu a to ve chvíli, kdy je v klientu Krameria ve výsledcích vyhledáno něco, co ještě není v indexu Feederu. Myslím, že to může být řešeno i nějakou informací pro uživatele, z které tato skutečnost bude jasná a bude jasné, jak rychle nebo v jakém čase probíhá aktualizace indexu Feederu.

[JanMeritus]

@MLhotak muze tam byt obecna informace a k ni mela by tam byt urcite timestamp aktualni verze indexu

[zabak]

Rozhraní pro uživatele se bude muset vypořádat s tím že v Krameriu může být něco co nemá vůbec nic v tom druhém indexu - tj. nemelo by to skončit chybou, hlavně ne chybou která bude blokovat práci uživatelů.