Closed bodnarIQ closed 2 years ago
Prosíme o vyjádření ze strany Inovatiky.
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ší.
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.
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.
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?
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
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.
@MLhotak muze tam byt obecna informace a k ni mela by tam byt urcite timestamp aktualni verze indexu
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ů.
Analyza moznych reseni aktualniho stavu
Spolocny solr index - spolecna data
Oddelene indexy - oddelene data
Kramerius+ vlastny solr core
Kramerius+ vlastna solr kolekcia (pri vyuziti SolrCloud)
Oddelene indexy - spojene data
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
Zde vnimame moznou potrebu budouci soucinnosti ze strany Inovatiky
Prosime o potvrzeni nasich pohledu na vyse zmineny obsah.