indicizzazione dei documenti leggera per gestire meno di 250k di record potenziali

10

Recentemente mi sono trovato a scaldarmi alle limitazioni dei motori di indicizzazione dei documenti. Stavo sviluppando un piccolo sito web che aveva bisogno di alcune funzionalità di ricerca abbastanza robuste, ma a causa dei loro vincoli hardware non potevo implementare una soluzione Lucene-ish (come Solr o ElasticSearch, come normalmente farei) per gestire questa esigenza.

E anche allora, mentre dovevo servire alcuni dati complessi e calcoli che richiedevano un uso intensivo del database, non avevo bisogno di gestire più di 250k di record potenziali. Distribuire un'intera istanza Solr o ES solo per gestirlo sembrava uno spreco.

Dopo che ci ho pensato, sembra un problema abbastanza grande. La maggior parte delle persone gestisce i requisiti di ricerca esclusivamente con SQL. Eseguono solo query SQL per i loro dati e basta. Le loro capacità di ricerca finiscono per essere terribili.

  • L'esecuzione di una ricerca con caratteri jolly full-text può risultare dolorosamente lenta su alcuni sistemi (in particolare gli host condivisi) e impantanare il database, soprattutto se si hanno query complesse e molti join.

  • Finisci facendo più query su una singola richiesta da parte dell'utente. Puoi aggirare questo problema con query sempre più complicate, ma vedi il punto precedente.

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

I database hanno avuto lo stesso problema di dover essere distribuiti come server e poi SQLite è arrivato e improvvisamente abbiamo potuto implementare un database che è autonomo in un singolo file. My Googling non ha prodotto nulla - mi chiedo se esista qualcosa come questo per l'indicizzazione / ricerca full-text.

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

    
posta Jarrod Nettles 02.01.2013 - 23:16
fonte

1 risposta

2

Sai, devo dire prendere in considerazione l'utilizzo di redis.

  • Utilizza l'idea di contesto . Sarebbe difficile approfondire senza saperne di più sui documenti. Spesso puoi distinguere molte cose dai titoli dei documenti. La profilazione di ciascun documento è il primo passo di base, proprio come la scansione web.

  • Fai un conteggio 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 sei in grado di rilevare un'elevata rilevanza in un documento o in un set.

    La prima cosa che fa è darti un elenco di parole tutto incluso in tutto il tuo set. Qualcosa che NON si trova in quella lista, ritorno automatico di "nessun risultato". Suggerirei una classifica dei risultati inferiore al 5-20% di popolarità (quando si esegue la query di ricerca sull'indice) anche semplicemente non dire risultati ".

  • Se fai vai con qualcosa di simile a redis, o anche solo crea la tua struttura di memoria puoi accoppiare documenti con file descrittore o file mini-db e oggetti pagina che descrivono ogni specifico documento avanti e indietro alla memoria. Tieni le ricerche comuni in memoria forse facendole competere per le slot o dando loro un tempo per vivere che cresce su ogni ricerca.

  • Per andare oltre, inizia a salvare i dati di riferimento che raggruppano un link / ref / pointer / index / a prescindere da due o più documenti e un gruppo di parole chiave o frasi. Fondamentalmente ottieni un tag cloud pompato.

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

  • Più modi puoi separare i tuoi dati e mantenere i gruppi correlati l'uno con l'altro nell'uso effettivo, meglio è.

  • Connetti la probabilità di correttezza monitorando ogni volta che un utente fa clic su un risultato che non è tra i primi tre. Migliora il 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 controllare gli aggiornamenti dei documenti? Chronjobs / script di shell o attività pianificate / script batch possono aiutare. Ci sono varie opzioni per la programmazione e lo scripting anche se ovviamente.

  • Rifiuti di disco, velocità di guadagno, perdita di complessità. Salva più alberi dei tuoi documenti e / o alberi di link ai documenti. Cerca solo gli alberi per i quali sono stati rispettati i criteri, o almeno li preferisci per ottenere risultati più rapidi nella maggior parte dei casi.

  • Crea il tuo motore di permutazione leggero o trovane uno che utilizza il rilevamento rapido dei caratteri e nessuna regex. In alternativa, creane uno con espressioni regolari 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 robuste indicizzazioni e ricerche di documenti. Non è tutto compreso. E a questo probabilmente faresti meglio ad afferrare una scatola di scorta, buttare una rete neurale e passare un paio di giorni a fare una bella interfaccia web con quella rete neurale.

    
risposta data 08.02.2013 - 03:06
fonte

Leggi altre domande sui tag