[PHP] Indexering & zoeken van bestanden

Hoihoi!

Ik ben met een bepaalde opdracht bezig, en voor die opdracht moet ik nu in PHP, bestanden gaan doorzoeken. De situatie is als volgt:

Ik heb een x aantal documenten verspreid over een y aantal mappen. x en y staan niet vast en kunnen veranderen.
Een gebruiker komt op mijn site en zoekt naar "Open Source".
De bedoeling is nu dat er in de x documenten in y mappen gezocht wordt naar documenten die één of meerdere van deze keywords bevatten.

BUT WAIT THERES MORE
Ook moet er in het resultaat een kleine opname van de tekst aanwezig zijn, waarbij ongeveer 80 tekens aan weerszijden van de keyword ook volledig zichtbaar moeten zijn. Dit wil zeggen dat de woorden niet afgekapt mogen worden na 80 tekens.

Hoe kan ik dit het beste oplossen?

Ik zelf zat te denken aan ofwel een inverse search functie (kost veel rekenkracht), en dan om de zoveel tijd de nieuwe bestanden indexeren, of de documenten parsen en enkel de tekst in de database zetten, en dan in de vorm van een "LIKE keyword" search of fulltext-search (met de +-operand) zoeken naar de keywords.

Graag hoor ik of iemand een betere oplossing heeft.

- Rik

Zijn het gewone plaintext bestandjes of met opmaak en alles zoals Word?

Ik zou het sowieso indexeren ja, en dan met fulltext zoeken. Of als je tijd en zin hebt om je er in te verdiepen: iets als Solr of Lucene.

Lennard schreef:

Zijn het gewone plaintext bestandjes of met opmaak en alles zoals Word?

Ik zou het sowieso indexeren ja, en dan met fulltext zoeken. Of als je tijd en zin hebt om je er in te verdiepen: iets als Solr of Lucene.

De opmaak is niet relevant. Er moet een lijst komen met documenten met relevante informatie (op basis van de keywords). De indexering gaat dan waarschijnlijk ook via plaintext lopen.

Solr en Lucene zijn niet mogelijk omdat de applicatie volledig in PHP moet op standaard hard/software.
Beide applicaties moeten standalone in een java applet draaien, iets wat niet zomaar mogelijk is.

Is het een specifieke extensie waar in je wilt zoeken? Zo weet ik dat het bij PDF in ieder geval mogelijk is om deze om te rekenen tot tekst en deze te indexeren.

Jponsen schreef:

Is het een specifieke extensie waar in je wilt zoeken? Zo weet ik dat het bij PDF in ieder geval mogelijk is om deze om te rekenen tot tekst en deze te indexeren.

Ja. Sowieso Doc, Docx, Pdf, HTML, en wellicht xlsx

Maar het probleem is niet zozeer de plaintext zelf exporteren. Daar heb ik al verschillende libraries voor gevonden.

Ik zou zelf voor de tweede oplossing die je zelf noemt gaan. Als je dan de bestandsnaam en omschrijving in een DB zet (eventueel een hash erbij, CRC o.i.d.). Je calculeert de complete size van alle mappen, slaat deze op controleert bij elke hit of de size onveranderd is, zo niet herbouw je complete database of kijk aan de hand van de eventueel opgeslagen hash of die nog hetzelfde zijn of dat het een compleet nieuw bestand is.

Dit lijkt mij de snelste manier om dit voor elkaar te krijgen.

Zoiets dacht ik ook al. Heb nu een database met filenaam, text, modificatiedatum, checksum en nog wat andere data.

Rik schreef:

Zoiets dacht ik ook al. Heb nu een database met filenaam, text, modificatiedatum, checksum en nog wat andere data.

Als je nu nog een checksum of totale size opslaat van alles bij elkaar dan hoef je niet per bestand een query uit te voeren, voor een mogelijke update. Dat hoef je dan enkel te doen als de checksum of size niet overeenkomt van het totaalplaatje.

Timkb schreef:

Eerdere citaten tonen

Rik schreef:

Zoiets dacht ik ook al. Heb nu een database met filenaam, text, modificatiedatum, checksum en nog wat andere data.

Als je nu nog een checksum of totale size opslaat van alles bij elkaar

of de filemtime() van de map bekijkt

Timkb schreef:

Eerdere citaten tonen

Rik schreef:

Zoiets dacht ik ook al. Heb nu een database met filenaam, text, modificatiedatum, checksum en nog wat andere data.

Als je nu nog een checksum of totale size opslaat van alles bij elkaar dan hoef je niet per bestand een query uit te voeren, voor een mogelijke update. Dat hoef je dan enkel te doen als de checksum of size niet overeenkomt van het totaalplaatje.

Probleem is dat ik dat dan ook weer in een nieuwe tabel moet plaatsen, en teveel (onnodige) tabellen wilde ik voorkomen.

Dat van lennard is misschien een beter idee, omdat ik één root map heb die ik door moet zoeken met mogelijk x submappen.

Rik schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Rik schreef:

Zoiets dacht ik ook al. Heb nu een database met filenaam, text, modificatiedatum, checksum en nog wat andere data.

Als je nu nog een checksum of totale size opslaat van alles bij elkaar dan hoef je niet per bestand een query uit te voeren, voor een mogelijke update. Dat hoef je dan enkel te doen als de checksum of size niet overeenkomt van het totaalplaatje.

Probleem is dat ik dat dan ook weer in een nieuwe tabel moet plaatsen, en teveel (onnodige) tabellen wilde ik voorkomen.

Dat van lennard is misschien een beter idee, omdat ik één root map heb die ik door moet zoeken met mogelijk x submappen.

Hoe is dat anders met Lennards idee? (Al vind ik Lennards idee inderdaad beter, stuk sneller)

Met mijn idee heb je van je root map de totale size of hash, met Lennards idee heb je de laatste change time van de root map. Beide zul je het moeten opslaan op een of andere manier.

Wat ik echter betwijfel is of filemtime op een map kan, stat daarentegen wel, bevat ook de laatste modificatie tijd.

Je hebt gelijk dat ik ook dat ergens moet opslaan. Een klein voordeel van Lennards manier is inderdaad dat het een stuk sneller is. Voor de md5hash moet ik alle files weer ophalen.
Voor een locale drive is het nog redelijk snel, maar voor 10 files in een bepaalde netwerkshare hier ben ik helaas 3 seconde per file bezig ofzo.

Bump.

Ik zit nu met een klein probleempje. De bestanden indexeren nu prima (en alles komt netjes in de tabel te staan), maar wanneer een bestand verplaatst of verwijderd wordt dan heb ik een probleem.

De originele record blijft dan namelijk bestaan, en er komt als het ware een duplicate record (waar enkel de filepath anders is).
Hoe kan ik dit het beste oplossen?

Ik dacht in eerste instantie aan het checken van de checksum, maar daar zijn ook scenarios te vinden waarin dit fout gaat:
Gebruiker opent bestand
Gebruiker slaat bestand ergens anders op (met andere content) -> checksum is anders
Gebruiker verwijderd oude bestand.

Op deze manier heeft een checksum check geen zin, simpelweg omdat de checksum bij het opslaan compleet anders is geworden. Een "UPDATE .. WHERE checksum = $checksum" is dan dus niet mogelijk.

Dat kan niet echt.
Dan zul je óf de gebruiker moeten forceren alles via jouw applicatie te doen, óf gewoon elke x termijn alles opnieuw moeten indexeren (eventueel checken op de filemtime of hash van je submappen of je die map wel opnieuw moet indexeren).

Lennard schreef:

Dat kan niet echt.
Dan zul je óf de gebruiker moeten forceren alles via jouw applicatie te doen, óf gewoon elke x termijn alles opnieuw moeten indexeren (eventueel checken op de filemtime of hash van je submappen of je die map wel opnieuw moet indexeren).

Dat dacht ik al
Probleem daarbij is helaas dat het ophalen per bestand zon 10-15 seconden duurt omdat het van een netwerkdrive gehaald moet worden.