[Java] PDF's indexeren, full-text search

[-FoX-]

Ik ga binnenkort, voor een bepaald web-based project, een full-text search feature moeten voorzien voor een heel aantal documenten (10GB). Veel van deze documenten zijn pdf's en men wil dan ook de mogelijkheid hebben om een full-text search uit te voeren. Voor deze feature komt het Lucene framework leuk om de hoek kijken.

Nu ben ik juist even aan het experimenteren geweest met het indexeren van de PDF's en hier heb je dan ook een heel aantal libraries voor. Mijn keuze hiervoor is dan op PDFBox gevallen. Echter in mijn lokale testresultaten zou het ongeveer een 20-tal uren duren alvorens de 10GB aan documenten geïndexeerd zullen zijn. Aangezien dit slechts 1x moet gebeuren is dit wel een haalbaar feit.

Nu kwam ik ook volgende PDF extractor tegen, namelijk: PDFTextStream.
Dit is wel een commerciële versie (prijs: 2000$) en alhoewel ik eerder geneigd ben naar OpenSource projecten vond ik deze benchmark-resultaten toch opmerkelijk.
De prijs van de PDFTextStream is wel redelijk hoog. Vooral dan ook het feit dat dit project bij meerdere klanten zal moeten geïmplementeerd worden en dus ook iedere keer de $2000 betaald zal moeten worden.

code:

PDFTextStream: 28.998 seconden
PDFBox: 156.477 seconden (oftewel 5x zolang)

Nu weet ik niet in welke mate ik belang moet hechten aan deze resultaten. Zijn er personen die ervaring hebben op j2ee gebied met full-text search en indexering van pdf's? En zoja, wat zijn de ervaringen hiermee?
Moet er veel belang gehecht worden aan de snelheid van deze PDF-libs, en zijn er misschien PDF-libs die mij beter zouden passen??

Het zelf schrijven van dergelijke PDF-extractor lijkt me een beetje te ver gaan, aangezien het dan nog maar de vraag is of de snelheid gemeten kan worden aan die van PDFBox.

Alle ervaringen/tips/plan van aanpak zijn welkom!

[Robtimus]

Ik heb voor school eens zoiets gedaan, wij gebruikten pdftotext om het eerst naar plain text te converteren en dat te indexeren. Woorden van 1 karakter werden niet geindexeerd.

[Soultaker]

Als je uitsluitend kijkt naar de snelheid (en niet overige eigenschappen zoals functionaliteit, ontwikkelmodel en eventuele bugs) dan lijkt me dat je een inschatting moet maken van het aantal (gewijzigde of nieuwe) documenten er per dag geïndexeerd moeten worden. Het lijkt me dat je die ook binnen een dag moet kunnen verwerken; als PDFBox dat kan, dan zou ik zeggen dat dat snel genoeg is.

Het indexeren van gegevens is niet iets waarbij responstijd van groot belang is; het is vooral belangrijk je de stroom van gegevens kan bijhouden. Of een document na 5 minuten of na 25 minuten toegevoegd is aan de index lijkt me niet heel relevant.

[cenix]

op sf staat nog een project wat pdf indexeert. Maar ik heb deze verder nog niet getest, wellicht kun je er iets mee.

http://sourceforge.net/projects/pdfsearch/

[DaCoTa]

Om het nog onduidelijker te maken, je zou ook naar Lowagie iText kunnen kijken.

[-FoX-]

IceManX schreef op 21 september 2004 @ 16:17:
Ik heb voor school eens zoiets gedaan, wij gebruikten pdftotext om het eerst naar plain text te converteren en dat te indexeren. Woorden van 1 karakter werden niet geindexeerd.

Werkte dat goed en hoe vond jij dat het indexeren verliep?

Soultaker schreef op 21 september 2004 @ 16:18:
Als je uitsluitend kijkt naar de snelheid (en niet overige eigenschappen zoals functionaliteit, ontwikkelmodel en eventuele bugs) dan lijkt me dat je een inschatting moet maken van het aantal (gewijzigde of nieuwe) documenten er per dag geïndexeerd moeten worden. Het lijkt me dat je die ook binnen een dag moet kunnen verwerken; als PDFBox dat kan, dan zou ik zeggen dat dat snel genoeg is.

Het indexeren van gegevens is niet iets waarbij responstijd van groot belang is; het is vooral belangrijk je de stroom van gegevens kan bijhouden. Of een document na 5 minuten of na 25 minuten toegevoegd is aan de index lijkt me niet heel relevant.

Dus jij zou van het indexeren eerder een nachtelijke taak maken of iets dergelijk? Of eventueel werken met een bepaalde queue? Ik had eerst gedacht aan realtime indexatie, maar dit is misschien toch geen haalbare oplossing...

[Robtimus]

-FoX- schreef op 22 september 2004 @ 08:49:
[...]

Werkte dat goed en hoe vond jij dat het indexeren verliep?

Werkte best goed, we kregen dan in de database een mapping van woorden naar documenten. De index werd alleen best groot, ruim 10% van de documenten die waren opgeslagen.
Je kon ook niet op een volgorde van woorden zoeken (dus een hele string), maar een AND van meerdere woorden zou geen probleem moeten zijn.

Was maar voor een schoolopdracht, dus echt super goed hoefde het niet te werken.

[djluc]

Ik had eerst gedacht aan realtime indexatie, maar dit is misschien toch geen haalbare oplossing...

Is totaal afhankelijk van je hardware en je load. Als je maar 1 user hebt die soms een zoekactie plaatst kan je wel realtime indexeren waarschijnlijk. Als er continu zoekacties binnen komen lijkt dit me niet zo handig. Verder is het van belang te weten of de server internationaal gebruikt wordt. Dan heb je vaak namelijk niet minder load 's nachts omdat de andere landen aan het werk zijn.

[Verwijderd]

djluc schreef op 22 september 2004 @ 10:44:
Is totaal afhankelijk van je hardware en je load. Als je maar 1 user hebt die soms een zoekactie plaatst kan je wel realtime indexeren waarschijnlijk. Als er continu zoekacties binnen komen lijkt dit me niet zo handig. Verder is het van belang te weten of de server internationaal gebruikt wordt. Dan heb je vaak namelijk niet minder load 's nachts omdat de andere landen aan het werk zijn.

Real time indexeren lijkt me alleen in de meest triviale gevallen haalbaar (je bedoelt toch live in de PDF files zoeken)?

Ik gebruik ghostscript met pstotext om pdf's naar ascii te converteren. Die ascii wordt vervolgens omgezet in een inverted file in een Mysql database. Het geheel draait onder Linux. Werkt zonder problemen.

PDF's worden geindexeerd zodra ze worden toegevoegd. Zoeken is (natuurlijk) supersnel. Indexeren is snel zat... Toevoegen van documenten gebeurt veel minder dan zoeken.

[-FoX-]

Als ik het dus goed begrijp, zijn de libraries als PDFTextStream.. die razendsnel zijn, een beetje overbodig in de meeste applicaties. Tenzij er echt honderden documenten per uur geupload worden en dus ook geïndexeerd moeten worden.

Is het vanuit het gebruikersstandpunt een goed idee om de indexering 's nachts te laten plaatsvinden om de systeem resources een beetje te verdelen? Of verwacht een gebruiker een onmiddellijke indexering en dus een onmiddellijke snelle full-text search

[Verwijderd]

-FoX- schreef op 23 september 2004 @ 08:25:
Als ik het dus goed begrijp, zijn de libraries als PDFTextStream.. die razendsnel zijn, een beetje overbodig in de meeste applicaties. Tenzij er echt honderden documenten per uur geupload worden en dus ook geïndexeerd moeten worden.

Is het vanuit het gebruikersstandpunt een goed idee om de indexering 's nachts te laten plaatsvinden om de systeem resources een beetje te verdelen? Of verwacht een gebruiker een onmiddellijke indexering en dus een onmiddellijke snelle full-text search

Dat zijn vragen die ik bij gebrek aan voldoende informatie niet kan beantwoorden. Incrementeel indexeren moet snel genoeg zijn om zo goed als real time documenten te verwerken. Afhankelijk van de hoeveelheden documenten en de grootte natuurlijk. Dat kun je alleen proefondervindelijk uittesten.

ALs het nuttig is: Mijn systeem indexeert 36000 documenten (mix van HTML, MS-Word en PDF) van in totaal 1.7 GB in ca. 12 uur. Dat kan dus net 's nachts. Normaal gesproken is het voldoende om alleen de nieuw toegevoegde documenten te indexeren. Als ik dat doe voor de laatste 24 uur (31 documenten) krijg ik:

code:

Processed 14 nodes, 31 links, 15388 words (unique per document)

real    0m38.747s
user    0m9.710s
sys     0m1.190s

Daar doet hij dus 38.7 seconden over. Ruim een seconde per document. Best acceptabel lijkt mij. In mijn geval is real time indexeren dus zeker haalbaar. (in de praktijk is er wel een max. 10 minuten vertraging).

Het gaat om een dual 2.4 Ghz P4 processor Linux systeem.

[ Voor 4% gewijzigd door Verwijderd op 23-09-2004 10:18 ]