indexación de documentos liviana para manejar menos de 250k registros potenciales

Recientemente me encontré irritando las limitaciones de los motores de indexación de documentos. Estaba desarrollando un sitio web pequeño que necesitaba algunas capacidades de búsqueda bastante robustas, pero debido a sus limitaciones de hardware no pude implementar una solución Lucene-ish (como Solr o ElasticSearch, como normalmente lo haría) para manejar esta necesidad.

E incluso entonces, aunque necesitaba presentar algunos datos y cálculos complejos que requerían una gran cantidad de bases de datos, no necesitaba manejar más de 250 mil registros potenciales. Implementar una instancia completa de Solr o ES solo para manejar esto parecía un desperdicio.

Después de pensarlo, parece un problema bastante grande. La mayoría de las personas maneja los requisitos de búsqueda únicamente con SQL. Simplemente ejecutan consultas SQL para sus datos y eso es todo. Sus capacidades de búsqueda también terminan siendo terribles.

• Hacer una búsqueda general de comodines de texto completo puede ser muy lento en algunos sistemas (hosts compartidos en particular) y atascar su base de datos, especialmente si tiene consultas complicadas y muchas uniones.

• Terminas haciendo múltiples consultas en una sola solicitud del usuario. Puede solucionar esto con consultas cada vez más complicadas, pero vea el punto anterior.

• Falta de características típicamente presentes en los motores de texto completo.

Las bases de datos tenían el mismo problema de necesitar ser implementadas como un servidor y luego apareció SQLite y de repente pudimos implementar una base de datos que está contenida en un solo archivo. Mi búsqueda en Google no ha producido nada; me pregunto si existe algo como esto para la indexación / búsqueda de texto completo.

¿Qué factores hay que tener en cuenta al decidir si implementar una indexación de documentos ligera (por ejemplo, como se explica en las respuestas a otra pregunta ) o seguir usando SQL para estas situaciones?

Sabes, tengo que decir que consideres usar redis.

• Usa la idea de contexto . Sería difícil profundizar sin saber más sobre los documentos. A menudo puede discernir muchas cosas de los títulos de los documentos. Perfilar cada documento es el primer paso básico, al igual que el rastreo web.

• Cuente cada documento de palabras en un diccionario de palabras clave. Mantenga un registro del conteo de popularidad de cada palabra para el proyecto total. Agregue más peso al iterador para este recuento si puede detectar una gran relevancia en un documento o conjunto.
  
  Lo primero que hace es darle una lista de palabras con todo incluido en todo su conjunto. Cualquier cosa que NO se encuentre en esa lista, devolución automática de "sin resultados". Sugeriría una clasificación de resultados inferior al 5-20% inferior de popularidad (cuando se ejecuta una consulta de búsqueda en el índice) también simplemente dice que no hay resultados '.

• Si no vas con algo así como Redis, o simplemente hacer su propia estructura de memoria puede vincular documentos con archivos descriptores de fichero o mini-db y objetos de la página que describen cada vuelta documento específico y vuelta a la memoria. Mantenga las búsquedas comunes en la memoria, tal vez haciéndolas competir por las máquinas tragamonedas o dándoles un tiempo de vida que crezca en cada búsqueda.

• Para ir más lejos, comience a guardar datos de referencia que agrupen un enlace / ref / puntero / índice / cualquiera de dos o más documentos y un grupo de palabras clave o frases. Básicamente obtienes una nube de etiquetas bombeada.

• Aún más, realice la detección de frases mediante el seguimiento cuando una palabra en su diccionario es seguida o precedida por una cadena exacta comúnmente en documentos de metadatos / títulos similares. Esto es intensivo pero requiere solo una pasada para representar los datos.

• Cuantas más formas pueda segregar sus datos y mantener los grupos relacionados entre sí en el uso real, mejor.

• Conecte la probabilidad de corrección haciendo un seguimiento cada vez que un usuario hace clic en un resultado que no está entre los tres primeros. Mejore la detección de frases observando búsquedas de usuarios que no arrojaron resultados perfectos. Fuerce sus consultas para que sean relativas a las búsquedas de los clientes.

• ¿Tienes que estar atento a las actualizaciones de documentos? Chronjobs / script de shell o tareas programadas / script por lotes pueden ayudar. Sin embargo, hay varias opciones para programar y crear secuencias de comandos.

• Disco de desperdicio, ganar velocidad, perder complejidad. Guarde varios árboles de sus documentos y / o árboles de enlaces a los documentos. Solo busque los árboles para los que se han cumplido los criterios, o al menos prefiera que obtengan resultados más rápido en la mayoría de los casos.

• Haga su propio motor de permutación ligero o encuentre uno que use detección rápida de caracteres y no regex. O simplemente haga uno usando regex en unas pocas horas, pero la diferencia de rendimiento será notable aquí para búsquedas suficientes.

• Muchas cosas.

Estas son las posibles soluciones para implementar una sólida indexación y búsqueda de documentos. No es todo incluido. Y es probable que sea mejor tomar una caja de repuesto, ponerle una red neuronal y pasar un par de días haciendo una buena interfaz web para esa red neuronal.