indicizzazione leggera dei documenti per gestire meno di 250.000 record potenziali

Di recente mi sono trovato a sfregare contro i limiti dei motori di indicizzazione dei documenti. Stavo sviluppando un piccolo sito Web che aveva bisogno di capacità di ricerca abbastanza robuste ma a causa dei loro vincoli hardware non riuscivo a distribuire una soluzione Lucene (come Solr o ElasticSearch, come farei normalmente) per gestire questa esigenza.

E anche allora, mentre avevo bisogno di fornire alcuni dati complessi e calcoli che richiedevano un uso intensivo del database, non avevo bisogno di gestire oltre 250.000 potenziali record. L'implementazione di un'intera istanza Solr o ES solo per gestire ciò sembrava uno spreco.

Dopo averci pensato, sembra un problema abbastanza grande. Molte persone gestiscono i requisiti di ricerca esclusivamente con SQL. Eseguono solo query SQL per i loro dati e basta. Anche le loro capacità di ricerca finiscono per essere terribili.

• Fare una ricerca jolly full-text coperta può essere dolorosamente lento su alcuni sistemi (in particolare gli host condivisi) e impantanare il database, soprattutto se hai query complicate e molti join.

• Si finisce per fare più query su una singola richiesta da parte dell'utente. Potresti aggirare questo problema con query sempre più complicate, ma vedi il punto precedente.

• Mancanza di funzionalità tipicamente presenti nei motori full-text.

I database avevano lo stesso problema della necessità di essere distribuiti come server e quindi è arrivato SQLite e improvvisamente abbiamo potuto distribuire un database autonomo in un singolo file. My Googling non ha prodotto nulla: chiedo se esiste qualcosa del genere per l'indicizzazione / ricerca full-text.

Quali fattori prendere in considerazione quando si decide se implementare l'indicizzazione di documenti leggeri (ad esempio, come spiegato nelle risposte a un'altra domanda ) o continuare a utilizzare SQL per queste situazioni?

Sai, devo dire di considerare l'uso di Redis.

• Usa l'idea di contesto . Sarebbe difficile approfondire senza sapere di più sui documenti. Spesso puoi discernere molte cose dai titoli dei documenti. La profilatura di ogni documento è il primo passo di base, proprio come la scansione del Web.

• Conta su ogni documento di parole in un dizionario di parole chiave. Tieni traccia del conteggio della popolarità di ogni parola per il progetto totale. Aggiungi più peso all'iteratore per questo conteggio se riesci a rilevare un'elevata rilevanza in un documento o set.
  
  La prima cosa che fai è darti un elenco tutto compreso di parole nell'intero set. Nulla NON trovato in tale elenco, ritorno automatico di "nessun risultato". Suggerirei una classifica dei risultati inferiore al 5-20% inferiore della popolarità (quando si esegue una query di ricerca sull'indice) semplicemente non dire risultati '.

• Se non andate con qualcosa come Redis, o anche solo fare il proprio struttura di memoria è possibile associare documenti con file descrittori di file o mini-db e oggetti della pagina che descrivono ogni specifico indietro documento e indietro per la memoria. Mantieni le ricerche comuni in memoria, magari facendole competere per le slot o dando loro il tempo di vivere che cresce ad ogni ricerca.

• Per andare oltre, inizia a salvare i dati di riferimento che raggruppano un link / ref / pointer / index / qualunque sia di due o più documenti e un pool di parole chiave o frasi. Fondamentalmente si ottiene una nuvola di tag pompata.

• Inoltre, effettua il rilevamento delle frasi monitorando quando una parola nel tuo dizionario è seguita o preceduta da una stringa esatta comunemente in documenti con metadati / titolo simili. Questo è intenso ma richiede solo un passaggio per il rendering dei dati.

• Maggiore è il modo in cui puoi separare i tuoi dati e mantenere i gruppi collegati tra loro nell'uso effettivo, meglio è.

• Collega la probabilità di correttezza monitorando ogni volta che un utente fa clic su un risultato che non è tra i primi tre. Ottieni il miglioramento del rilevamento delle frasi guardando le ricerche degli utenti che non hanno prodotto risultati perfetti. Forza le tue query a diventare relative alle ricerche dei clienti.

• Devi cercare gli aggiornamenti dei documenti? Chronjobs / shell script o attività programmate / script batch possono aiutare. Ci sono varie opzioni per la programmazione e lo scripting, ovviamente.

• Spreca disco, guadagna velocità, perdi complessità. Salva più alberi dei tuoi documenti e / o alberi di link ai documenti. Cerca solo gli alberi per i quali sono stati soddisfatti i criteri, o almeno li preferisci per ottenere risultati più veloci nella maggior parte dei casi.

• Crea il tuo motore di permutazione leggero o trova quello che utilizza il rilevamento rapido dei caratteri e nessuna regex. Oppure creane uno utilizzando regex in poche ore, ma la differenza di prestazioni sarà evidente qui per ricerche sufficienti.

• Così tante cose.

Queste sono intese come possibili soluzioni per implementare l'indicizzazione e la ricerca di documenti affidabili. Non è tutto compreso. E a quel punto probabilmente faresti meglio a prendere una scatola di riserva, gettarci sopra una rete neurale e passare un paio di giorni a creare una bella interfaccia web con quella rete neurale.