Sí, puede usar SOLR como base de datos, pero hay algunas advertencias realmente serias:
-
El patrón de acceso más común de SOLR, que es sobre 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 ser muy cuidadoso cuando diseña patrones de acceso a datos a gran escala con SOLR.
-
Aunque el rendimiento de SOLR escala tanto horizontalmente (más máquinas, más núcleos, etc.) como verticalmente (más RAM, mejores máquinas, etc.), sus capacidades de consulta son muy limitadas en comparación con las de un RDBMS maduro. . Dicho esto, hay algunas funciones excelentes, como las consultas de estadísticas de campo, que son muy convenientes.
-
Los desarrolladores que están acostumbrados a usar bases de datos relacionales a menudo tendrán problemas cuando usen los mismos patrones de diseño DAO en un paradigma SOLR, debido a la forma en que SOLR usa filtros en las consultas. Habrá una curva de aprendizaje para desarrollar el enfoque correcto para construir una aplicación que use SOLR para parte de sus consultas grandes o modificaciones con estado .
-
Las herramientas "empresariales" que permiten la gestión avanzada de sesiones y entidades con estado que ofrecen muchos marcos web avanzados (Ruby, Hibernate, ...) tendrán que descartarse por completo .
-
Las bases de datos relacionales están diseñadas para manejar datos y relaciones complejas y, por lo tanto, están acompañadas de métricas de última generación y herramientas de análisis automatizadas. En SOLR, me encontré escribiendo este tipo de herramientas y haciendo muchas pruebas de estrés manualmente, lo que puede ser una pérdida de tiempo .
-
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 existen métodos sólidos para unir datos entre índices.
-
Resiliencia:para una alta disponibilidad, SolrCloud utiliza un sistema de archivos distribuido 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, etc. Por lo tanto, debe estar preparado para proporcionar la infraestructura de resiliencia que requiere SOLR si desea que sea resistente y escalable en la nube.
Dicho esto, hay muchas ventajas obvias para SOLR para ciertas tareas:(ver http://wiki. apache.org/solr/Por qué usarSolr ) -- las consultas sueltas son mucho más fáciles de ejecutar y devuelven resultados significativos. La indexación se realiza de manera predeterminada, por lo que la mayoría de las consultas arbitrarias se ejecutan de manera bastante efectiva (a diferencia de un RDBMS, donde a menudo tiene que optimizar y desnormalizar después del hecho).
Conclusión: A pesar de que PUEDE usar SOLR como RDBMS, es posible que encuentre (como lo he hecho yo) que, en última instancia, "no hay almuerzo gratis", y el ahorro de costos de las búsquedas de texto lucene súper geniales y la indexación en memoria de alto rendimiento, a menudo se pagan con una menor flexibilidad y la adopción de nuevos flujos de trabajo de acceso a datos.
