java - Usando el índice de búsqueda de Solr como base de datos, ¿está esto "mal"?

mysql database

Question

Mi equipo está trabajando con un CMS de terceros que usa Solr como índice de búsqueda. Me he dado cuenta de que parece que los autores están utilizando Solr como una base de datos de tipo en que cada documento devuelto contiene dos campos:

1. El ID del documento Solr (básicamente un nombre de clase y una identificación de base de datos)
2. Una representación XML de todo el objeto

Básicamente, ejecuta una búsqueda en Solr, descarga la representación XML del objeto y crea una instancia del objeto a partir del XML en lugar de buscarlo en la base de datos utilizando el ID.

Mi instinto me dice que esta es una mala práctica. Solr es un índice de búsqueda, no una base de datos ... así que tiene más sentido para mí ejecutar nuestras búsquedas complejas contra Solr, obtener los identificadores del documento y luego extraer las filas correspondientes de la base de datos.

¿La implementación actual es perfectamente sólida o hay datos que respalden la idea de que esto está maduro para la refactorización?

EDITAR: Cuando digo "representación XML", me refiero a un campo almacenado que contiene una cadena XML de todas las propiedades del objeto, no múltiples campos almacenados.

Answer 1

Es perfectamente razonable utilizar Solr como base de datos, dependiendo de su aplicación. De hecho, eso es más o menos lo que guardian.co.uk está haciendo .

Definitivamente no es una mala práctica per se. Es malo si lo usas de la manera incorrecta, como cualquier otra herramienta en cualquier nivel, incluso GOTO.

Cuando dice "Una representación XML ...", supongo que está hablando de tener múltiples campos almacenados de Solr y recuperarlos utilizando el formato XML de Solr, y no solo un gran campo de contenido XML (lo cual sería un uso terrible de Solr). . El hecho de que Solr use XML como formato de respuesta predeterminado es en gran medida irrelevante, también puede usar un protocolo binario , por lo que es bastante comparable a las bases de datos relacionales tradicionales en ese sentido.

En última instancia, depende de las necesidades de su aplicación. Solr es principalmente un motor de búsqueda de texto, pero también puede actuar como una base de datos NoSQL para muchas aplicaciones.

Answer 2

Esto probablemente se hizo por razones de rendimiento, si no causa ningún problema, lo dejaría en paz. Hay una gran área gris de lo que debería ser en una base de datos tradicional frente a un índice de solr. Parece que la gente hace cosas similares a esto (generalmente pares de valores clave o json en lugar de xml) para la presentación de la interfaz de usuario y solo obtiene el objeto real de la base de datos si es necesario para las actualizaciones / eliminaciones. Pero todas las lecturas solo van a Solr.

Answer 3

He visto cosas similares porque permite una búsqueda muy rápida. Estamos trasladando los datos de nuestros índices de Lucene a una tienda rápida de valores clave para seguir los principios DRY y también para disminuir el tamaño del índice. No hay una regla dura para este tipo de cosas.

Answer 4

Sí, puedes usar SOLR como base de datos, pero hay algunas advertencias realmente serias:

1. El patrón de acceso más común de SOLR, que está por encima de http, no responde particularmente bien a las consultas por lotes. Además, SOLR NO transmite datos, por lo que no puede iterar perezosamente a través de millones de registros a la vez. Esto significa que debe tener mucho cuidado al diseñar patrones de acceso a datos a gran escala con SOLR.

2. Aunque el rendimiento de SOLR escala horizontalmente (más máquinas, más núcleos, etc.) y verticalmente (más RAM, mejores máquinas, etc.), sus capacidades de consulta son muy limitadas en comparación con las de un SGBDR maduro . Dicho esto, hay algunas funciones excelentes, como las consultas de estadísticas de campo, que son bastante convenientes.

3. Los desarrolladores que están acostumbrados a usar bases de datos relacionales a menudo se encontrarán con problemas cuando usan los mismos patrones de diseño DAO en un paradigma SOLR, debido a la forma en que SOLR usa los filtros en las consultas. Habrá una curva de aprendizaje para desarrollar el enfoque correcto para crear una aplicación que use SOLR como parte de sus grandes consultas o modificaciones statefull .

4. Las herramientas de "emprendeduría" que permiten la gestión avanzada de sesiones y las entidades statefull que muchas ofertas avanzadas de frameworks web (Ruby, Hibernate, ...) tendrán que lanzarse por completo por la ventana .

5. Las bases de datos relacionales están destinadas a tratar con datos y relaciones complejas, y están acompañadas de métricas de última generación y herramientas de análisis automatizados. En SOLR, me he encontrado escribiendo esas herramientas y poniendo a prueba las pruebas de estrés manualmente, lo que puede ser una pérdida de tiempo .

6. Unirse: este es el gran asesino. Las bases de datos relacionales admiten métodos para crear y optimizar vistas y consultas que unen tuplas basadas en predicados simples. En SOLR, no hay ningún método robusto para unir datos entre índices.

7. Resistencia: para alta disponibilidad, SolrCloud utiliza un sistema de archivos distribuidos debajo (es decir, HCFS). Este modelo es bastante diferente al de una base de datos relacional, que generalmente tiene resiliencia usando esclavos y maestros, o RAID, y así sucesivamente. Por lo tanto, debe estar preparado para proporcionar la infraestructura de resistencia que requiere SOLR si desea que sea escalable y resistente a la nube.

Dicho esto, hay muchas ventajas obvias para SOLR para ciertas tareas: (ver http://wiki.apache.org/solr/WhyUseSolr ) - las consultas sueltas son mucho más fáciles de ejecutar y devuelven resultados significativos. La indexación se realiza de forma predeterminada, por lo que la mayoría de las consultas arbitrarias se ejecutan con bastante eficacia (a diferencia de un RDBMS, donde a menudo tiene que optimizar y desnormalizar después del hecho).

Conclusión: aunque PUEDE usar SOLR como un RDBMS, puede encontrar (como yo) que en última instancia, "no hay almuerzo gratis", y los ahorros de costos de las búsquedas de texto lucene super-cool y de alto rendimiento, en la memoria indexación, a menudo son pagados por una menor flexibilidad y adopción de nuevos flujos de trabajo de acceso a datos.