[bug]search

[Vorkie]

Als ik in de search zoekt naar het trefwoord 5.1 dan geeft ie een fout dat de zoekopdracht langer heeft geduurt dan 15 seconden...

Ga ik dan alleen zoeken op mp3 of iets anders, dan doet hij het wel gewoon...??

Is dit een bekend probleem of niet??

[Hahn]

Je zult gewoon wat specifieker moeten zijn met je zoekopdrachten denk ik, als je '5.1' invult dan laat ie de punt weg en gaat ie dus alle resultaten af met een '5' en een '1' eraf en dat zijn er natuurlijk véél

Hmm, dat is niet helemaal waar, maar het eerste geldt wel: specifieker zijn

Dit staat trouwens in de searchmanual:

Omega herkent verschillende leestekens als samentreksels van phrases in de queries en negeert de leestekens ('vervangt' ze door spaties) tijdens het indexeren, te weten de " ", "-", ".", "_", "/", "\", "@", "'", "*".

Maar het rare hierbij is dat je op '5.1' geen resultaten krijgt (timeout), maar op '5 1' (los dus) wel

[ Voor 80% gewijzigd door Hahn op 14-03-2004 18:21 ]

[ACM]

ja, das niet zo gek.

Bij een phrase search moet ie veel meer werk doen dan bij dezelfde query met losse woorden. 't Is niet echt anders, we hebben met zijn alleen teveel tekst getikt in de got-db waardoor zeker veelvoorkomende woorden in een phrase search zeer veel tijd kosten.

Dus 5 1 -> zoek alle documenten waar 5 en 1 in zitten, 5.1 -> zoek in alle documenten waar 5 en 1 staat of ze bij elkaar staan. Bij de eerste stap beperkt het zich tot een database van zo'n 2GB, bij de 2e stap moet ie ineens nog een 2e tabel van ruim 6GB openen en doorworstelen. Niet alles eruit natuurlijk, maar je kan je voorstellen dat 5 en 1 veelgebruikte "termen" zijn, zoals je ook wel aan de resultaten kan zien "Woord frequenties: mp3: 28048, 5: 212481, 1: 414238" (hij combineert dus die 5 en 1 tot zo'n 100k resultaten ofzo die ie dan nog es uit moet gaan zitten pluizen).

Er is vast ruimte tot verbetering, maar dan moet er ook iemand zijn die dat kan en wil maken, voor zover het al echt mogelijk is

[Spider.007]

ACM schreef op 14 maart 2004 @ 19:39:
ja, das niet zo gek.

Bij een phrase search moet ie veel meer werk doen dan bij dezelfde query met losse woorden. 't Is niet echt anders, we hebben met zijn alleen teveel tekst getikt in de got-db waardoor zeker veelvoorkomende woorden in een phrase search zeer veel tijd kosten.

Dus 5 1 -> zoek alle documenten waar 5 en 1 in zitten, 5.1 -> zoek in alle documenten waar 5 en 1 staat of ze bij elkaar staan. Bij de eerste stap beperkt het zich tot een database van zo'n 2GB, bij de 2e stap moet ie ineens nog een 2e tabel van ruim 6GB openen en doorworstelen. Niet alles eruit natuurlijk, maar je kan je voorstellen dat 5 en 1 veelgebruikte "termen" zijn, zoals je ook wel aan de resultaten kan zien "Woord frequenties: mp3: 28048, 5: 212481, 1: 414238" (hij combineert dus die 5 en 1 tot zo'n 100k resultaten ofzo die ie dan nog es uit moet gaan zitten pluizen).

Er is vast ruimte tot verbetering, maar dan moet er ook iemand zijn die dat kan en wil maken, voor zover het al echt mogelijk is

Hmmm.. interessant verhaal Is er ooit wel eens gekeken naar technieken die bijvoorbeeld ook door Google worden gebruikt?

[P_de_B]

Google heeft een cluster van zo'n 10000 servers die het zoekwerk doen, ik denk dat je dat niet kunt vergelijken met de hardware van T.Net

[Hahn]

P_de_B schreef op 14 maart 2004 @ 20:21:
Google heeft een cluster van zo'n 10000 servers die het zoekwerk doen, ik denk dat je dat niet kunt vergelijken met de hardware van T.Net

Maar de hoeveelheid data die Google doorzoekt is ook niet te vergelijken met het 'beetje' die de GoTsearch doorzoekt

[ Voor 5% gewijzigd door Hahn op 14-03-2004 20:23 ]

[P_de_B]

December schreef op 14 maart 2004 @ 20:22:
[...]
Maar de hoeveelheid data die Google doorzoekt is ook niet te vergelijken met het 'beetje' die de GoTsearch doorzoekt

Tja, daar zit wat in natuurlijk

[ACM]

Spider.007 schreef op 14 maart 2004 @ 20:00:
Hmmm.. interessant verhaal Is er ooit wel eens gekeken naar technieken die bijvoorbeeld ook door Google worden gebruikt?

Ik heb vrij open-minded naar de google "appliance" gekeken, maar die biedt niet de flexibiliteit die wij hebben. Zowel niet in de mogelijkheden kwa queries als in de mogelijkheden kwa indexering (rechten er globaal in verwerken bijvoorbeeld).

Google is meer bruikbaar om voor een site te gebruiken waar maar 1 toegansrecht geldt (bijv een intranet of gewoon een publieke site) en dat hebben wij niet

Andere oplossingen dan Xapian zullen overigens ook stuklopen op de phrase-searches, maar die zouden het wellicht wel efficienter kunnen uitvoeren. Google heeft natuurlijk wel een vrij groot team van mensen die continue bezig is de software bij te werken en te verbeteren

[crisp]

zie ACM: NaB