Solución:
Una de nuestras aplicaciones utiliza datos que se almacenan tanto en Cassandra como en ElasticSearch. Usamos Cassandra para acceder a esos registros siempre que podemos, y tenemos datos duplicados en tablas de consulta diseñadas para cumplir con 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 destruir todo y volver a cargar. Para ese propósito, he escrito trabajos que están diseñados para mantener ElasticSearch sincronizado con nuestro clúster de Cassandra. También hubo una discusión bastante reciente en Quora sobre este tema, que arrojó puntos similares.
Dicho esto, ElasticSearch funciona estupendo como motor de búsqueda. Y Cassandra trabaja estupendo como un almacén de datos escalable y de alto rendimiento. Pero preguntando los datos son diferentes de buscando para los datos. Hay ocasiones en las que necesitamos uno u otro, y una combinación de los dos funciona bien para nuestra aplicación. Puede (o no) funcionar bien para el tuyo.
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.
Editar 20200421
Escribí una respuesta más reciente a una pregunta similar:
ElasticSearch frente a ElasticSearch + Cassandra
Cassandra + Lucene es una gran opción. Existen diferentes iniciativas para este tema, por ejemplo:
- Índice Cassandra Lucene de Stratio: derivado de Stratio Cassandra, es un complemento para Apache Cassandra que amplía su funcionalidad de índice. (https://github.com/Stratio/cassandra-lucene-index)
- Stratio Cassandra, es una integración nativa con Apache Lucene, es muy interesante. (https://github.com/Stratio/stratio-cassandra) – ESTE PROYECTO HA SIDO DESCONTINUADO A FAVOR DEL Índice Cassandra Lucene de Stratio
- Tuplejump Calliope, es como Stratio Cassandra, pero es menos activo. (https://github.com/tuplejump/stargate-core)
- Búsqueda DSE por Datastax. Permite usar Cassandra con Apache Solr, pero es una opción propietaria (http://www.datastax.com/what-we-offer/products-services/datastax-enterprise)
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 que estás preservando tu esquema de datos con una operación de escritura confiable y no quieres aprovechar las operaciones de indexación que ofrece elasticsearch. En caso de que desee conservar algunos datos de índices, elasticsearch es bueno en caso de que confíe en su esquema y solo vaya a hacer 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. Habría usado casandra si hubiera querido tener muchos cambios en el esquema de los datos en mis líneas de pilotaje analíticas.
También hay muchas herramientas de representación agradables como kibana que puede utilizar para presentar sus datos con buenos gráficos. Quizás soy vago pero ellos son muy guapos y me ayudaron.