Portable desktop search: Få mest mulig ut av DocFetcher

Det gode med datamaskiner er at de gjør det enkelt å lage tusenvis av dokumenter. Den dårlige tingen med datamaskiner er en direkte konsekvens av den gode: Å finne blant alle dokumentene bare de du trenger, raskt, kan være vanskelig. Det er der Open Source Java-programmet kalt DocFetcher prøver å hjelpe.

Generelt sett er jeg, uten noen spesiell grunn, ikke så glad i Java-applikasjoner. Jeg synes DocFetcher er ganske interessant. Den kan fungere som en flerbruker, veldig bærbar stasjonær søkemotor, hvis du konfigurerer den på riktig måte. Her er noen triks for å gjøre nettopp det.

Konfigurer først minnet

Installasjon og grunnleggende bruk av DocFetcher er ganske enkel, takket være det rene brukergrensesnittet ( figur A ), integrert manual og wiki, så jeg hopper direkte til de tøffe delene. Den viktigste ulempen med DocFetcher kan være standardminnekonfigurasjonen.

Figur A

Alle Java-programmer har en haugestørrelse, det vil si en grense for hvor mye minne de kan bruke. Standardverdien for DocFetcher er 256 megabyte, noe som ikke er nok. Med den verdien går DocFetcher tom for minne ikke bare mens jeg indekserer Dokumentmappen min (16530 filer for en total størrelse på litt over 4 GB), men også under søk. For å redusere frekvensen av dette problemet mest mulig, øker du haugestørrelsen på linjen i DocFetcher.sh-skriptet som faktisk starter Java:
 java -enableassertions -Xmx256m -Xss2m -cp ".: $ {CLASSPATH}" -Djava.library.path = "lib" net.sourceforge.docfetcher.Main " postbeskyttet " 

Endre verdien på -Xmx- alternativet til minst 512 MB, og du vil være mye lykkeligere. Du kan også prøve å leke med Java-stabelstørrelsen, det vil si Xss, hvis betydning er godt forklart her.

Du kan gjøre DocFetcher raskere og mer robust også ved å begrense det maksimale antall resultater per spørring. For å gjøre det, tilordne den minste verdien som passer dine virkelige behov til MaxResultsTotal-alternativet i den generelle konfigurasjonsfilen: conf / program-conf.txt .

Indeks smart ...

DocFetcher må lage indekser over filene dine. Etter den første kjøringen må bare nye eller fjernede filer analyseres, slik at minneforbruket blir mindre kritisk. Likevel kan du på en fornuftig måte forbedre ytelsene og effektiviteten til DocFetcher-indeksen. Hvis det er mulig, kan du bare beholde komprimerte arkiver i formater som har interne indekser, for eksempel Zip, i stedet for komprimerte tjærefiler. Ellers må DocFetcher pakke ut arkivene helt for å vite hva de inneholder. Fremfor alt må du sørge for at du bare indekserer det du virkelig, virkelig, virkelig vil eller trenger å indeksere. Så før du starter DocFetcher:

  • fjerne dupliserte filer
  • ekskludere hele klasser av filer ved å legge inn riktige ordinære uttrykk (f.eks:. * \. xls for å hoppe over alle Excel-regneark) i "Ekskluder filer" -delen av indekseringskø-vinduet
  • desinfiser navnene på filene dine og gjør dem meningsfulle. Som du ser i figur B, returnerer DocFetcher relevante filer, selv om navnene deres samsvarer med søkeordene, selv om innholdet ikke kunne analyseres som tekst
  • aktiver SourceCodeAnalyzer-modus i konfigurasjonsfilen hvis du trenger å indeksere mye programvarekildekode
  • erklærer eksplisitt alle formatene som er ren tekst, men kanskje ikke blir gjenkjent som sådan, fra markeringsspråk som den store .t2t

Figur B

... og søk deretter

Det er to måter å gjøre DocFetcher-søk på. Først må du begrense dem til så få mapper som mulig, og angi minimum og maksimal størrelse på filene du forventer å finne. Det som imidlertid utgjør forskjellen, er å lære å fortelle DocFetcher så nøyaktig som mulig hva den skal søke. Den faktiske, komplette søkesyntaxen er den samme som Apache Lucene-motoren, men her er et ekstra forenklet sammendrag å begynne å øve. Sammen med bare søkeordene, som er små og små bokstaver, kan du spesifisere deres:

  • relativ vekt : "linux ^ 4 windows" betyr "søke etter filer som inkluderer både Linux og Windows, men sett først de der Linux er hyppigere"
  • avstand : "linux windows" ~ 10 står for "return filer der Linux og Windows ikke er mer enn 10 ord fra hverandre"
  • likhet : "linux ~" returnerer dokument som inneholder ordet Linux eller lignende

Flerbruker, bærbart søk

Jeg nevnte i begynnelsen at DocFetcher "kan fungere som en multi-user, veldig bærbar desktop søkemotor" . Bærbarhet begynner med at DocFetcher kjører med samme indeksformat, også på Mac OS og Windows. Bortsett fra det, er DocFetcher, hvis jeg kan bruke et buzzword, sky-kompatibelt . Hvis både filene og indeksene er på nettlagring et sted, vil en kopi av DocFetcher som peker til disse indeksene, kunne søke i disse filene.

Dette vil imidlertid bare skje hvis både indeksene og de indekserte mappene alltid er i samme relative stilling (f.eks. Begge under "/ dropbox_files"), og du oppretter alltid indeksene med alternativet "relative baner" merket. Ved å bruke dette trikset kan du også distribuere søkbare dokumentsamlinger, fra e-bøker til firmakataloger, legge alle filene og en kopi av DocFetcher på CD-ROMS og USB-nøkler! Bare husk å også ta med en kopi av Java runtime-installasjonsprogrammet, i tilfelle sluttbrukeren ikke allerede har en på datamaskinen.

Endelig kan DocFetcher-indekser deles mellom mange brukere. Den raske, skitne, lavteknologiske måten å gjøre dette på er å få hver bruker til å installere sin egen kopi av den bærbare versjonen av DocFetcher i mappen hennes, og deretter for hånd angi indeksenes plassering i filen misc / paths.txt . Det eneste problemet i et slikt scenario ville være hvis alle kunne gjenopprette indeksene eller endre konfigurasjonen. For å forhindre dette, deaktiverer du alle alternativene relatert til indeksoppretting og modifisering i program-conf.txt- filen for alle DocFetcher-installasjonene. I teorien kan naturligvis brukere skrive om de samme alternativene som de vil i panelet "Avanserte innstillinger" i DocFetcher, men ikke bekymre deg: beskytt indeksene ved å gi skrivetilgang til både dem og mappen de bor i bare til DocFetcher-administrator.

© Copyright 2021 | pepebotifarra.com