Hlavní navigace

Vlákno názorů k článku Stane se Džykso českým Google? od kp - Michale, to jste ale mohl opravit to s...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 9. 2002 0:41

    kp (neregistrovaný)
    Michale, to jste ale mohl opravit to s tim spellem, i tady to porad nekomu hazelo tu XML prisernost misto vysledku - jako na zive.cz...

    Jinak je to **konecne** dobry fulltext v cz. Co bych ale vytknul:

    1. zkuste pouzit invertovane seznamy (mate-li to v tom) se skipem. Velice zle roste cas na reseni dotazu s poctem termu. Podle tech casu bych si dokonce tipnul, ze jezce po seznamech soupete v priority queue jen jeden po druhem. Takze se ty casy scitaji. Doporucuji prace p. Moffata v teto oblasti.

    2. v urcitych dotazech se mi stava, ze to hazi podobne vysledky hned za sebou. Pritom zmena je jen hlavicce nebo titulku.

    Jinak opravdu solidni, libi se mi to.

    Prozradite jak je nakrajeny index, abyste ho mohli updatovat tak casto, jak rikate?
  • 6. 9. 2002 10:48

    Michal Illich (neregistrovaný)
    > Jinak je to **konecne** dobry fulltext v cz

    Dekujeme.

    > 1. zkuste pouzit invertovane seznamy (mate-li to v tom) se skipem.

    Od Moffata jsem online dostupneho nic nenasel, i kdyz abstracty vypadaji zajimave.
    Co jsem ale uz mel prilezitost poznat vselijake "lepsi" invertovane seznamy, tak nic z toho nebylo v praxi pouzitelne.
    Pocitejte se mnou:
    Mame nejake slovo, rekneme 20000krat se opakujici v mnozine dokumentu.
    Pokud chceme vyhledavat, delame toto:
    1. Najdeme si, kde je seznam na disku --- konstantni cas, <1ms
    2. Disk seekuje - konstantni cas, ~10ms
    3. Precteme seznam z disku - umerne poctu, pri rychlosti 40MB/s je to 1-2 ms
    4. Zpracujeme seznam - umerne poctu, rychle, dalsi 1ms

    Tedy: jedine, kde ma smysl setrit je bod 2, vsechno ostatni probehne v podstate okamzite.
    A zrovna to je bod ktery se usetrit neda - celou databazi do pameti narvat nelze a tudiz alespon jeden seek musi probehnout...
    Jakekoliv komprese a jine upravy invertovanych seznamu obvykle zkrati bod 3, drobne na ukor bodu 4.
    Vzhledem k tomu, ze dnes jsou disky velmi levne, neni duvod setrit na miste.

    -

    > Prozradite jak je nakrajeny index, abyste ho mohli updatovat tak casto, jak rikate?

    Je to dano odlisnou architekturou vyhledavace - databaze neni jedna obrovska, ale spousta mensich - kazdou je mozne pomerne svobodne aktualizovat, kdy je to potreba.
  • 6. 9. 2002 23:05

    pb (neregistrovaný)
    Moffat delal se Zobelem praci o invertovanych seznamech se skip operaci .Seznam byl rozdelen na bloky a tem predrazeny hlavicky - kdyz se melo jet v tom seznamu na nejakou pozici, dalo se tam "doskakat", protoze hlavicka urcila, zda ma cenu nasledujici blok cist - nebo preskocit. Vysledek byl ten, ze s 50ti termy to bylo 2xrychlejsi jak pri reseni dotazu s jednim. Pochopitelne vse bylo jeste pod kompresi. Co se tedy zkratilo je (3) a (4) Vaseho seznamu. Vyzkousejte vetsi pocet termu do jyxo. Cas jde razantne nad nekolik sekund - jednou mi to snad dal az za 5-10sec, uz nevim presne...

    To chapu, ze je index nakrajeny, ale otazka je JAK:-). Je to nakrajene podle domen, podle poctu dokumentu, podle termu, krajene vertikalne, horizontalne...
  • 7. 9. 2002 11:23

    Michal Illich (neregistrovaný)
    Bod 3 (cteni z disku) neusetrite - pokud to ma preskocit par bajtu (a nikdy to vic nebude), tak se to z disku stejne musi precist (trebaze to vy neuvidite, operacni system nebo hardware to udela za vas, aby neseekoval). Tenhle trik muze byt uzitecny pri in-memory invertovanych seznamech, ale pro VELKY fulltext je to nepouzitelne.
    "50 termu dvakrat rychlejsi nez s jednim" -> to znamena jedine, neseekovali, tedy meli malou databazi v pameti.
  • 7. 9. 2002 20:31

    pb (neregistrovaný)
    Bod 3. Tech par bajtu ovlivnite tim, jak velke bloky si v seznamech sam nadelate. Neni proto pravda, ze se tim usetri malo. Usetri se tim naopak hodne a mate-li dotaz typu A AND B (tedy Vas defaultni pristup) dela uspora extremne moc pri A hodne rozdilnem od B (casty versus obecny term). Pokud je mi znamo, prave velke stroje tohle pouzivaji v ruznych obmenach, protoze jinak musi vzdy cist cele seznamy a to je extremne neefektivni prave u dlouhych seznamu.

    Existuji i techniky, kdy se stavi bloky nad bloky atd. Efektivni je to tusim do urovne 2-7, ale nejsem si jist. Vim jen, ze pri blocich o 10000 polozkach bylo zrychleni pri 32 termech zhruba 5ti nasobne.

    Zaver ktery jste si na zaklade sve vlastni uvahy ucinil je mylny.
  • 7. 9. 2002 21:44

    Michal Illich (neregistrovaný)
    Prominte, probereme si to jeste jednou, ano? ;)

    U soucasnych disku trva seek prumerne 8 - 10 ms.
    Tytez disky ctou data rychlosti 40MB/s.
    Za 10 ms tedy prectou 400kB.

    Presne tato hodnota tedy vyjadruje, kolik by se muselo preskocit dat, aby toto preskoceni bylo vyhodne.
    Samozrejme kratsi seeky jsou rychlejsi; a pokud jsou prilis kratke, tak se disk pohybuje stejne jako kdyby cetl, ale "naprazdno", tedy ani zde se nic neusetri.

    Tedy myslenka je to dobra, ale funguje pouze pokud provadite operace v pameti, kde "seekovani" neexistuje.
  • 8. 9. 2002 23:53

    pb (neregistrovaný)
    Vase vysvetleni je dobre, ale pouze v pripade, ze disk ani system nedisponuje takovymi vecmi jako je read-ahead cache a pre-fetch. U disku co tahaji 40MB/s se domnivam ze budou... :-)

    Jestli vymyslite, jak zrychlit ty dotazy co jyxo trvaji i vice jak 10sekund, dejte vedet. Zajimalo by me, jestli toho dosahnete pres skipy (a diky cache je jedno jestli v pameti nebo na disku) nebo jinou technikou.
  • 9. 9. 2002 9:50

    Michal Illich (neregistrovaný)
    No tak jsme se konecne shodli na tom, ze na rychlosti cteni z disku se nic neusetri ;)
    (to, ze to user-space proces cteni nevidi, neznamena, ze disk ta data necte - trebas jako readahead)

    Nevim, jake dotazy pokladate, ale v 95% jsou rychlosti pod jednu sekundu, obvykle se pohybuji okolo 150-200ms.
    Dokonce i kdyz zadam treba dotaz 'we all live in our yellow submarine', ktery by mel byt uplnym peklem (hodne slov a vetsina velmi casta), tak Jyxo odpovi za skvelych 372 ms.

    Skoro si troufam tvrdit, ze nas software je nejrychlejsi, ale to by chtelo nejake testy (stejna db na stejnem hardwarem), coz je dost nemyslitelne.

    PS: "pb"!="kp", predpokladam?
  • 10. 9. 2002 1:48

    pb (neregistrovaný)
    Ne, "pb"="kp", jsem u kolegy na chate a cookiny jsem si nevzal.

    Ted k tomu faktickemu.

    1. porovnavate nahodny seek a sekvecni cteni. Porovnejte bud nahodne cteni a nahodny seek, nebo sekvencni cteni a sekvencni seek (skip). Zaver si ucinte sam. Howgh

    2. kdyz zbytecne prenasite po sbernicich do pameti (az na user level), ztracite vykon ve vetsi zatezi. Howgh

    3. dovolte mi myslenku - "pycha predchazi pad". Psal jsem nekolik stroju pro zahranicni firmy a muzu Vam rict jedno - kdyz si zacnete myslet, ze Vase algoritmy jsou uz nejlepsi mozne, prohral jste. Pozna se to na TREC testech, kde uz to nejde "okecat" srovnavanim jablek a hrusek. Howgh.

    Co jit nekdy do hospody?
  • 10. 9. 2002 10:38

    Michal Illich (neregistrovaný)
    ad 1) no, ono ja porovnavam to, co stroj skutecne dela - nejdriv 'nahodny' seek (slova v polozenych dotazech jsou z hlediska abecedniho umisteni "nahodne") a pak sekvencni cteni (invertovany seznam je k jednomu slovu ulozen na jednom miste). "Nahodne cteni" u disku neexistuje (oproti RAM, ktera to ma v nazvu) a "sekvencni seek" je trochu protimluv, i kdyz jsem uz vyse uznal, ze seek na kratke vzdalenosti muze byt rychlejsi.

    ad 2) rychlost disku 40MB/s, rychlost kabelu 133MB/s, rychlost pameti 600MB/s - at srovnavam, jak srovnavam, bottleneck je disk

    ad 3) nikde jsem netvrdil, ze nase algoritmy jsou nejlepsi mozne; ja dokonce vim, v kterych smerech jdou zlepsit - nicmene zlepseni by vyzadovalo napr. mit 30GB pameti, atd., coz bohuzel zadny cesky klient nezaplati

    'hospoda' (teda s lehkou modifikaci, nebot alkohol nepiju a zakourene prostredi taky nemusim, tedy preferuji cajovny/kavarny) muze byt zajimava. Napriklad proto, ze jsem jiz slysel nejmin pultuctu lidi pochybovat o vasi existenci (pochyby vetsinou zpusobene duplicitou vaseho jmena) ;-). Mimochodem, vy nejste v Anglii ?
  • 11. 9. 2002 1:37

    kp (neregistrovaný)
    Batlnek neni jen disk. Disky (i mean arrays) se daji pomerne solidne slozit pres slice aby se plotny tak nezatizily. Nejcastejsi invertovane seznamy se daji dat do barelu v pameti. Ono je to trochu komplikovane, asi mame ted kazdy z nas jinou architekturu pred ocima. Znam par stroju co treba zkousi kompresi i v pameti, aby ziskaly vykon (vetsinou tim usetri pro vetsi cache pametovych barelu atp.).

    Z lidi si moc nedelejte, byli jsou a budou, jen software je vecny! :-) V Anglii nejsem - v dobe letadel jsem tak trochu vsude. Jeden den se nekde naloguju a hned druhy den tam jsem i fyzicky. Protoze proste obcas hrabnu kam nemam a chce to zasah, nebo me pozvou naopak na oslavu :-)
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).