Hogy működik az Advise keresés? Avagy: idegenvezetés a gomb megnyomásától a találatra kattintásig.
[email protected]
Összefoglaló Mi történik, mikor megnyomom a gombot?
A Query parser ASE4j
Index adatszerkezetek A Query solver Advise Relevancia függvény
Mi történik, mikor megnyomom a gombot? Profil megállapítása
AdwseCoreModule.actionProfiledSearch(…)
INTRASEARCH, PUBLICSEARCH – ezeket kötelező telepíteni!
GWT RPC hívás
AdwseCoreService.search(…)
PushService Mi ez? Párhuzamos keresést támogató megoldás – a szerver-kliens szerepek kissé felcserélődnek (a kliens polloz, a szerver eseményeket „tol le” a kliensnek).
AbstractSearchPushProcessor A keresési folyamatot vezérlő alaposztály (SearchPushProcessor, HistoryPushProcessor stb.) Többfelé ágazik a hívás (forrásrendszer szerint), párhuzamos végrehajtás (ExecutorService – thread pool)
ParallelServiceProvider/ParallelSearchService implementációk Párhuzamos keresést végeznek
SearchServiceImplV2 – ez már az ASE4j felé delegál
A Query parser Feladata: Java objektumokat csinálni a felhasználó által beírt sztringből.
Egy nagyon egyszerű JavaCC (JJTree) nyelvtan
Nem tartalmazza az opciók feldolgozását (pl.: source:), mert azt egyszerűbb Java-ból QueryParserService A levél csomópontokat (phrase) a WordMiner-en és a StemmingServiceen is átvezeti Az eredmény egy Query objektum: Select kifejezés: mik azok a gráf csomópontok, amikből ki akarunk indulni (pl.: ”alma*” AND ”körte*” NEAR ”pálinka”)
Filter kifejezés: mik azok a feltételek, amiknek a cél csomópontoknak meg kell felelniük (pl.: url like ”file://bpifile01/.*”) EdgeFilter: mik azok a feltételek, amiknek minden élre teljesülniük kell (csak a típusos tárolónál van értelme) Limit, params:
ASE4j 1/2 Mi ez: Associative Storage Engine for Java
Általános objektum gráf tároló (ase4j-server) Asszociációs tárolók (AssociationStore) SimpleAssociationStoreImpl
objektum súly objektum
DocumentAssociationStoreImpl
objektum pozíciók objektum
TypedAssociationStoreImpl
objektum típus objektum
Objektum tárolók (ObjectStore) FileObjectStoreImpl
attr1, attr2, … attrN – fájlokban + index(ek)
schema.xml – milyen tárolók és hogyan vannak összekötve Vigyázzunk, ha a schema.xml-t meg akarjuk változtatni! ase4j-client: kliens oldali kódok, tipikusan elég ezt behúzni, a szerver oldal tud standalona futni (a kommunikáció RMI-n keresztül megy) Indexelés: AssociationStore.addAll(List
>) Keresés: AssociationStore.query(Query
query)
ASE4j 2/2 Tervezési megfontolások
On-the-fly indexelés (ne kelljen denormalizálni)
Indexelés közben már lehessen keresni Nagyon gyors legyen a keresés Max. 2Mrd objektum (int) Max. néhány 100 Mrd asszociáció (long) Törölni nagyon-nagyon ritkán kell, az az egy nem baj, ha lassú Legyen lehetőség egyszerű klaszterezésre Lehessen Java-ból indítani (Unit tesztelés) Lehessen logikai kifejezéseket megadni Lehessen szórészletre keresni Lehessen idézőjelesen keresni
Index adatszerkezetek 1/2 Lényegében egy blokk alapú ritka mátrix.
Asszociációk tárolása blokkokban
size
from
to1
…
to2
val1
…
val2
SimpleAssociationBlockImpl
size
from
to1
to2
…
val1
val2
…
DocumentAssociationBlockImpl
pos11
pos12
pos13
…
pos21
pos22
…
pos31
TypedAssociationBlockImpl
size
from
to1
to2
…
type1
type2
…
A blokkokat a …AssociationStoreImpl-ek mentik és töltik be (CachedBlockStore), felépítése: Magic: AS4J Index tábla: 2n méretű egyszerű tömb, int long (file pozíció) 2n méretű blokkok sorban – ha egy blokk túlnövi a méretét, megduplázzuk és a fájl végére írjuk (append only – helypazarló, de gyors). Ha az index túlnövi a méretét, megduplázzuk, és újraépítjük a fájlt A blokkokat cache-eljük (WorkingSet), mert így az indexelés sokkal hatékonyabb
Minden blokkhoz tartozik egy …QueryBlockImpl is Blokk megtalálása: from obj. obj. tároló id (int) index tábla file pozíció
Index adatszerkezetek 2/2 Objektumok tárolása Mi az objektum? Név-érték párok listája
Egyszerűsítés: értéknek nem engedünk meg másik objektumot (pontosabban: annak az attribútumai már nem lesznek indexelhetőek) Tároljunk minden attribútumot külön fájlban! Helytakarékos (ha egy attribútum) Gyors (egymástól függetlenül, append-only)
Attribútum-tároló (FilePropertyStore) Magic: PROP Index tábla: 2n méretű egyszerű tömb, int long (file pozíció) Szerializált értékek (String, Long, byte[], Serializable, bármi…)
Attribútum indexelés Pontosan egy attribútumot ki kell jelölni az objektum kulcsának (pl. URL), ennek egyedinek kell lennie, és kell hozzá index (schema.xml) Az index lehet bármi, ami implementálja a UniqueIndex-et
Objektum megtalálása: key unique index id (int) index tábla file pozíció deszerializálás (és ezt minden attribútumra)
A Query solver A keresés lelke.
AbstractSolver ősosztály, tárolóspecifikus implementációk DocumentAssociationStoreImpl.query(Query)
AbstractSolver.solve(Query) Select kifejezés kiértékelése DocumentQueryBlockImpl Egyszerű halmazműveletek a blokkon + alapvető relevancia számítás
Filter kifejezés kiértékelése A query blokk elemeinek lekérdezése a ”to” ObjectStore-ból Filter kifejezés ellenőrzése, amire nem teljesül, azt kidobjuk
Limitálás – Top N relevanciájú elemet leválogatjuk Eredmény lista összerakása (List>)
Logikai műveletek (halmazműveletek) AND – metszetképzés két blokk ”to” azonosítói között OR – unióképzés a két blokk között NEAR – speciális metszetképzés: csak akkor kerül egy ”to” a metszetbe, ha a pozícióadatai a másik blokkban kellően közel vannak hozzá (+azoknak a relevanciája lesz a legnagyobb, akiknél ez a távolság a legkisebb) NOT – speciális kezelést igényel, pl.: NOT x kifejezés értelmezhetetlen, de pl. az x AND NOT y értelmezhető
Relevancia függvény 1/2 Lehetővé teszi a relevancia számítás paraméterezését RelevanceCompiler és IRelevanceProvider
Performancia okból futási időben fordított Java kód Alapértelmezett:
Td 2 r = Ri + Rd + Rs e + cu Ru
A lényeg: r = f Ri , Rd , Rs ,Td + cu Ru alakú, ahol f() tetszőlegesen megváltoztatható!
Relevancia függvény 2/2 Paraméterei Ri (indexRel) – Index tárolóból származó relevancia. Ez a súlytényező elsősorban attól függ, hogy a keresett kifejezés(ek) milyen közel szerepelnek egymáshoz a dokumentumban, és másodsorban attól, hogy hányszor.
Rd (docRel) – Dokumentum súly. Ez a súlytényező egy, a dokumentumhoz kötött érték. Segítségével bizonyos dokumentumokat fontosabbnak jelölhetünk meg mint másokat – függetlenül attól, hogy milyen keresőkifejezéssel történt a keresés (természetesen a keresett szavaknak szerepelniük kell a dokumentumban).
Rs (sourceRel) – Forrásrendszer súly. Ez a súlytényező egy, a forrásrendszerhez (pl. fileserver1, exchange, intranet3) kötött érték. Segítségével megadhatjuk, hogy mely források fontosabbak, és melyek kevésbé.
Td (docAge) – A dokumentum életkora, évben megadva. (pl. egy 6 hónapos dokumentum életkora 0.5).
Ru (userRel) – A felhasználói relevancia. Segítségével az egyes
keresőkifejezésekhez kapott találati listák tetszőleges módon átsorrendezhetőek.
