Filtrado/búsqueda eficiente

Question

Tenemos una aplicación alojada que administra páginas de contenido. Cada página puede tener una cantidad de campos personalizados y algunos campos estándar (marca de tiempo, nombre de usuario, correo electrónico del usuario, etc.).

Con potencialmente cientos de sitios diferentes que usan el sistema, ¿cuál es una forma eficiente de manejar el filtrado/búsqueda? Imagine una vista de cuadrícula que desee restringir. Puede filtrar en campos específicos (ID de usuario, fecha) o puede ingresar a una búsqueda de texto completo.

Por ejemplo, "todas las páginas iniciadas por userid 10" serían una consulta bastante rápida en una base de datos MySQL. Pero cosas como "todas las páginas iniciadas por un usuario cuyo ID de usuario es 10 y coincide con [alguna consulta de búsqueda]" aspirarían contra la base de datos, por lo que es adecuada para un motor de búsqueda como Lucene.

Básicamente me pregunto cómo otros sitios grandes hacen este tipo de cosas. ¿Utilizan un motor de búsqueda 100% para todos los tipos de filtrado? ¿Mezclan consultas de bases de datos con un motor de búsqueda?

Si usamos solo un motor de búsqueda, hay un problema con el tiempo de demora que tarda un objeto nuevo/actualizado en aparecer en el índice de búsqueda. Es decir, he leído que no es inteligente actualizar el índice inmediatamente, y hacerlo en lotes. Incluso si esto significa cada 5 minutos, los usuarios se confundirán cuando su página recientemente agregada no se muestre inmediatamente cuando vean una simple página (por ejemplo, una consulta de búsqueda de "categoría: 5").

Estamos utilizando MySQL y hemos estado mirando de cerca a Lucene para buscar. ¿Hay alguna otra tecnología que no sepa?

Mi idea es ofrecer una página de filtrado simple que utiliza MySQL para filtrar campos básicos. Luego, ofrezca una página de búsqueda de texto completo separada que presente resultados similares a Google. ¿Es esta la única manera?

Answer 1

Solr o grassyknoll proporcionan interfaces ligeramente más abstractas a Lucene.

Dicho eso: Sí. Si usted es un sitio principalmente basado en contenido, que proporciona búsquedas de texto completo sobre sus datos, hay algo en juego más allá de LIKE. Si bien los índices FULLTEXT de MySql no son perfectos, en el ínterin podría ser un marcador de posición aceptable.

Suponiendo que crea un índice Lucene, vincular documentos Lucene a sus objetos relacionales es bastante sencillo, simplemente agregue una propiedad almacenada al documento en tiempo de indexación (esta propiedad puede ser una url, ID, GUID, etc.) Entonces, la búsqueda se convierte en un sistema de 2 fases: 1) Emisión de consulta para indexies Lucene (Mostrar resultados simples como título) 2) Obtener información más detallada acerca del objeto de sus almacenes relacionales por su clave

Desde instanciación de Documentos es relativamente costoso en Lucene, solo desea almacenar campos buscados en el índice Lucene, en lugar de completar clones de sus objetos relacionales.

Answer 2

¡No elimine MySQL tan fácilmente!

Impleméntelo usando la base de datos, p. un seleccionar con un 'me gusta' en la cláusula where o lo que sea.

Perfílmelo, agregue índices si es necesario. Despliegue una versión beta, de modo que obtenga números reales de los patrones de datos reales del usuario; no todas las columnas se preguntan después, etc.

Si el rendimiento es malo, entonces eso es cuando se consideran otras opciones. Puede considerar ajustar su SQL, su base de datos, la máquina en la que se ejecuta la base de datos y, finalmente, utilizar otra pila tecnológica ...

Answer 3

En caso de que quiera utilizar MySQL o PostgreSQL, una solución de código abierto que funciona muy bien con ella es Sphinx: http://www.sphinxsearch.com/

Estamos teniendo el mismo problema y teniendo en cuenta Esfinge y Lucene como posibles soluciones.