mysql - real - Filtrado/búsqueda eficiente
busqueda en tiempo real con php (3)
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 usando 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 el ID de usuario 10" serían una consulta bastante rápida contra 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 utilizamos 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 de inmediato 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 usando 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 use 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?
¡No descarte MySQL tan fácilmente!
Implementarlo utilizando la base de datos, por ejemplo, seleccionar con un ''me gusta'' en la cláusula where o lo que sea.
Perfíllo, agregue índices si es necesario. Despliegue una versión beta, de modo que obtenga números reales a partir de los patrones de datos reales del usuario; no todas las columnas se preguntarán después, etc.
Si el rendimiento es malo, 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 de tecnología ...
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 de Lucene, vincular los documentos de Lucene a sus objetos relacionales es bastante sencillo, simplemente agregue una propiedad almacenada al documento en el momento del índice (esta propiedad puede ser una url, ID, GUID, etc.) Luego, la búsqueda se convierte en un 2 sistema de fase: 1) Emitir consulta a los índices de Lucene (Mostrar resultados simples como el título) 2) Obtener información más detallada sobre el objeto de sus tiendas relacionales por su clave
Debido a que la creación de instancias de Documentos es relativamente costosa en Lucene, solo desea almacenar campos buscados en el índice Lucene, en lugar de completar clones de sus objetos relacionales.
En caso de que desee 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 considerando a Sphinx y Lucene como posibles soluciones.