Searchengine strategie

[Verwijderd]

Ik heb gisteravond even dit artikel over lucene gelezen, leuk artikel hoewel er niet echt ingegaan wordt op hoe het precies werkt.

Maar goed, ik bedacht ineens, waarom zou je je bestanden systeem eigenlijk niet als index gebruiken? Als je een document indexeert maakt hij gewoon een directory structuur aan:

lopen:
/l/o/p/e/n

slapen:
/s/l/a/p/e/n

sluipen:
/s/l/u/i/p/e/n

In die directory staan dan links naar documenten die dat woord matchen. Is dit zo'n raar idee? Zitten er grote nadelen aan? Misschien wordt het bestandensysteem erg belast?

Op zich lijkt het me wel makkelijk indexen maken en zoeken.
Iemand typt "slapen" in, de zoekmachine kijkt in de /s/l/a/p/e/n directory, bestaat hij, dan is het een match, zo niet, dan niet.

Het nadeel is natuurlijk wel dat je ontiegelijk veel directories en subdirectories krijgt. En in hoeverre dat een probleem is kan ik niet echt inschatten.

Ideeën?

[Janoz]

Wat je nu eigenlijk bedacht hebt is een boom structuur. Een gerichte graaf zonder cycles waar elke node maar 1 binnenkomende edge heeft en meerdere uitgaande (Als je er van uitgaat dat de richting naar de leafes is). Dat is in de informatica een erg bekend begrip, en dit is inderdaad 1 van de meest efficiente manieren om data te indexeren en terug te vinden (Imers, elk woord is op te halen in (het aantal letters) X (de tijd die het nodig is om 1 dir te kiezen uit ~26 dirs))

[Verwijderd]

Ja dat begrijp ik, maar is het bestanden systeem geschikt om zo'n index in te maken?

[jelmervos]

Ik heb op mijn school es een VB app gemaakt die continue directory's random aanmaakte. En dat ging heel lang goed, 30000 directory's is geen probleem.

Bij hoeveel het niet meer goed gaat weet ik niet, Windows wordt steeds trager.

[joepP]

Op donderdag 13 december 2001 10:59 schreef Zef het volgende:
Ja dat begrijp ik, maar is het bestanden systeem geschikt om zo'n index in te maken?

Niet echt denk ik.

Je kan je beter verdiepen in de algoritmes voor dit soort bomen, en die zelf implementeren. Zo moeilijk is dat niet. Het bestandssysteem heeft hele andere uitgangspunten, de efficientie is voor deze toepassing waarschijnlijk uitermate slecht.

[chem]

hangt er vanaf welk OS je gebruikt.

Wat iemand al opmerkte: je zoektijd wordt letters * zoektijd voor 1 dir.

Die zoektijd wordt bepaald door de intelligentie van het filesystem. MacOS gebruikt hier bv B-Tree+ voor, en dat werkt wel lekker

Wat ik wil zeggen: jij maakt een voor JOU begrijpelijke structuur en wil vv. dat het filesystem voor snelheid zorgt. Wat denk handiger is: pleur dit in een database en zet daar een index op. Voordeel is dat de database dan zelf voor de beste bestandsindeling en caching kan kiezen - met enkel de zoekopdrachten om mee rekening te houden. Een gewoon filesystem is uiteraard niet bedacht met slechts 1 users en 1 directory, waardoor je caching niet soeper-doeper werkt.

[Apache]

reiserfs zal hier wel mee overweg kunnen denk ik, anders een speciaal fs hiervoor verzinnen?

[Janoz]

Op donderdag 13 december 2001 13:01 schreef chem het volgende:
.........Wat denk handiger is: pleur dit in een database en zet daar een index op. Voordeel is dat de database dan zelf voor de beste bestandsindeling en caching kan kiezen - met enkel de zoekopdrachten om mee rekening te houden. Een gewoon filesystem is uiteraard niet bedacht met slechts 1 users en 1 directory, waardoor je caching niet soeper-doeper werkt.

Mwah... boomstructuren met variabele diepte zijn niet echt heel lekker in een RDB te gooien IMHO. (Tenzij je het natuurlijk over de gewone woorden had natuurlijk, en niet het mappen van je eigen datastructuur op een db-ontwerp)... Intern werkt een database met velden waarop een key zit ook mbv een boom structuur (Hierbij zijn echter wel wat extra's toegevoegd, zoals onderlinge verbindingen tussen de leafs zodat je ook makkelijk op volgorde kunt uitlezen)