Elasticsearch vs Cassandra vs Elasticsearch con Cassandra

110

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

  • Necesito almacenar datos a un ritmo más rápido y leer datos.
  • Totalmente a prueba de fallas y fácilmente escalable.
  • Capaz de buscar datos para Analytics.

Terminé con una breve lista de: Cassandra and Elasticsearch

Lo que 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 from_date to to_dateo más formas de obtener datos para análisis, si no diseño el modelo de datos correctamente o no mantengo la vista a largo plazo, lo que podría ser bastante difícil en un mundo en constante cambio.

Si bien Elastic Searches mejor para indexar (respaldado por Lucene), y puede buscar los datos al azar arrojando texto al azar. Pero, ¿funciona igual incluso si quiero recuperar datos from_date to to_date(espero que sea así)? 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, ¡explícalo! ¿Cómo los combinamos para obtener una solución más eficaz?

elasticsearch cassandra lucene Reddy
fuente
2
También debe considerar DSE Search = Cassandra + solr integrado = lo mejor de ambos mundos: una base de datos escalable para el almacenamiento impulsado por el poder de búsqueda de Solr.
Bereng
1
@Bereng, supongo que DSE es comercial y no nos ocupamos de software comercial.
Reddy
3
Si es una startup con ingresos netos <$ 2 millones (EE. UU.), Le permitirán usar DSE de forma gratuita (durante al menos uno o dos años).
Aaron

Respuestas:

150

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 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 a buscar 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 al utilizar el 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

Aaron
fuente
24
¿Alguien puede explicar la diferencia entre consultar y buscar los datos?
Dror
21
@dror, por ejemplo, si conoce la (s) identificación (s) de sus datos, simplemente la solicita (cassandra) y si no conoce la (s) identificación (es) de sus datos, entonces la busca (búsqueda elástica).
Arsenik
2
@Gladwell, todo depende del tamaño de sus datos y de la complejidad de sus consultas. En teoría, Elastic puede hacerlo todo. Sin embargo, confío en que Cassandra haga un mejor trabajo de escalado para admitir un gran conjunto de datos (para consultas) que Elastic, especialmente si admite múltiples regiones / DC.
Aaron
1
@Aaron ... escalar para admitir un gran conjunto de datos es lo que ambos motores hacen bien. Nuestra organización utiliza la búsqueda elástica como base de datos principal, motor de alertas, herramienta de análisis y ahora que xpack admite el aprendizaje automático; también proporciona estadísticas comerciales sobre nuestro IOT de borde.
AnthonyJClink
1
@Dror Haciendo la verdadera pregunta!
Mike Ezzati
32

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

Álvaro Agea
fuente
Una cosa a tener en cuenta, en 2.1 ahora puede "colocar" un indexador personalizado ... así, por ejemplo, podría imitar lo que Statio está haciendo con su bifurcación de C * pero fuera de la línea principal C *. No estoy al tanto de ningún esfuerzo generalizado para hacer esto, pero planeo colocar los índices de Lucene en C * de esta manera. Para más información: issues.apache.org/jira/browse/CASSANDRA-8717
evanv
8

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 algunos buenos gráficos. Quizás soy vago pero ellos son muy guapos y me ayudaron.

M.Rez
fuente
4

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

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


fuente
4

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 esto artículo , su rendimiento es bueno.
Si su aplicación necesita la función de búsqueda, Elassandra es la mejor opción de código abierto. La búsqueda DSE está disponible pero es cara.

anavaras lamurep
fuente
1

Habíamos desarrollado una aplicación en la que utilizamos Elasticsearch y Cassandra. Se almacenaron datos similares en Cassandra y se indexaron en Elasticsearch.

La interfaz de usuario de nuestra aplicación tenía funciones 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 estén indexados en Elasticsearch.

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

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

Sumit A
fuente
0
  • Como elasticsearch se basa en el índice de Lucene y si desea almacenar la indexación en elasticsearch, se desempeña 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, se crearán problemas.
  • 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 utilizar con fluidez si los configura correctamente.
  • Solo las desventajas que puedo pensar en ello, si está apuntando a un resultado en tiempo real y no puede compensar un retraso de milisegundos 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.
vishal yadav
fuente
0

Cassandra es excelente para recuperar datos por ID . No sé mucho sobre el rendimiento del índice secundario, pero dudo que sea tan rápido como Elasticsearch. Sin duda, Elasticsearch gana cuando se trata de la funcionalidad de búsqueda de texto completo ( análisis de texto , puntuación de relevancia , etc.).

Cassandra también gana en rendimiento de actualización . Elasticsearch admite actualizaciones, pero una actualización es en realidad una reindexación + eliminación suave en una operación atómica.

Cassandra tiene un modelo de replicación muy bueno (si necesita ser más seguro). Elasticsearch también está bien, no estoy en el campo que dice que ES es particularmente poco confiable (a veces tiene problemas, como todo el software).

Elasticsearch también tiene agregaciones para análisis en tiempo real. Y debido a que las búsquedas son tan rápidas, el análisis de un subconjunto de datos será rápido .

Si alguno de ellos satisface sus requisitos lo suficientemente bien (como aquí, parece que ES funcionaría bien), solo usaría uno. Si tiene requisitos de ambos mundos, puede:

  • use uno de ellos y solucione los inconvenientes. Por ejemplo, es posible que pueda manejar muchas actualizaciones con Elasticsearch, pero con más fragmentos y más hardware
  • usa ambos y asegúrate de que estén sincronizados
Radu Gheorghe
fuente