Over de search

[Verwijderd]

Hi.

Even naar aanleiding van de post van JVS in gebruik de search!!!! .

Dat de search slecht werkt weet inderdaad iedereen, maar wat ik graag wil weten is hoe hoog het eigenlijk op het verlanglijstje van (gathering of)Tweakers staat om dit eens te verbeteren. Sinds de forumsoftware-update werkt de search gewoon verschrikkelijk slecht tot helemaal niet en het resultaat is dat mensen (inclusief ikzelf) toch makkelijker een topic openen over dingen die vaak al lang voorbij gekomen zijn!
Zo ook DIT topic dat je nu leest. Type maar eens 'search' in bij de search bijvoorbeeld.

Ik bedoel niet te zeggen dat jullie NU op mijn commando die search moeten gaan verbeteren. (Hoewel ik dat wel graag zou zien natuurlijk ), maar wat ik vooral wil zeggen is dat een hoop kennis en oplossingen voor problemen gewoon verloren gaan door zo'n slechte search. All in all is GoT naast een gezellig forum inmiddels wel uitgegroeid tot een heuze "knowledge base" (da's Engels ja). Ik vind het zonde dat deze momenteel slecht tot helemaal niet toegankelijk is, want de waarde van al die opgeslagen kennis is echt ENORM.
(Oh, en dat er een alternatieve search is weet ik , maar deze is nog niet zo goed als de 'oude' search en daarnaast, GoT moet toch gewoon zelf een search hebben?)

[ Voor 11% gewijzigd door Verwijderd op 08-12-2002 04:14 ]

[Verwijderd]

Helemaal met je eens..als ik met problemen zit kom ik altijd op GoT..en dan gebruik je toch die search die idd slecht werkt.

[Vae Victis]

Verbetering van de search word wel hard aan gewerkt
Maar zelfs met 2 'brakke' search is het nog wel redelijk te doen je moet alleen even wat moeite doen om andere search criteria te gebruiken.
Dan vind je wel wat je wil weten, en anders is google er ook nog.

Als je in med had gekeken:
Downtime, React v1.7, Search
Dan ahd je uit reactie van ACM al kunnen lezen wat er gedaan word op dit moment.

[Verwijderd]

Vae Victis schreef op 08 december 2002 @ 04:12:
Verbetering van de search word wel hard aan gewerkt
Maar zelfs met 2 'brakke' search is het nog wel redelijk te doen je moet alleen even wat moeite doen om andere search criteria te gebruiken.
Dan vind je wel wat je wil weten, en anders is google er ook nog.

Als je in med had gekeken:
Downtime, React v1.7, Search
Dan ahd je uit reactie van ACM al kunnen lezen wat er gedaan word op dit moment.

Sja, dat het 'te doen' is begrijp ik ook wel. Ik kom ook niet voor het eerst op Got en ik denk in plaats van 3 wel 10 keer na voor ik een topic open (behalve HK dan) en ik ben ook vrij goed bekend met Omega. Daarnaast, het topic waar je naar linkt heb ik gelezen, maar ik word er niet echt blij van. Ik begrijp goed dat de mensen hier hard hun best doen om een goed Got + search te maken hoor, begrijp me niet verkeerd. Ik waardeer dat zeer, maaarrr....
Is het niet mogelijk om de oude search terug te brengen onder de huidige software, of zeg ik nu iets heel geks? Goed. Er zal al veel over nagedacht zijn door de crew en ik (of anderen hier) gaan ook zeker niet de oplossing aandragen (denk ik). Feit blijft echter dat er momenteel een enorme hoop kennis onbereikbaar is en ik vraag me gewoon af of dit prioriteit heeft voor de crew of niet.

[ Voor 8% gewijzigd door Verwijderd op 08-12-2002 04:25 ]

[Vae Victis]

Het is idd, jammer dat het niet lekker werkt. Maar er is al meerdere malen gezegt dat er aan gewerkt word.
Dus wat wil je nog meer horen? Dat het morgen al klaar is? Dat is gewoon niet mogelijk.
Zoals je uit die med topic kan maken, neemt het gewoon wat tijd in, en in die tijd moeten wij ons zien te redden.
Maar om nu om de minst of geringste een topic te openen omdat de search niet werkt is niet nodig. Gewoon geduld hebben, it's finished when it's done.

Is het niet mogelijk om de oude search terug te brengen onder de huidige software, of zeg ik nu iets heel geks?

[rml]ACM in "[ omega] Foutmelding: Error seeking to bl"[/rml]
Tja wat kun je daaraan toe voegen

Kan me wel herrineren dat ik ergens gelezen heb dat de search van topix ook al aan zijn max van presteren zat, en dat hij zelfs als dat kon nog erger zou presteren als deze search.
Maar die stukje kan ik niet zo gauw vinden.

[ACM]

Verwijderd schreef op 08 december 2002 @ 04:07:
Dat de search slecht werkt weet inderdaad iedereen, maar wat ik graag wil weten is hoe hoog het eigenlijk op het verlanglijstje van (gathering of)Tweakers staat om dit eens te verbeteren.

Hoog, maar op de 'maar' kom ik zo op terug.

Ik bedoel niet te zeggen dat jullie NU op mijn commando die search moeten gaan verbeteren.

Als het een kwestie van 10 seconden werk (of zelfs 10 uur) was, dan was het allang gedaan

All in all is GoT naast een gezellig forum inmiddels wel uitgegroeid tot een heuze "knowledge base" (da's Engels ja). Ik vind het zonde dat deze momenteel slecht tot helemaal niet toegankelijk is, want de waarde van al die opgeslagen kennis is echt ENORM.

Uhuh.

(Oh, en dat er een alternatieve search is weet ik , maar deze is nog niet zo goed als de 'oude' search en daarnaast, GoT moet toch gewoon zelf een search hebben?)

Die alternatieve search is veelal _beter_ dan de 'oude search van topix'.

Even voor de duidelijkheid, de topix search engine gebruikte hetzelfde principe van opslaan en doorzoeken van de database als React nu doet, sterker nog, in principe is die van React beter.
Echter werd de topix-search ook zeer sterk genekt door de grootte van de database en hebben we (eerst Femme en later ik) er al een aangepaste methode omheen gebakken.
Daardoor werd er in topics van maximaal 100 dagen oud gezocht, was er een voorkeur voor zoeken op topictitel, kon je echt niet op woorden kleiner dan 3 karakters zoeken.
En ook bij topix waren de klachten over de "slechte search engine" niet van de lucht (hoewel dat natuurlijk niet altijd aan de engine te wijten was )
Bij React wilden we graag weer proberen de complete database te indexeren (die ondertussen zowat verdubbeld was trouwens), maar door de enorme grootte ging dat dus mis, de topix-engine had het niet sneller kunnen indexeren trouwens (volgens mij zelfs langzamer dan de laatste react-versie het deed, maar dat hebben we nooit echt vergeleken).

Wat mijn alternatieve engine _wel_ kan en topix/react niet is zoeken op willekeurig korte (niet helemaal lange, dat is op 50 chars gelimiteerd) woorden, zelfs een woord als c++ en getallen snapt ie.
Daarnaast is ie veel sneller en efficienter met doorzoeken van zijn eigen zoek-database (die nu 9.5GB is).

Dat die omega-engine nog niet perfect is, daar ben ik me maar al te goed van bewust, maar volgens mij is ie net zo 'kreupel' als de engine van topix, maar op andere vlakken...

Goed, doordat die omega-engine opzich wel goed werkt en vooral een stuk sneller is dan de topix/react-engine hebben we besloten voor GoT de interne mysql-based-engine niet meer toe te passen en ook niet verder te ontwikkelen. Mysql laat gewoon de schaling van de search-engine niet toe en dat was ook wel te verwachten als je een beter begrip van die search-engine hebt, vroeg of laat zou het tegen flinke beperkingen oplopen en met trucjes kan je dat wel wat vooruit schuiven maar het houdt een keer op. En daar liepen we dus tegen aan.

Daarom besloten we dat we beter een engine als omega (maar wellicht niet omega zelf, omdat ie nog wel wat probleempjes heeft )

Het nadeel van het toepassen van zo'n engine is echter dat het veel tijd kost om een goede uit te zoeken, die dan om te bouwen zodat ie voor React geschikt is en hem dan te testen (alleen het indexeren van de GoT-db kost al gauw een paar dagen, en veel kleinere db's testen heeft alleen nut om de werking te testen, niet voor de performance).

Verwijderd schreef op 08 december 2002 @ 04:22:
Is het niet mogelijk om de oude search terug te brengen onder de huidige software, of zeg ik nu iets heel geks?

Ten eerste, we hebben geen toegang tot de source-code van topix. Toevallig wel tot de indexeer-code van hun zoekmachine, maar dat zegt niet dat we dat zomaar mogen kopieren.
Goed, doordat ik die code wel es ingekeken heb, weet ik dat hun zoekmachine hetzelfde principe gebruikt als wat we met React probeerden en dat dat dus met grote databases in de problemen kan komen.
Dus naast het feit dat we die code niet zomaar mogen gebruiken (niet onoverkomelijk, weet ik wel ) hebben we het eigenlijk al getest (in een andere vorm).

Vae Victis schreef op 08 december 2002 @ 04:57:
[rml]ACM in "[ omega] Foutmelding: Error seeking to bl"[/rml]
Tja wat kun je daaraan toe voegen

Tsja, dat ging over een oude versie van omega terugzetten, niet over de engine van topix

Anyway, ik zal dan deze uitgebreide uitleg post ook in dat MED-topic linken en daarom hier nog even uitleggen _waarom_ de mysql-based engines zo slecht werken voor ons.

Als je zoekt op de tekst "windows 2000 crasht met games in direct3d" (lijkt me een redelijke zoekstring, niet?)

Dan moet je dus eigenlijk weten hoe een engine probeert te zoeken.
Eerst de react/topix-engine:
- De zin wordt in losse woorden opgesplitst, de overbodige (de zgn ruiswoorden, ze komen zo vaak voor dat het geen zin heeft erop te zoeken) woorden eruit gehaald en dan houden we dus dit over:
windows, 2000, crasht, games, direct3d
- Dan worden er in de zgn woord-topic koppeltabel de bijpassende topics opgezocht.
Er wordt eerst per woord het woordid bepaalt en die wordt van die woordid's een query opgebouwd (afhankelijk of je OR of AND gebruikte verschilt de query natuurlijk), echter is het zo dat er per woord in principe de hele tabel doorzocht moet worden (weliswaar kan je dit door je database laten doen, op een efficientere manier, maar toch). De woord-koppel-tabel bij topix bevatte overigens zo'n 60-80Miljoen woordid-topicid koppels. Als er dus voor het woord 'windows' 50.000 topics gevonden worden en voor '2000' nog eens 50.000 etc heb je al gauw dat je database met enkele honderden-duizenden (of zelfs miljoenen) topicid's opgescheept zit in eerste instantie.
- Als ie die topicid's heeft bijeengegaart, moet ie natuurlijk nog bepalen of je ze dmv AND of OR eruit wilde hebben. Bij OR is dat domweg alle gevonden unieke topicid's sorteren op telling (oid) en bij AND is dat alleen die topicid's opsnorren die alle woorden bevatten.
Kortom, een vrij zware actie (en ja, ik ken het bestaan van indices ).

Het grootste nadeel van deze engine is dus vooral dat ie alle mogelijk geschikte topics eerst op moet zoeken en daarna pas kan proberen het te filteren op de AND of OR.
Zoeken in specifieke forums beperkt natuurlijk wel hoeveel er "mogelijk geschikt zijn", maar het blijft exponentieel (of misschien kwadratisch, maar meer dan lineair) toenemen met de grootte van GoT, waardoor het langzamerhand steeds trager wordt.

Dan de omega/mifluz/whatever-searchengines.
- Deze moeten hetzelfde doen met de woorden, dus ook de ruiswoorden (vaak wel minder, alleen de echt zinloze woorden worden er dan uitgehaald) eruit vissen en de boel omzetten naar woordid's.
Wat er bij omega nog als tussenstap gebeurt is het zgn 'stemmen', er wordt dan van woorden als 'werk', 'werken', 'werkt', 'gewerkt' etc 1 woord gemaakt ('werk'), omdat ze tenslotte min-of-meer hetzelfde betekenen.
- Daarna gaat ie naar documenten op zoek, maar ipv eerst per woord alle documenten te zoeken die kunnen voldoen en ze daarna samen te voegen, draait ie het om.
Er wordt dus gezocht naar alle documenten die voldoen aan al de eisen (en vraag me niet hoe het precies intern werkt, dat weet ik ook niet ) waardoor je, ipv honderduizenden, hooguit duizenden topics terug krijgt.

Dit efficientere zoeken wordt vooral mogelijk gemaakt doordat dat soort engines de zoekdata in een eigen database-formaat opslaan en veelal dan de boel dusdanig kunnen opslaan dat het veel efficienter te raadplegen is.


Goed, ik hoop dat het zo een beetje duidelijker is, zo niet, stel vragen

[Verwijderd]

Omega zoekding legt plat ism met arethusa dus daar komt de tweaker ook niet verder mee he

[Verwijderd]

Oke : 1 vraag : waarom is de externe search offline ?
_{jammer net te laat}

[ Voor 22% gewijzigd door Verwijderd op 08-12-2002 12:46 ]

[Verwijderd]

Verwijderd schreef op 08 December 2002 @ 12:45:
Oke : 1 vraag : waarom is de externe search offline ?
_{jammer net te laat}

dies ook op Vakantie met Arethusa mee

[SambalBij]

Over die Omega search gesproken, daar zit momenteel één heel irritante fout in.
(Dat heeft denk ik met die 'stemmen' te maken)
Bij woorden van meer dan drie letters, eindigend op een 'e' laat hij die laatste e weg.
Zoeken op bijv. 'bode' levert alle resultaten waar het woord 'bod' in voorkomt...
Is dat een bug of een (ongewenste) feature??

[ACM]

dat heet stemmen ja, werkt niet altijd perfect, maar zorgt over het algemeen voor betere resultaten.

[kmf]

Dan bied ik hierbij ook MIJN alternatieve search aan, dat me altijd goed heeft geholpen

Kies rechtsonder bij de topiclijst een weergave van de topics over een groter tijdsbestek. Een jaartje zal wel goed genoeg zijn en CTRL-F dan naar de dingen die je wilt weten.

Knullig, maar werkt IIG WEL altijd en GOED. En als het niet tussen de topics van 1 jaar zit, dan mag je het toch wel openen omdat je geen oude topic zomaar mag kicken

[SH007]

athlonkmf schreef op 08 december 2002 @ 14:25:
Dan bied ik hierbij ook MIJN alternatieve search aan, dat me altijd goed heeft geholpen

Kies rechtsonder bij de topiclijst een weergave van de topics over een groter tijdsbestek. Een jaartje zal wel goed genoeg zijn en CTRL-F dan naar de dingen die je wilt weten.

Knullig, maar werkt IIG WEL altijd en GOED. En als het niet tussen de topics van 1 jaar zit, dan mag je het toch wel openen omdat je geen oude topic zomaar mag kicken

doed ik ook altijd, ware het niet dat bij react die topiclist niet meer volledig is. Hij laat maar een beperkt aantal items zien

[Booster]

Operations schreef op 08 december 2002 @ 13:17:
Zoeken op bijv. 'bode' levert alle resultaten waar het woord 'bod' in voorkomt...
Is dat een bug of een (ongewenste) feature??

ja, dat is inderdaad een erg vervelende 'feature'.

Zoeken op nbase: gezocht op "nbas."
Ik krijg ook vaker wat vreemde errors bij het zoeken daar, die zal ik een keer noteren en posten.

[ Voor 42% gewijzigd door Booster op 08-12-2002 14:29 ]

[Newy]

GRRRRRRRRRRRRR wat nou niets gevonden, wat is er aan de hand met de zoekfunctie,
moet ik eerst betalen ofzo ???????

Krijg er de pleuris in zo langzamerhand

[ACM]

Newy schreef op 08 December 2002 @ 14:42:
GRRRRRRRRRRRRR wat nou niets gevonden, wat is er aan de hand met de zoekfunctie,
moet ik eerst betalen ofzo ???????

Krijg er de pleuris in zo langzamerhand

Dan pleur je toch op?

Niemand verplicht je hier te blijven en moeite doen de lap tekst die ik hierboven getikt heb doe je ook al niet eens...

[ACM]

Booster schreef op 08 december 2002 @ 14:28:
ja, dat is inderdaad een erg vervelende 'feature'.

Zoeken op nbase: gezocht op "nbas."
Ik krijg ook vaker wat vreemde errors bij het zoeken daar, die zal ik een keer noteren en posten.

En wat is je probleem nou dan
Hetzelfde stemmings-algoritme wordt natuurlijk ook bij de opslag gebruikt, dus nbase zal niet in de zoek-db staan, nbas wel...

[Newy]

ACM schreef op 08 December 2002 @ 15:34:

[...]

Dan pleur je toch op?

Niemand verplicht je hier te blijven en moeite doen de lap tekst die ik hierboven getikt heb doe je ook al niet eens...

OK ff gelezen,
ik kom er wel uit.

Zelfs Geforce kon niet gevonden worden, toen ging ff het licht uit.
Sorry

[Packardhell]

Volgens bronnen in Het Abo-forum komt er in react v1.8 waarschijnlijk een betere en nieuwe searchfunctie. Dus 't komt wel goed.

[MSalters]

Ehm, een intersectie van twee gesorteerde verzamlingen gaat (typisch) sneller dan lineair, en zeker niet kwadratisch. 2x50000 ids intersecten uit een set van 8M, dat zou zo'n 100-1000 resultaten opleveren, en dat is O(1000)*O( log(50000) ) = O(16000) operaties.

Kortom, de intersectie is niet de bottleneck.

Met meer woorden wordt het alleen sneller; je intersect eerst de kleinste collecties.

OR is natuurlijk lineair, dus waarschijnlijk ook IO-bound danwel beperkt door de L2/L3 cache-snelheid.

[ACM]

MSalters schreef op 08 december 2002 @ 16:08:

Ik had het meer over de zoekperformance tov de dataset grootte. Een intersectie in een grotere set gaat echt niet sneller dan een intersectie in een kleinere set (wat wel zo zou kunnen zijn als het sneller dan lineair was )

Daarnaast betwijfel ik of mysql zich zo goed aan jouw (nahja, dat schud jij ook niet uit je mouw natuurlijk ) getallentheorie houdt...

edit:
Even kort getest in mysql, en dat kan ie zowaar redelijk goed Nahja, tot op zekere hoogte trouwens, daarna gaat het weer slechter.

En daarnaast zoekt iedereen standaard op OR (wat aan jouw relaas niks af doet), wat vaak betere resultaten geeft dan AND.

[ Voor 42% gewijzigd door ACM op 08-12-2002 16:50 ]

[ACM]

[nohtml]

ACM schreef op 08 December 2002 @ 16:35:
Daarnaast betwijfel ik of mysql zich zo goed aan jouw (nahja, dat schud jij ook niet uit je mouw natuurlijk ) getallentheorie houdt...

edit:
Even kort getest in mysql, en dat kan ie zowaar redelijk goed Nahja, tot op zekere hoogte trouwens, daarna gaat het weer slechter.

Ter illustratie trouwens; een query die, imho, redelijk gelijk is aan het zoeken.

code:

mysql> select count(distinct(t.topicid)) 
from F_Topics t, F_Messages ma WHERE ma.TopicID = t.topicid 
AND ma.userid = 3324;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                      10129 |
+----------------------------+
1 row in set (0.14 sec)
mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb WHERE ma.TopicID = t.topicid AND ma.userid = 3324 
AND mb.topicid = t.topicid AND mb.userid = 2577;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                        209 |
+----------------------------+
1 row in set (0.05 sec)
mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb, F_Messages mc WHERE ma.TopicID = t.topicid 
AND ma.userid = 3324 AND mb.topicid = t.topicid AND mb.userid = 2577 
AND mc.topicid = t.topicid AND mc.userid = 460;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                         92 |
+----------------------------+
1 row in set (0.08 sec)
mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb, F_Messages mc, F_Messages md WHERE ma.TopicID = t.topicid
AND ma.userid = 3324 AND mb.topicid = t.topicid AND mb.userid = 2577 
AND mc.topicid = t.topicid AND mc.userid = 460 AND md.topicid = t.topicid 
AND md.userid = 59;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                         43 |
+----------------------------+
1 row in set (0.20 sec)
mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb, F_Messages mc, F_Messages md, F_Messages me WHERE 
ma.TopicID = t.topicid AND ma.userid = 3324 AND mb.topicid = t.topicid 
AND mb.userid = 2577 AND mc.topicid = t.topicid AND mc.userid = 460 
AND md.topicid = t.topicid AND md.userid = 59 AND me.topicid = t.topicid 
AND me.userid = 3275;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                         29 |
+----------------------------+
1 row in set (1.24 sec)

Kortom, eerst 1 (alle unieke topics waar ik gereageerd heb tellen), dan 2 (alle unieke topics waar AntonT en ik reageerden), dan 3 (Anton, ik en Daniel), dan 4 (Anton, ik, Daniel en Kees) en 5 (Anton, ik, Daniel, Kees en Floris).

Als simpele illustratie voor een stel intersecties zoals die, volgens mij dus, gemaakt zouden moeten worden. Bovenstaande queries kunnen trouwens nog wel iets sneller gemaakt worden door ipv een userid-topicid index een userid-index te hebben, magoed dat maakt voor het verhaal verder niet zo uit volgens mij.

[chem]

Ik heb hier eigenlijk weinig aan toe te voegen...
Laat het duidelijk zin dat we echt hard bezig zijn om een nieuwe search op te leveren. Vooralsnog zitten we met 2 alternatieven nu te testen en verbeteren, het ontbeert ons nu 'even' aan een schijf die een gb of 60-80 vrij heeft en geen 2 gb filesize limit + geen functie in eoa serverpark

Ik geef geen opleverdatum maar we hopen 'spoedig' iig te weten of de 2 alternatieven praktisch zijn.

[Verwijderd]

chem schreef op 08 December 2002 @ 17:08:
Ik heb hier eigenlijk weinig aan toe te voegen...
Laat het duidelijk zin dat we echt hard bezig zijn om een nieuwe search op te leveren. Vooralsnog zitten we met 2 alternatieven nu te testen en verbeteren, het ontbeert ons nu 'even' aan een schijf die een gb of 60-80 vrij heeft en geen 2 gb filesize limit + geen functie in eoa serverpark

Ik geef geen opleverdatum maar we hopen 'spoedig' iig te weten of de 2 alternatieven praktisch zijn.

Ok cool. Het ziet er allemaal erg eeeh spannend uit, dat sql gedoe. Veel succes iig.

[Mr.Vulcano]

chem schreef op 08 december 2002 @ 17:08:
Ik heb hier eigenlijk weinig aan toe te voegen...
Laat het duidelijk zin dat we echt hard bezig zijn om een nieuwe search op te leveren. Vooralsnog zitten we met 2 alternatieven nu te testen en verbeteren, het ontbeert ons nu 'even' aan een schijf die een gb of 60-80 vrij heeft en geen 2 gb filesize limit + geen functie in eoa serverpark

Ik geef geen opleverdatum maar we hopen 'spoedig' iig te weten of de 2 alternatieven praktisch zijn.

Iedereen wil natuurlijk graag een tijdstip hebben wanneer het waarschijnlijk weer werkt. Is het niet mogelijk om een tijdsstip te noemen als, we hopen dan en dan doen we er voor de zekerheid nog bijvoorbeeld vier weken bij, dus dan zeggen we dat we waarschijnlijk rond die datum een goed werkende search functie hebben.

[Erkens]

Mr.Vulcano schreef op 09 December 2002 @ 13:10:
[...]


Iedereen wil natuurlijk graag een tijdstip hebben wanneer het waarschijnlijk weer werkt. Is het niet mogelijk om een tijdsstip te noemen als, we hopen dan en dan doen we er voor de zekerheid nog bijvoorbeeld vier weken bij, dus dan zeggen we dat we waarschijnlijk rond die datum een goed werkende search functie hebben.

mja, mij maakt die "opleverdatum" weinig uit, liever dat het meer tijd kost dan dat we over pak hem beet een half jaar weer een probleem hebben omdat de db dan nog groter is

mja, er is wel een tijd bekend wanneer: z.s.m.

[SambalBij]

ACM schreef op 08 december 2002 @ 13:31:
dat heet stemmen ja, werkt niet altijd perfect, maar zorgt over het algemeen voor betere resultaten.

Dan denk ik dat er iets met dat stemming mechanisme mis is, en wellicht aangepast kan worden??

Om dat toe te passen op een nederlandstalige content, moeten er dus nederlandse stemming regels worden toegepast. Wellicht klopt er iets niet met die regels? (nbase -> nbas, een dood -> dod klopt in ieder geval heel erg niet)
Ik zie op die Xapian site dat stemming optioneel is? Is het dan niet handige het uit te zetten als het toch niet goed werkt, of het wellicht als keuze optie mee te geven die bij de search aan of uit gezet kan worden?

[Ruudjah]

Waarom niet gewoon een quadthlon bak met een enorme berg geheugen erin als DB server? DB in intervallen in mem zetten, en in mem zoeken. Zou toch moeten kunnen werken?

Vergeten: Google verkoopt ook searchtechnologie. Misschien een idee?

[ Voor 18% gewijzigd door Ruudjah op 09-12-2002 16:36 ]

[ACM]

Operations schreef op 09 December 2002 @ 15:32:
Dan denk ik dat er iets met dat stemming mechanisme mis is, en wellicht aangepast kan worden??

Om dat toe te passen op een nederlandstalige content, moeten er dus nederlandse stemming regels worden toegepast. Wellicht klopt er iets niet met die regels? (nbase -> nbas, een dood -> dod klopt in ieder geval heel erg niet)
Ik zie op die Xapian site dat stemming optioneel is? Is het dan niet handige het uit te zetten als het toch niet goed werkt, of het wellicht als keuze optie mee te geven die bij de search aan of uit gezet kan worden?

Zucht...
dood, doden, dode -> dod
Er wordt trouwens een nederlandstalige stemmer gebruikt, dus die zal eerder met engelse dan met nederlandse woorden niet goed werken, maar over het algemeen zijn ze redelijk vergelijkbaar stembaar.

Wat is nou je probleem? Vind je niet de goede dingen door de stemming? Of ben je gewoon beledigd dat de searchengine vindt dat jij dod ipv dood bedoelde

Stemming zal in de meeste gevallen meer en betere zoekresultaten opleveren dan gewoon domweg alle woorden maar opslaan, daarnaast scheelt het natuurlijk ook in de grootte van de zoekdb (en daardoor gelijk ook in de snelheid).

[chem]

quote: http://www.google.com/services/silver_gold.html

USD$599 monthly fee, USD$10 CPM beyond 1 million queries per year

En de hosted versie zal daar niet veel van verschillen.

[ACM]

Oei en sinds 5 december 22:29:58 zijn er zo'n 17000 requests op de omega-zoekert geweest, gaat duur worden als we dat zouden nemen

Ik ben me ervan bewust dat browsen in een resultaat set ook een query is hoor maar het openen van de zoekpage (zonder query) is hierbij niet mee geteld, maar dat zal bij google ook wel gelden.

[Booster]

ACM schreef op 08 december 2002 @ 15:36:
En wat is je probleem nou dan

Dat de search niet zoekt op wat ik exact wil zoeken?

Verder voegt hij een punt toe aan het eind van de zoekstring lijkt het, daar heb ik ook niet om gevraagt. En de omega zoekmachine in het algemeen gaf nogal eens wat errors, die ik op dit moment even niet gerepliceerd krijg.
Als ik die weer vind dan zet ik ze wel ergens neer.

Hetzelfde stemmings-algoritme wordt natuurlijk ook bij de opslag gebruikt, dus nbase zal niet in de zoek-db staan, nbas wel...

Ik vind het stemmen heel aardig bedacht maar imho is het een beetje het 'hoi ik ben de search en ik weet het beter als jij' principe.

Als ik zoek op een tekst dan zoek ik ook op DIE tekst en niet op iets wat een zoekmachine mij gaat aanraden. Als ik daarop wil zoeken dan voer ik dat wel zelf in.
Zelf zoek ik vaak op dingen waarvan ik al weet hoe ze omgeschreven worden. Bv, je hebt 'ooit' eens 'ergens' een bepaalde zin gelezen en je wilt weten waar dat was.

Dan voer ik bv bij een zoekmachine in: +"met de woorden zoals ik ze me herriner". Ik zoek dus veel gerichter en daar lijkt het stem-algoritme mij totaal niet in te begrijpen.

Ik kan er prima in komen dat dat stemmen een aardige oplossing is tov andere mogelijkheden, maar ik vind het gewoon niks.

[ Voor 3% gewijzigd door Booster op 09-12-2002 20:15 ]

[SambalBij]

ACM schreef op 09 december 2002 @ 16:45:
Wat is nou je probleem? Vind je niet de goede dingen door de stemming? Of ben je gewoon beledigd dat de searchengine vindt dat jij dod ipv dood bedoelde

Voornamelijk het laatste...
Als er iets is waar ik me soms heel erg aan kan irriteren dan is het als software intelligent probeert te doen, terwijl ik daar helemaal niet om vraag.
Ik heb dan zoiets van als ik 'dood' intik, zoek dan ook op 'dood' en niet op 'dod'. Had ik op 'dod' willen zoeken dan had ik wel 'dod' ingetikt nietwaar

Het gaat voor de rest ook helemaal nergens om, over het algemeen werkt die search prima namelijk

[ACM]

Booster schreef op 09 december 2002 @ 20:15:
Dat de search niet zoekt op wat ik exact wil zoeken?

De search moet vinden wat jij wilt dat ie vind, ben ik volledig met je eens.
Maar imho mag ie daarvoor elke willekeurige truc toepassen om datgene te vinden dat jij wilt dat ie vind. Dus bijvoorbeeld het stemmen, maar ook handige manieren van sorteren (op "score" bijv), helaas is de omega-engine niet zo geschikt om andere manieren van sorteren te gebruiken, hoewel het wel kan en moet kunnen (kweet niet hoe, nooit getest).

Verder voegt hij een punt toe aan het eind van de zoekstring lijkt het, daar heb ik ook niet om gevraagt

Nee hoor, die staat in de template punten worden sowieso genegeerd.

En de omega zoekmachine in het algemeen gaf nogal eens wat errors, die ik op dit moment even niet gerepliceerd krijg.
Als ik die weer vind dan zet ik ze wel ergens neer.

Ja, ik kon ze ook niet meer vinden, een hele tijd was de string "split array" of "help ietsanders" er eentje waarmee je een error kreeg, maar nu niet meer. Het gekke is alleen dat ik niks gewijzigd heb... Behalve dat ie rustig aan door is gaan indexeren elke nacht.

Ik vind het stemmen heel aardig bedacht maar imho is het een beetje het 'hoi ik ben de search en ik weet het beter als jij' principe.

Ik vind dat wel meevallen, sterker nog, als ik de originele zoekstring zou weergeven via de template had je het nooit geweten en had je er ook nooit last van gehad, of wel?
Zou je dan niet vinden wat je wilt vinden? (en dus niet "op laten zoeken waar je op laat zoeken")
Het zou me verbazen als google, altavista en yahoo geen stemming gebruiken trouwens, alhoewel ze natuurlijk dan wel een minstens 10x zo goed algoritme gebruiken.

Als ik zoek op een tekst dan zoek ik ook op DIE tekst en niet op iets wat een zoekmachine mij gaat aanraden. Als ik daarop wil zoeken dan voer ik dat wel zelf in.
Zelf zoek ik vaak op dingen waarvan ik al weet hoe ze omgeschreven worden. Bv, je hebt 'ooit' eens 'ergens' een bepaalde zin gelezen en je wilt weten waar dat was.

Daar is de NEAR functionaliteit voor, aangezien dat verder vrij weinig gebruikt zou worden (denk ik, met gewoon zoeken vind je het meestal ook wel als het er is) en het niet in de basis templates zat heb ik er weinig aandacht aan besteed. Daarmee zoek je dus eigenlijk op strings van woorden (ook al maakt ie er dan alsnog de gestemde versies van)
Er wordt overigens (bij mijn weten) standaard wel al de voorkeur gegeven aan woorden die dicht bij elkaar zijn dan verder uit elkaar staan.

Dan voer ik bv bij een zoekmachine in: +"met de woorden zoals ik ze me herriner". Ik zoek dus veel gerichter en daar lijkt het stem-algoritme mij totaal niet in te begrijpen.

De meeste searches zijn niet gericht denk ik, maar om "informatie te vinden" en dan is het juist nuttig als er wat intelligenter gezocht wordt (als je naar informatie over een dode man in 1970 zoekt wat je ooit voorbij hebt zien komen, dan zoek je bijv op "dode man 1970", maar stel dat er in het topic stond 'een man is dood, hier in 1970' dan zou je dat met een exacte search nooit gevonden hebben, met de gestemde search wel.

Ik kan er prima in komen dat dat stemmen een aardige oplossing is tov andere mogelijkheden, maar ik vind het gewoon niks.

Alleen bij gericht zoeken is het iets dat je tegen kan werken denk ik, volgens mij is er niemand die niet vindt wat ie wil vinden daardoor??

Operations schreef op 09 december 2002 @ 23:59:
Als er iets is waar ik me soms heel erg aan kan irriteren dan is het als software intelligent probeert te doen, terwijl ik daar helemaal niet om vraag.

Anderzijds heeft die software natuurlijk wel een veel betere kennis van wat ie zoal opgeslagen heeft en van wat ie geindexeerd heeft, of hoe het indexeren in zijn werk gaat...
Met die kennis kan ie jou nuttig van dienst zijn.

Ik heb dan zoiets van als ik 'dood' intik, zoek dan ook op 'dood' en niet op 'dod'. Had ik op 'dod' willen zoeken dan had ik wel 'dod' ingetikt nietwaar

Klopt, maar je had natuurlijk ook op 'dood', 'dode' of 'doden' (meervoud) hebben kunnen willen zoeken. Zoals gezegd, bij een exacte search is dat wat onhandig wellicht, maar bij een "zoektocht naar informatie" waarschijnlijk alleen maar handig.

[disjfa]

ok ik moet gewoon ff wat kwijt

ff simpel stellen ik post in de hk maar vaak wil ik ook gewoon wat weten. dat wil ik opzoeken enzo. daarvoor klik ok de omega search aan en ik heb persoonlijk nog nooit problemen gevonden daarmee om makkelijk te stellen..... hij roeleerd.

ik ken de namen die ik nodig heb bij zoekopdrachten en als ik die gebruik dan krijg ik elke keer weer een mooi lijstje met dat ie alles heeft gevonden ik ben blij met diegene die dei heeft gemaakt en als ik jullie was zou ik die gewoon onder t knopje zoeken zetten

een aanmerking alleen.... als je zoekt. zet het zoekscherm onderaan de pagina. dan wet je dat je wat hebt gevonden enzo ipv bij een resolutie van 1024 iig een scherm naar beneden scrollen en dan pas iets zien (is gebruikersvriendelijk enzo )

[Booster]

Even reageren, alhoewel ik denk dat we nog redelijk op 1 lijn zitten.

ACM schreef op 10 December 2002 @ 00:23:
Maar imho mag ie daarvoor elke willekeurige truc toepassen om datgene te vinden dat jij wilt dat ie vind. Dus bijvoorbeeld het stemmen, maar ook handige manieren van sorteren (op "score" bijv), helaas is de omega-engine niet zo geschikt om andere manieren van sorteren te gebruiken, hoewel het wel kan en moet kunnen (kweet niet hoe, nooit getest).

Agreed. Ik heb zeker graag dat alles uit de kast getrokken wordt om te vinden wat ik zoek, maar dan zou mijn volgende punt toch de 'presentatie' van die gegevens zijn. Een resultaten die een zoekmachine geeft moeten mij 'logisch' over komen, anders krijg ik al snel het idee dat de zoekmachine met iets anders bezig is dan 'alles uit de kast trekken'.

Nee hoor, die staat in de template punten worden sowieso genegeerd.

Ok, het viel mij op, en ik was bang dat ik daardoor weer een paar zoekresultaten ernaast liep.

Ja, ik kon ze ook niet meer vinden, een hele tijd was de string "split array" of "help ietsanders" er eentje waarmee je een error kreeg, maar nu niet meer. Het gekke is alleen dat ik niks gewijzigd heb... Behalve dat ie rustig aan door is gaan indexeren elke nacht.

De errors die ik kreeg hadden te maken met EOF-dingetjes geloof ik, dit lijkt dus wel te kloppen met wat jij zegt over spontaan verdwenen bugs door een completere index. Op dat moment was de error bijzonder frustrerend omdat ik toch echt op zoek was naar iets relatief simpels.

Ik vind dat wel meevallen, sterker nog, als ik de originele zoekstring zou weergeven via de template had je het nooit geweten en had je er ook nooit last van gehad, of wel?

Ik denk vrij serieus dat ik het wel gemerkt had. Misschien komt dat omdat ik soms een beetje een neus lijk te hebben voor dergelijke dingetjes. De gemiddelde gebruiker had er waarschijnlijk inderdaad niets van gemerkt.

Zou je dan niet vinden wat je wilt vinden? (en dus niet "op laten zoeken waar je op laat zoeken")
Het zou me verbazen als google, altavista en yahoo geen stemming gebruiken trouwens, alhoewel ze natuurlijk dan wel een minstens 10x zo goed algoritme gebruiken.

Ik verwacht in de meeste gevallen wel te vinden wat ik zoek, maar niet op de plek waar ik het zou verwachten. Net of de logischere threads wat verder onderaan de resultaten staan.

Van de zoekmachines die jij noemt doet Google het bij mij zeker het beste, omdat hij voornamelijk echt vaak exact de dingen vind die ik zoek. Ik weet meestal al een vrij duidelijke richting of weet hoe men iets verwoord zou hebben en daarop zoeken scheelt echt. (ik zoek denk ik 70% met strings ipv losse woorden)
In principe zouden mensen ook stukken gebaat zijn bij een cursus 'hoe ga ik om met de search' Ik bedoel, ik krijg geregeld info uit zoekmachines die voor anderen blijft liggen en dat zie je gewoon aan de manier die mensen gebruiken om te zoeken.

Daar is de NEAR functionaliteit voor, [cut]
Er wordt overigens (bij mijn weten) standaard wel al de voorkeur gegeven aan woorden die dicht bij elkaar zijn dan verder uit elkaar staan.

Ok, begrijp me niet verkeerd: ik denk zeker dat de omega engine een erg aardig idee bevat voor een searchengine, maar het lijkt er dan toch op dat hij me niet helemaal lekker ligt.
Mogelijk ben ik gewoon verwent

De meeste searches zijn niet gericht denk ik, maar om "informatie te vinden" en dan is het juist nuttig als er wat intelligenter gezocht wordt (als je naar informatie over een dode man in 1970 zoekt wat je ooit voorbij hebt zien komen, dan zoek je bijv op "dode man 1970", maar stel dat er in het topic stond 'een man is dood, hier in 1970' dan zou je dat met een exacte search nooit gevonden hebben, met de gestemde search wel.

Agreed. Toch ben ik (en jij ook als ik het goed begrepen heb) van mening dat dit intelligente zoeken niet moet ophouden bij de stem-methode.

Het is jammer dat ik zo even snel niet echt manieren zie waarop dat makkelijk beide opties aangeboden kunnen worden. Dus een vinkje 'intelligent' of 'flat'.

Alleen bij gericht zoeken is het iets dat je tegen kan werken denk ik, volgens mij is er niemand die niet vindt wat ie wil vinden daardoor??

Ok, ik trek die woorden overigens in, en zal ze zelfs min of meer omkeren: ik vind stemmen een heel aardige methode om te vinden wat je zoekt, mits 'logisch' gepresenteerd.

Mijn gebruiksmanier van zoeken is misschien gewoon lastig zomaar te integreren in een zoekmachine en dat helpt niet mee.

[ACM]

Booster schreef op 10 december 2002 @ 12:19:
Even reageren, alhoewel ik denk dat we nog redelijk op 1 lijn zitten.

Volgens mij ook wel

De errors die ik kreeg hadden te maken met EOF-dingetjes geloof ik, dit lijkt dus wel te kloppen met wat jij zegt over spontaan verdwenen bugs door een completere index. Op dat moment was de error bijzonder frustrerend omdat ik toch echt op zoek was naar iets relatief simpels.

Dat lijkt me dat we het over het zelfde hadden, erg vervelende (exception: blabla stond er dan) dingen
Ben blij dat ze weg zijn, alhoewel ik niet snap waarom

Ik verwacht in de meeste gevallen wel te vinden wat ik zoek, maar niet op de plek waar ik het zou verwachten. Net of de logischere threads wat verder onderaan de resultaten staan.

Het blijft natuurlijk een sortering van een algoritme, die kan nooit zo goed (wel tig keer sneller) sorteren als een mens.

Van de zoekmachines die jij noemt doet Google het bij mij zeker het beste, omdat hij voornamelijk echt vaak exact de dingen vind die ik zoek.

Idd, google wordt ook vaak wel een van de beste engines op het web genoemd, hun software is dan ook wel een heel stuk complexer dan omega (en dus helemaal dan react's zoekdingetje). Het scheelt natuurlijk wel dat google ondertussen geld verdient met hun service en ze dus de boel steeds verder kunnen verbeteren. Terwijl omega een opensource project is met een klein bedrijfje erachter.

In principe zouden mensen ook stukken gebaat zijn bij een cursus 'hoe ga ik om met de search' Ik bedoel, ik krijg geregeld info uit zoekmachines die voor anderen blijft liggen en dat zie je gewoon aan de manier die mensen gebruiken om te zoeken.

Dat weet ik wel zeker

Mogelijk ben ik gewoon verwent

Je bent gewoon te kritisch

Agreed. Toch ben ik (en jij ook als ik het goed begrepen heb) van mening dat dit intelligente zoeken niet moet ophouden bij de stem-methode.

Nee absoluut niet, stemming is alleen maar een manier om wat meer resultaten (die dicht bij elkaar liggen wat inhoud betreft, als het goed is) te vergaren. De sortering op relevantie etc is weer een heel ander verhaal.

Het is jammer dat ik zo even snel niet echt manieren zie waarop dat makkelijk beide opties aangeboden kunnen worden. Dus een vinkje 'intelligent' of 'flat'.

Stemming zit in de zoekdatabase verwerkt wat opslag betreft. Er komt dus ook werkelijk geen woord meer voor als 'dood', 'doden' of 'dode' (om het vrij lugubere voorbeeld er maar weer bij te pakken) overal waar dat voorkwam werd 'dod' weggeschreven. Dat maakt voor de zoekdb over het algemeen niet zo veel uit (behalve met de gegeven voorbeelden ) aangezien je er toch niet de inhoud van gebruikt voor andere dingen dan zoeken.

Ok, ik trek die woorden overigens in, en zal ze zelfs min of meer omkeren: ik vind stemmen een heel aardige methode om te vinden wat je zoekt, mits 'logisch' gepresenteerd.

Mijn gebruiksmanier van zoeken is misschien gewoon lastig zomaar te integreren in een zoekmachine en dat helpt niet mee.

Ach, dat hoeft ook niet hoor
Je bent gewoon vrij kritisch en die gebruikers zijn ook nodig, vaak zijn dat de mensen waardoor dingen verbeterd worden

Overigens heeft de nieuwste (nog niet helemaal stable) versie van omega een betere stemmer en ik zal dan weer eens kijken of ik de sortering wat beter kan maken (door die NEAR-sortering toe te passen, indien mogelijk en nodig).

[ Voor 5% gewijzigd door ACM op 10-12-2002 12:39 ]

[Booster]

Zoals je al aangeeft zal de sortering van een algoritme niet voor iedere mensch logisch blijken. Maar ik verwacht dat er nog best wat te tweaken is hier en daar zodat dingen ietsje logischer naar voren kunnen komen.

De vergelijking Google / Omega is natuurlijk niet helemaal 'correct', maar ik wilde voornamelijk benadrukken dat Google fijn is door zijn 'logica' in brengen en dat dit is wat ik vooral lijk te missen in Omega.
Met Omega en de normale search bij elkaar vind ik nogsteeds een hele hoop van wat ik nodig heb ik met omega zijn de resultaten vaak vrij goed op het gebied wat ik nodig heb. Het kost alleen wat meer moeite en een andere instelling van mij.

Ik probeer heel goed ook de technische kant van de search te begrijpen en dat vind ik best lastig, maar ik denk dat ik in ieder geval al prima kan zien waar de beperkingen liggen en weet in ieder geval dat het niet 'zomaar' aan de mensen ligt die eraan werken
Dus ik kan er prima begrip voor op brengen als de search wat minder werkt dan ik gewend ben.

En wat betreft het brengen van kritiek denk ik nogsteeds dat ook hier de 'presentatie' een hoop doet, en ik kan me toevallig nog wat mensen herrineren die hun kritiek hier wat minder verteerbaar brachten

Verder ben ik zeer benieuwd naar wat voor veranderingetjes er in de toekomst gaan plaatsvinden bij Omega en in hoeverre dat die echt tot betere / logischere zoekresultaten gaan leiden
(suc6!)

[CTVirus]

Ik heb zelf ook vaak problemen met de zoekmachine, errors als max execution time expired, max memory reached (8 mb per request). (ik zal de exacte fouten een keer opslaan),

Zou het niet makkelijk zijn om fouten die de zoekmachine geeft op te slaan. Ik beheer zelf een intranet, waarbij ik elke ochtend kijk of er mensen of code nog fouten heb veroorzaakt. Doordat ik ook netjes alle get en post informatie opsla. Kan ik de problemen vaak vrij makkelijk oplossen.

[Glabbeek]

Aangezien Arethusa het op dit moment al (een poosje) niet doet is de Omega-search ook niet bereikbaar. Deze linkt (in ieder geval vanuit de search-page) namelijk naar die server.

Is het bekend of Adonis deze taak snel overneemt (tenminste, dat begrijp ik uit deze .plan) of is de Omega-seach eventueel nu al op een ander URL bereikbaar?

Nu hoop ik niet dat deze vraag al eerder gesteld is, maar ik kon het niet in een MED vinden en zoeken lukt natuurlijk niet echt

[ Voor 1% gewijzigd door Glabbeek op 10-12-2002 21:14 . Reden: Typo's ]

[MSalters]

ACM schreef op 08 december 2002 @ 16:59:
[nohtml]
[...]

Ter illustratie trouwens; een query die, imho, redelijk gelijk is aan het zoeken.

code:

mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb, F_Messages mc, F_Messages md WHERE ma.TopicID = t.topicid
AND ma.userid = 3324 AND mb.topicid = t.topicid AND mb.userid = 2577 
AND mc.topicid = t.topicid AND mc.userid = 460 AND md.topicid = t.topicid 
AND md.userid = 59;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                         43 |
+----------------------------+
1 row in set (0.20 sec)
mysql> select count(distinct(t.topicid)) from F_Topics t, F_Messages ma, 
F_Messages mb, F_Messages mc, F_Messages md, F_Messages me WHERE 
ma.TopicID = t.topicid AND ma.userid = 3324 AND mb.topicid = t.topicid 
AND mb.userid = 2577 AND mc.topicid = t.topicid AND mc.userid = 460 
AND md.topicid = t.topicid AND md.userid = 59 AND me.topicid = t.topicid 
AND me.userid = 3275;
+----------------------------+
| count(distinct(t.topicid)) |
+----------------------------+
|                         29 |
+----------------------------+
1 row in set (1.24 sec)

Kortom, eerst 1 (alle unieke topics waar ik gereageerd heb tellen), dan 2 (alle unieke topics waar AntonT en ik reageerden), dan 3 (Anton, ik en Daniel), dan 4 (Anton, ik, Daniel en Kees) en 5 (Anton, ik, Daniel, Kees en Floris).

Opes, dat geeft aan dat de query-optimizer ernstig ongeschikt is voor dit soort search-queries. Een special-purpose search-query engine zal er nooit 1,04 seconden over doen om op 43 resultaten de extra restrictie "AND me.topicid = t.topicid AND me.userid = 3275" te doen. Je hebt logischerwijs een lijstje met 43 topic ids en een lijstje met 12839 topic ids. Om deze te intersecten doe je grofweg 43 binary searches in 12839 topic ids, dus O( 43*log(12389) ) ~= 500 operaties, dat zou in een milliseconde moeten.

_{move to /14?}

[ACM]

[nohtml]

Glabbeek schreef op 10 December 2002 @ 21:12:
Is het bekend of Adonis deze taak snel overneemt (tenminste, dat begrijp ik uit deze .plan) of is de Omega-seach eventueel nu al op een ander URL bereikbaar?

De harde schijf met de zoekdatabase (die niet kapot was) is ook over gezet naar de "nieuwe" arethusa, wat trouwens niet adonis is geworden.
Enige nadeel is dat ik omega opnieuw moet compileren (en daarvoor de backend-library xapian en daar weer voor gcc-3.2)

Hoe snel het online is weet ik niet, ik hoop toch echt vandaag wel.

MSalters schreef op 11 December 2002 @ 02:08:

Klopt allemaal, maar je snapt nu iig waarom mysql het niet zo goed doet in onze ogen voor de searchengine
MySQL heeft zodra de queries "complex worden" al gauw moeite er mee en zal wat sneller het onderspit delven tov bijv postgresql. Alhoewel ik niet weet en getest heb hoe goed die het er vanaf brengt (*sets reminder* )

_{move to /14?}

Hehe, nah, als je hier graag op een echt technisch niveau over wilt discussieren kunnen we altijd nog een ander topic in P&W openen.

[ACM]

Booster schreef op 10 december 2002 @ 12:19:
Ik weet meestal al een vrij duidelijke richting of weet hoe men iets verwoord zou hebben en daarop zoeken scheelt echt. (ik zoek denk ik 70% met strings ipv losse woorden)
In principe zouden mensen ook stukken gebaat zijn bij een cursus 'hoe ga ik om met de search' Ik bedoel, ik krijg geregeld info uit zoekmachines die voor anderen blijft liggen en dat zie je gewoon aan de manier die mensen gebruiken om te zoeken.

Btw... Ik ontdek net dat er al gewoon phrase-search support inzit
"zoek string dinges" laat omega zoeken op PHRASE basis.
(hij maakt er eerst wel losse zoekwoorden van, maar zoekt toch op woorden bij elkaar)

Trouwens ook near-support:
iets NEAR ietsanders zou een voorkeur geven aan de topics waar iets vlakbij ietsanders staat.

Overigens zijn complexe queries ("(iets OR ietsanders) AND bla") ook mogelijk. Net als het gebruik van de + en - modifiers (wel er in, niet erin).

Grootste nadeel van de phrase en near-queries is trouwens wel dat ze vrij traag (kunnen) zijn.

[ Voor 5% gewijzigd door ACM op 11-12-2002 16:40 ]

[Makkelijk]

Fijn trouwens dat omega nou ook al van geen kant meer werkt sinds paar daagjes!

[ACM]

Fijn dat mensen die zo hard klagen nooit vertellen wat er van geen kant werkt of waardoor ze vinden dat het van geen kant werkt...

[ZaZ]

Ik heb sinds een paar dagen dat als ik op de omega search klik er helemaal niks gebeurt, weet niet wat het is........
en de andere search levert haast altijd een error op (zelfs met 1 woord)

[Erkens]

ZaZ schreef op 12 december 2002 @ 10:46:
Ik heb sinds een paar dagen dat als ik op de omega search klik er helemaal niks gebeurt, weet niet wat het is........
en de andere search levert haast altijd een error op (zelfs met 1 woord)

dat kwam door dat Arethusa het niet deed

[Attilla]

Is het niet mogelijk dat in het search scherm de react search door de omega wordt vervangen ?

Ik merk namelijk nog bij veel mensen dat ze niet weten dat ze die moeten gebruiken en aangezien de omega search toch wel beter werkt lijkt het mij geen probleem.

[Justice]

In principe zouden mensen ook stukken gebaat zijn bij een cursus 'hoe ga ik om met de search' Ik bedoel, ik krijg geregeld info uit zoekmachines die voor anderen blijft liggen en dat zie je gewoon aan de manier die mensen gebruiken om te zoeken.

Je kan het zo zien maar je kan het natuurlijk ook anders zien. De search sluit blijkbaar niet aan op het model wat VEEL mensen van de search hebben, dus ze zoeken verkeerd, en vinden dus niet wat ze zoeken.

Dan kan je dus VEEL mensen een cursus zoeken proberen aan te praten met de kans dat 50% er tijd voor heeft en iets beter gaat zoeken, en 20% die daadwerkelijk goed zoekt. Of je kan de userinterface en de manier van zoeken zo proggen dat hij aansluit bij VEEL mensen, met het gevolg dat VEEL mensen goed kunnen zoeken, enkele 'zoekexperts' opnieuw moeten leren zoeken, maar die hebben meer ervaring met verschillende omgevingen dus switchen makkelijker. Dit is trouwens wel een universeel probleem met search engines, dus echt aanrekenen kan ik het je niet

* Justice vindt bijna altijd wat hij zoekt, en zo niet kan er nooit iemand een antwoord geven op zijn problemen .

[ACM]

.

[GraasGast]

kan dat stemming-probleem niet verholpen worden door woorden selectief uit te sluiten van stemming door ze bv tussen aanhalingstekens te zetten (alla google)

bode > bod
"bode" > bode

nbase > nbas
"nbase" > nbase

Zo kan je toch zoeken op woorden die fout gaan...

[iets]

De search kan geen exacte woordenstring vinden IMHO. C/P een willekeurige woordenstring uit dit topic en de search zal het gegarandeerd niet terug vinden.

[ACM]

GraasGast schreef op 13 December 2002 @ 23:01:
kan dat stemming-probleem niet verholpen worden door woorden selectief uit te sluiten van stemming door ze bv tussen aanhalingstekens te zetten (alla google)

Geef mij eens een goede uitleg van "het probleem"
Ik heb er nog geen een gezien...

bode > bod
"bode" > bode

nbase > nbas
"nbase" > nbase

Zo kan je toch zoeken op woorden die fout gaan...

Ja, maar als ze niet opgeslagen worden op die manier, dan zul je ze nooit vinden als je de ongestemde versie erin propt.
Btw, als je het graag wilt proberen, plak er een punt achter in de omega-zoekert "bode." stemmed niet (zonder ", de punt wordt intern verwijdert als het goed is) en vindt ook gelijk 0 resultaat simpelweg omdat dat nergens zo opgeslagen is...

ShotGun schreef op 14 December 2002 @ 04:19:
De search kan geen exacte woordenstring vinden IMHO. C/P een willekeurige woordenstring uit dit topic en de search zal het gegarandeerd niet terug vinden.

Vreemd dan dat ik het wel werkend getest en gezien heb
Het is, helaas, wel _erg_ sloom en hoe langer de string is, hoe langer het zal duren natuurlijk.

Maar goed om het tegendeel te bewijzen:
"Dat de search slecht werkt weet inderdaad iedereen" als zoekstring (tweede regel van de startpost) levert als resultaat alleen dit topic op...

Nou jij weer

(ik heb het over de omega search he?)

[Verwijderd]

Zal wel een domme vraag zijn, maar weet iemand hoe ik in godsnaam GBA topics kan vinden? Alles wat ik probeer ( GBA of [GBA] ) levert 0 hits op, terwijl die topics er toch echt wel zijn. Is er een alternatief voor mijn zoekopdracht?

[ludo]

Verwijderd schreef op 15 december 2002 @ 16:33:
Zal wel een domme vraag zijn, maar weet iemand hoe ik in godsnaam GBA topics kan vinden? Alles wat ik probeer ( GBA of [GBA] ) levert 0 hits op, terwijl die topics er toch echt wel zijn. Is er een alternatief voor mijn zoekopdracht?

http://arethusa.tweakers.net/~acm/omega/omega geeft bij mij wel wat results hoor

[Verwijderd]

eRR: gebruik de Omega search engine ... zie de link in de linker bovenhoek van het serach scherm. Jammer dat je niet eerst het topic goed leest voordat je een vraag stelt.

[bitflusher]

de search is trouwens erg fan van: Custom Tweakers Case Building Take 3
zoek maar op:
php
domein
ben er nog een paar tegen gekomen.

maar zonder dollen wanneer zal er weer een fatsoenlijke search zijn (ruwe schatting)

tot die tijd zal zich een nieuwe trend zich ontwikkelen:
"ik heb gezocht met search maar heb nix gevonden dus roep geen UTFS <probleem>"

reactie: UTFOS =Use The Fucking Omega Search

[leuk_he]

Hoe moet je eingelijk omgaan met als je iets van een video kaart zoekt (strepen op beeld, kan hem niet in interlaced mode zetten bla bla) en de seach levert 2 hit op: allebei een topic die uit 50 pagina's bestaat. Hoe vind je dan de goede pagina?

Hoe is zondermeer door die hele grote topics heen te lezen. (GOT wordt druk!)

[oZy]

ze hadden de 255 posts per thread limit nooit weg moeten doen imho. er zijn topics bij die je bij nagenoeg alle queries als resultaat terug krijgt, van die leuke draadjes met 2000 posts (how 2 become a dj, en dat tweaktown topic krijg ik bijv heel vaak voor mn neus)

[D-Three]

leuk_he schreef op 17 december 2002 @ 17:47:
Hoe moet je eingelijk omgaan met als je iets van een video kaart zoekt (strepen op beeld, kan hem niet in interlaced mode zetten bla bla) en de seach levert 2 hit op: allebei een topic die uit 50 pagina's bestaat. Hoe vind je dan de goede pagina?

Hoe is zondermeer door die hele grote topics heen te lezen. (GOT wordt druk!)

oZy schreef op 18 December 2002 @ 15:07:
ze hadden de 255 posts per thread limit nooit weg moeten doen imho. er zijn topics bij die je bij nagenoeg alle queries als resultaat terug krijgt, van die leuke draadjes met 2000 posts (how 2 become a dj, en dat tweaktown topic krijg ik bijv heel vaak voor mn neus)

Sorry dat ik hier zo nog ff die boel naar omhoog kick maar het bovenstaande vind ik eerlijk gezegd soms ook nogal vervelend.
Een leuke oplossing zou zijn dat er vermeld staat in welke posts (welke pagina's?) de gevonden woorden staan. Maar dat lijkt me niet onmiddellijk gemakkelijk, vrees ik.
Nog eens zoeken in de gevonden resultaten zou ook een mogelijke oplossing kunnen zijn. Maar volgens mij is dat eigenlijk niet meer dan "de eerste zoekstring AND de twee zoekstring", dus echt goed vind ik dat nu ook weer niet.

Nu ja, eerlijk gezegd vind ik Omega wel goed, je krijg heel veel hits (soms wat teveel door dat stemmen ). Wat ik enkel mis is zoeken op titel, inhoud of combinatie (AND/OR) en rangschikken op datum.

[JvS]

jajaja, dat komt allemaal nog.

Dat je grote topics krijgt met de normale search komt omdat grote topics gewoon ronduit kut voor het gebruik van het forum is. Ik kan over mijn radeonprobleem ook niets vinden en ik kan daar dan ook gewoon een topic over starten,als ik maar duidelijk aangeef wat ik al geprobeerd heb.

(ow en de react search is niet echt optimaal) .

De search helemaal omgooien is niet de oplossing, je zegt dat het makkelijk is, maar de search houdt helemaal niet alle posts bij en gaat al helemaal niet alle posts in een topic stuk voor stuk uitpluizen hoor...Zoeken op post gaat dus ook lang niet zo makkelijk werken. Daarnaast wordt een topic veel beter gevonden door een combinatie van trefwoorden die vaak niet eens in een enkel topic staan...

[ Voor 44% gewijzigd door JvS op 04-01-2003 10:40 ]

[D-Three]

JvS schreef op 04 January 2003 @ 10:39:
De search helemaal omgooien is niet de oplossing, je zegt dat het makkelijk is, maar de search houdt helemaal niet alle posts bij en gaat al helemaal niet alle posts in een topic stuk voor stuk uitpluizen hoor...

Heb ik toch ook niet gezegd?
Al moet ik toegeven dat mijn zinsbouw niet echt optimaal is :

Laagvliegerke schreef op 04 January 2003 @ 10:37:
Maar dat lijkt me niet onmiddellijk gemakkelijk, vrees ik.

JvS schreef op 04 January 2003 @ 10:39:
Daarnaast wordt een topic veel beter gevonden door een combinatie van trefwoorden die vaak niet eens in een enkel topic staan...

Weet ik. Maar soms kan het wel handig zijn Ik vind het echter niet vervelend hoor, zeker nu die Omega redelijk goed werkt

[JvS]

ik denk dat het beter is, als gewoon alles in losse topics komt te staan, er zijn maar een paar onderwerpen die in grote topics staan en die je ook wil terugzoeken (met als radeontopic op #1 in mijn ogen).

[Verwijderd]

Okay, als ik wat zoek dan krijg ik als result bijvoorbeeld een topic met 60 pagina's.

Kan de link van de search dan naar de juiste pagina en juiste topic springen (daar waar mijn search iets gevonden heeft) i.p.v. naar de 1e pagina van die topic.

[Erkens]

Verwijderd schreef op 06 januari 2003 @ 12:32:
Okay, als ik wat zoek dan krijg ik als result bijvoorbeeld een topic met 60 pagina's.

Kan de link van de search dan naar de juiste pagina en juiste topic springen (daar waar mijn search iets gevonden heeft) i.p.v. naar de 1e pagina van die topic.

lees deze draad o.a. nog eens goed door

[Verwijderd]

Erkens schreef op 06 januari 2003 @ 12:41:
[...]

lees deze draad o.a. nog eens goed door

Heb ik nu voor de 2e keer gedaan. Bovenstaande staat er volgens mij niet in, maar zou wel handig zijn

De stemming is iig hopeloos, dat klopt. Als ik bijvoorbeeld zoek naar computer arts (het tijdschrift) maakt hij er computer art van Ook "computer arts" komt er niet doorheen... Oftwel, de search is in dit geval weer comleet nutteloos!

[ACM]

gadverdamme...
LEES DE DRAAD VOOR JE BLAAT!!!

sow, dat is eruit.
Het staat er WEL in, want ik heb het hier ZELF getikt.

(dit ging iig over de stemming )
Over paginering: Dat wordt niet opgeslagen omdat dat niet op te slaan is, is wel al tig keer uitgelegd maar blijkbaar niet in deze draad.

't is iig vaak genoeg voorbij gekomen om te kunnen vinden:
Zie de zoek

[ Voor 78% gewijzigd door ACM op 06-01-2003 13:05 ]

[Verwijderd]

Jaaaaaaaa, jij blaat te snel dus! Als je mijn eerste reactie in deze topic goed gelezen had, zag je dat die over de paginering ging hoor...

Wel raar, alle replies op een topic hebben toch een eigen id-tje? Dat is één extra linkje...

[Erkens]

Verwijderd schreef op 06 januari 2003 @ 13:08:
Jaaaaaaaa, jij blaat te snel dus! Als je mijn eerste reactie in deze topic goed gelezen had, zag je dat die over de paginering ging hoor...

Wel raar, alle replies op een topic hebben toch een eigen id-tje? Dat is één extra linkje...

mja, het wordt toch niet opgeslagen welk woord in welk topic staat dus wat heb je aan zo'n id

[Verwijderd]

Pffff raar allemaal!

Hier dan 3 tips voor de nieuwe search:

1. dat stemming moet absoluut kunnen worden overruled (door bijv. iets tussen quotes te typen ofsow?)

2. spring a.u.b. na een search naar de betreffende reply/pagina in een gevonden topic

3. maak een aanvinkdingetje zodat je (of in ieder geval de topicposter) kan subscriben op een (je) topic. Dus dat je kan kiezen of je wel of niet een mailtje wilt ontvangen wanneer iemand iets aan een topic heeft toegevoegd.

Okay, keep up the good work!

[ Voor 5% gewijzigd door Verwijderd op 06-01-2003 13:35 ]

[ThaDaNo]

Dat zijn hier bookmarks hoor

[blackd]

Verwijderd schreef op 06 januari 2003 @ 13:33:
2. spring a.u.b. na een search naar de betreffende reply/pagina in een gevonden topic

Kan dus niet.

3. maak een aanvinkdingetje zodat je (of in ieder geval de topicposter) kan subscriben op een (je) topic. Dus dat je kan kiezen of je wel of niet een mailtje wilt ontvangen wanneer iemand iets aan een topic heeft toegevoegd.

Heeft niets met search te maken. Maar deze feature is er al en staat uit anders wordt de load op de servers wel erg hoog met al die mails.

[Verwijderd]

Snorkeldude, allemaal goed bedoeld, maar zoekmachines zitten nou niet echt heel erg makkelijk in elkaar en zeker niet als ze door een gigantische berg aan data moeten zoeken. Hetgeen jij voorstelt als 2e punt is niet zomaar even binnen een paar tellen te bouwen en dan ook nog eens zodanig dat het snel is.

[ACM]

Verwijderd schreef op 06 januari 2003 @ 13:33:
Hier dan 3 tips voor de nieuwe search:

1. dat stemming moet absoluut kunnen worden overruled (door bijv. iets tussen quotes te typen ofsow?)

Plak een punt achter je zoekwoord (dus "arts.")... Het heeft geen zin, want het vindt niks, want de stemming wordt ook gebruikt bij het opslaan, magoed je kan het best overrulen hoor
Je zoekt nou eenmaal op het woord "art" (kunst) en eventueel de meervoudsvorm ervan ("arts", kunsten).

2. spring a.u.b. na een search naar de betreffende reply/pagina in een gevonden topic

Helaas, de huidige zoekdatabase is ~10GB, als je de data zo op gaat slaan dat je weet wat in welke posting stond (wat nodig is om te kunnen bepalen op welke pagina het stond) kom je makkelijk op de 30-50GB
En het ergste is dat je nog minder vind ook dan, want vaak staan de woorden verspreid over een topic ipv allemaal in 1 bericht.

3. maak een aanvinkdingetje zodat je (of in ieder geval de topicposter) kan subscriben op een (je) topic. Dus dat je kan kiezen of je wel of niet een mailtje wilt ontvangen wanneer iemand iets aan een topic heeft toegevoegd.

Okay, keep up the good work!

Daar kan je bookmarks voor gebruiken, en de functionaliteit is er wel in React, maar uitgeschakeld. Omgerekend worden er ergens tegen de 0.2 - 2 miljoen mailtjes per dag naar gebruikers gestuurd als je zoiets zou doen (of in geval je het alleen naar de topicstarter stuurt nog steeds makkelijk tienduizenden per dag) en dat willen we gewoon simpelweg niet...
Te veel data verkeer, te veel mailtjes (belasting op de servers schiet omhoog dan), te veel gedoe met mail dat niet aankomt etc.

[Splasher]

ACM schreef op 06 January 2003 @ 17:36:

[...]


[...]

Daar kan je bookmarks voor gebruiken, en de functionaliteit is er wel in React, maar uitgeschakeld. Omgerekend worden er ergens tegen de 0.2 - 2 miljoen mailtjes per dag naar gebruikers gestuurd als je zoiets zou doen (of in geval je het alleen naar de topicstarter stuurt nog steeds makkelijk tienduizenden per dag) en dat willen we gewoon simpelweg niet...
Te veel data verkeer, te veel mailtjes (belasting op de servers schiet omhoog dan), te veel gedoe met mail dat niet aankomt etc.

Hier voor heb je toch al een handig progie zoals HotTopic... en zo zijn er nog wel een paar van die varianten geloof ik

En zoals je al zij kan je ook je bookmark gebruiken

[chem]

Er zijn idd zat tools om je topics bij te houden. We bieden hottopic xml files, native xml files van alle acties, RSS output, mozilla sidebars en bookmarks aan. Had je nog meer gewenst? Dan hebben we nog ICQ/email notifications in de aanbieding (staan uit, ik weet het), de Got Tracker van Crisp, de active topics, je eigen posthistory en straks OOK nog myReact.

En dan weet ik het echt niet meer hoor...

Nog iets anders over de 'stemming' van woorden: ik denk dat ik het gewoon niet laat zien in de nieuwe search, dan kan er ook niet over geklaagd worden

Dit gebeurt namelijk om je te HELPEN. Zoeken is en blijft een kunst, en als je stug volhoudt dat 'hij niet werkt' dan vind je idd nooit wat.

[ Voor 28% gewijzigd door chem op 06-01-2003 20:20 ]

[Verwijderd]

okay, okay

Maarre, als je nou kijkt naar "stemming". Feit is dat meerdere mensen (zie ook in dit topic) hier problemen door ondervinden. Dan kan je kan natuurlijk gaan zuchten en net zolang blijven zeggen dat het allemaal wel werkt, totdat er niemand meer reageert, maar daar los je het probleem niet mee op.

Ik begrijp natuurlijk dat het niet zo 1,2,3 gepiept is om een search te maken in een gigantische zooi data, maar de bezoekers geven hier gewoon hun bevindingen weer. Wanneer er iets raars wordt ontdekt en dat hier wordt gemeld dan is dat toch juist handig voor jullie? Het zijn maar suggesties, of in het ergste geval wat opbouwende kritiek...

Als je kijkt naar de voorbeelden nbase/bode/dood, dan kan je niet gewoon zeggen dat het wel werkt. En als ik dan lees dat de stemming is uit te zetten, dan zakt helemaal m'n broek af, doe dat dan totdat één en ander wel goed werkt

[ Voor 98% gewijzigd door Verwijderd op 07-01-2003 05:22 ]

[JvS]

Geef eens een voorbeeld waar die stemming je dusdanig in de weg zit, dat je niets kan vinden of alleen irrelevante zaken? En dan het liefst iets in de techfora, wat gewoon te vinden moet zijn. Ik ben wel benieuwd eigenlijk.

[ACM]

JvS schreef op 07 January 2003 @ 07:38:
Ik ben wel benieuwd eigenlijk.

Ik ook, want ik heb nog geen voorbeeld gezien waarbij het in de weg zat... Alleen maar van mensen die kotsten op dat zelfdenken van de searchengine.