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?