elasticsearch cassandra lucene

Elasticsearch vs Cassandra vs Elasticsearch con Cassandra



lucene (7)

Almacenar datos en una combinación de Cassandra y ElasticSearch le brinda la mayor funcionalidad. Le permite buscar tablas de valor-clave y también le permite buscar datos en índices.

La combinación le brinda mucha flexibilidad, ideal para su aplicación.

Estoy aprendiendo NoSQL y estoy buscando diferentes opciones para uno de los requisitos de mi cliente. He revisado varios recursos antes de presentar esta pregunta (una persona con poco conocimiento en NoSQL)

  • Necesito almacenar datos a mayor velocidad y leer datos.
  • Totalmente a prueba de fallas y fácilmente escalable.
  • Capaz de buscar datos a través de Analytics.

Terminé con una breve lista de: Cassandra and Elasticsearch

Lo que sí entiendo es que Cassandra es una solución de almacenamiento NoSQL perfecta para mí, ya que puedo escribir datos y leer datos usando índices. Donde falla o podría fallar es en Analytics. En el futuro, si quiero obtener datos de from_date to to_date , o más formas de obtener datos para análisis, si no diseño el modelo de datos correctamente o mantengo una visión a largo plazo, lo que podría ser bastante difícil en un mundo en constante cambio.

Mientras que Elastic Search es mejor en indexación (respaldado por Lucene), y puede buscar datos aleatoriamente arrojando texto aleatorio. Pero funciona de la misma manera, incluso si quiero recuperar datos de from_date to to_date (espero que sea). Pero la verdadera pregunta es, ¿es un motor de búsqueda o un almacenamiento de datos NoSQL perfecto como Cassandra? Si es así, ¿por qué todavía necesitamos a Cassandra?

Si ambos están en un mundo diferente, ¡explique eso! ¿Cómo los combinamos para obtener una solución más efectiva?

Cassandra + Lucene es una gran opción. Existen diferentes iniciativas para este problema, por ejemplo:

Después de trabajar en este problema, me di cuenta de que las bases de datos NoSQL como casandra son buenas cuando quieres asegurarte de preservar tu esquema de datos con una operación de escritura confiable, y no quiero aprovechar las operaciones de indexación que ofrece elasticsearch. En caso de que desee preservar algunos datos de índices, elasticsearch es bueno en caso de que confíe en su esquema y solo haga muchas más lecturas que escrituras.

Mi caso fue el análisis de datos. Así que conservé muchos de mis Latices en la búsqueda elástica, ya que más tarde quise recorrer mucho los datos para ver cuál debería ser mi próximo paso. Hubiera usado casandra si hubiera querido tener muchos cambios en el esquema de los datos en mis líneas analíticas.

También hay muchas herramientas de representación agradables como kibana que puede usar para presentar sus datos con algunos buenos gráficos. Tal vez soy flojo pero son muy guapos y me ayudaron.

Habíamos desarrollado una aplicación donde usábamos Elasticsearch y Cassandra. Datos similares fueron almacenados en Cassandra e indexados en Elasticsearch.

La interfaz de usuario de nuestra aplicación tenía características como búsquedas, agregaciones, exportación de datos, etc. Los microservicios de back-end obtenían continuamente grandes datos (sobre temas de Kafka) y los almacenaban en Cassandra. Una vez que los datos se almacenan en Cassandra, los servicios se asegurarán de que los datos se indexen en Elasticsearch.

Cassandra estaba actuando como "Fuente de la verdad" para Elasticsearch. En los casos en que se requería reindexar el índice ES, consultamos a Cassandra y reindexamos los datos en ES.

Esta solución nos ayudó, ya que era muy fácil de escalar y las búsquedas y agregaciones fueron mucho más rápidas.

Una de nuestras aplicaciones utiliza datos almacenados en Cassandra y ElasticSearch. Usamos Cassandra para acceder a esos registros siempre que podemos, y duplicamos los datos en tablas de consulta diseñadas para cumplir con las solicitudes específicas del lado de la aplicación. Para una búsqueda más liberal de lo que nuestras tablas de consulta pueden permitir, ElasticSearch realiza esa funcionalidad muy bien.

Nos hemos hecho la misma pregunta (a nosotros mismos) ... "¿Por qué no obtenemos todo de ElastsicSearch?"

La respuesta es que ElasticSearch fue diseñado para ser un motor de búsqueda y no un almacén de datos persistente. A veces ElasticSearch pierde escrituras. Los cambios de esquema son difíciles de hacer en ElasticSearch sin eliminar todo y volver a cargar. Para ese propósito, he escrito trabajos diseñados para mantener ElasticSearch sincronizado con nuestro clúster Cassandra. También hubo una discusión bastante reciente sobre Quora sobre este tema , que arrojó puntos similares.

Dicho esto, ElasticSearch funciona muy bien como motor de búsqueda. Y Cassandra funciona muy bien como un almacén de datos escalable y de alto rendimiento. Pero consultar datos es diferente de buscar datos. Hay momentos en que necesitamos uno u otro, y una combinación de los dos funciona bien para nuestra aplicación. Puede (o puede que no) funcionar bien para los suyos.

En cuanto a la analítica, he tenido cierto éxito en el uso del conector Cassandra Spark, para atender consultas OLAP más complejas. Espero que ayude.

Elassandra es la solución combinada de Cassandra + Elastic search. Utiliza Elastic search para indexar los datos y Cassandra como el almacén de datos, no estoy seguro del rendimiento, pero según este article , su rendimiento es bueno.
Si su aplicación necesita una función de búsqueda, Elassandra es la mejor opción de código abierto. La búsqueda DSE está disponible pero es costosa.

  • Como elasticsearch se basa en el índice de Lucene y si desea almacenar la indexación en elasticsearch, funciona mejor en comparación con la indexación en Cassandra para recuperar los datos.
  • Si sus requisitos no están relacionados con la recuperación en tiempo real, también puede usar elasticsearch como base de datos NoSQL, hay pensamientos de que ElasticSearch pierde escrituras y los cambios de esquema son difíciles, pero si su volumen de datos no es demasiado grande. Puede lograr fácilmente elasticsearch como motor de búsqueda con la mejor indexación junto con elasticsearch como una base de datos NoSQL. Hay varias formas de prevenirlo. He trabajado en los cambios de esquema en elasticsearch, si su estructura de datos es consistente, creará cualquier problema.
  • Ser partidario de ElasticSearch o SOlr. He trabajado en ambos motores de búsqueda y he experimentado que ambos motores de búsqueda se pueden usar con fluidez si los configura correctamente.
  • Solo contras que puedo pensar en ello, si está apuntando a un resultado en tiempo real y no puede compensar milisegundos de retraso en su respuesta. Entonces es mejor tomar la ayuda de otras bases de datos NoSQL como cassandra o couchbase.
  • Cassandra con solr, funciona mejor que Cassandra con elasticSearch.