¿Cuándo NO usar Cassandra?

Últimamente se ha hablado mucho sobre Cassandra .

Twitter, Digg, Facebook, etc., todos lo usan.

¿Cuándo tiene sentido:

• usa Cassandra,
• no use Cassandra, y
• use un RDMS en lugar de Cassandra.

No hay nada como una bala de plata, todo está construido para resolver problemas específicos y tiene sus propios pros y contras. Depende de usted, qué enunciado del problema tiene y cuál es la mejor solución para ese problema.

Intentaré responder a sus preguntas una por una en el mismo orden en que las hizo. Dado que Cassandra se basa en la familia de bases de datos NoSQL, es importante que comprenda por qué usar una base de datos NoSQL antes de responder sus preguntas.

Por qué usar NoSQL

En el caso de RDBMS, hacer una elección es bastante fácil porque todas las bases de datos como MySQL, Oracle, MS SQL, PostgreSQL en esta categoría ofrecen casi el mismo tipo de soluciones orientadas a las propiedades ACID. Cuando se trata de NoSQL, la decisión se vuelve difícil porque cada base de datos NoSQL ofrece diferentes soluciones y debe comprender cuál es la más adecuada para los requisitos de su aplicación / sistema. Por ejemplo, MongoDB es apto para casos de uso donde su sistema exige un almacén de documentos sin esquema. HBase puede ser adecuado para motores de búsqueda, analizar datos de registro o cualquier lugar donde se requiera escanear tablas de unión bidimensionales enormes. Redis está diseñado para proporcionar búsqueda en memoria de variedades de estructuras de datos como árboles, colas, listas vinculadas, etc. y puede ser una buena opción para crear tablas de clasificación en tiempo real, sistema de tipo pub-sub. Del mismo modo, hay otras bases de datos en esta categoría (incluida Cassandra) que son aptas para diferentes enunciados de problemas. Ahora pasemos a las preguntas originales y contestemos una por una.

Cuando usar Cassandra

Al ser parte de la familia NoSQL, Cassandra ofrece una solución para problemas donde uno de sus requisitos es tener un sistema de escritura muy pesado y desea tener un sistema de informes bastante receptivo sobre los datos almacenados. Considere el caso de uso de la analítica web donde los datos de registro se almacenan para cada solicitud y desea construir una plataforma analítica a su alrededor para contar las visitas por hora, por navegador, por IP, etc. de manera real. Puede consultar esta publicación de blog para comprender más sobre los casos de uso en los que Cassandra encaja.

Cuándo usar un RDMS en lugar de Cassandra

Cassandra se basa en una base de datos NoSQL y no proporciona propiedades de datos relacionales y ACID. Si tiene un fuerte requisito para las propiedades de ACID (por ejemplo, datos financieros), Cassandra no sería adecuado en ese caso. Obviamente, puede hacer una solución para eso, sin embargo, terminará escribiendo un montón de código de aplicación para simular las propiedades de ACID y perderá tiempo en el mercado. También administrar ese tipo de sistema con Cassandra sería complejo y tedioso para usted.

Cuando no usar Cassandra

No creo que deba responderse si la explicación anterior tiene sentido.

Al evaluar los sistemas de datos distribuidos, debe tener en cuenta el teorema de CAP: puede elegir dos de los siguientes: consistencia, disponibilidad y tolerancia de partición.

Cassandra es un sistema tolerante a la partición disponible que admite la consistencia eventual. Para obtener más información, vea esta publicación de blog que escribí: Guía visual de sistemas NoSQL .

Cassandra es la respuesta a un problema particular: ¿Qué haces cuando tienes tantos datos que no caben en un servidor? ¿Cómo almacena todos sus datos en muchos servidores y no rompe su cuenta bancaria y no vuelve locos a sus desarrolladores? Facebook obtiene 4 Terabytes de nuevos datos comprimidos CADA DÍA. Y este número probablemente crecerá más de dos veces en un año.

Si no tiene esta cantidad de datos o si tiene que pagar millones por la instalación del clúster Enterprise Oracle / DB2 y los especialistas necesarios para configurarlo y mantenerlo, entonces está bien con la base de datos SQL.

Sin embargo, Facebook ya no usa cassandra y ahora usa MySQL casi exclusivamente para mover la partición hacia arriba en la pila de aplicaciones para un rendimiento más rápido y un mejor control.

La idea general de NoSQL es que debe usar el almacén de datos que mejor se adapte a su aplicación. Si tiene una tabla de datos financieros, use SQL. Si tiene objetos que requerirían consultas complejas / lentas para mapear a un esquema relacional, use un objeto o un almacén de clave / valor.

Por supuesto, casi cualquier problema del mundo real con el que te encuentres está en algún punto entre esos dos extremos y ninguna de las soluciones será perfecta. Debe considerar las capacidades de cada tienda y las consecuencias de usar una sobre la otra, que serán muy específicas para el problema que está tratando de resolver.

Además de las respuestas dadas anteriormente sobre cuándo usar y cuándo no usar Cassandra, si decide usar Cassandra, es posible que desee considerar no usar Cassandra en sí, sino uno de sus muchos primos.

Algunas respuestas anteriores ya apuntaban a varios sistemas "NoSQL" que comparten muchas propiedades con Cassandra, con algunas diferencias pequeñas o grandes, y pueden ser mejores que Cassandra para sus necesidades específicas.

Además, recientemente (varios años después de que se formulara originalmente esta pregunta), un clon de Cassandra llamado Scylla (ver se lanzó https://en.wikipedia.org/wiki/Scylla_(database) . Scylla es una reimplementación de código abierto de Cassandra en C ++, que afirma tener un rendimiento significativamente mayor y latencias más bajas que la Java Cassandra original, aunque es principalmente compatible con ella (en características, API y formatos de archivo). Entonces, si ya estás considerando a Cassandra, es posible que también quieras considerar a Scylla.

Al hablar con alguien en medio del despliegue de Cassandra, no maneja bien los muchos a muchos. Están haciendo un trabajo de pirateo para hacer sus pruebas iniciales. Hablé con un consultor de Cassandra sobre esto y me dijo que no lo recomendaría si tuviera este problema establecido.

Debes hacerte las siguientes preguntas:

1. (Volumen, velocidad) ¿Escribirás y leerás TONELADAS de información, tanta información que ninguna computadora podría manejar las escrituras?
2. (Global) ¿Necesitará esta capacidad de escritura y lectura en todo el mundo para que las escrituras en una parte del mundo sean accesibles en otra parte del mundo?
3. (Confiabilidad) ¿Necesita que esta base de datos esté en funcionamiento todo el tiempo y nunca se caiga, independientemente de qué nube, qué país, ya sea VM, contenedor o metal desnudo?
4. (Capacidad de escala) ¿Necesita esta base de datos para poder seguir creciendo fácilmente y escalar linealmente?
5. (Consistencia) ¿Necesita consistencia TUNABLE donde algunas escrituras pueden ocurrir de forma asíncrona donde otras necesitan ser certificadas?
6. (Habilidad) ¿Está dispuesto a hacer lo que sea necesario para aprender esta tecnología y el modelado de datos que conlleva la creación de una base de datos distribuida globalmente que puede ser rápida para todos, en todas partes?

Si para alguna de estas preguntas pensó "tal vez" o "no", debe usar otra cosa. Si tuviste un "infierno sí" como respuesta a todos ellos, entonces deberías usar Cassandra.

Use RDBMS cuando pueda hacer todo en una caja. Probablemente sea más fácil que la mayoría y cualquiera puede trabajar con él.

La consulta individual pesada frente a la carga de consulta ligera de gazillion es otro punto a considerar, además de otras respuestas aquí. Es inherentemente más difícil optimizar automáticamente una sola consulta en una base de datos de estilo NoSql. Utilicé MongoDB y me encontré con problemas de rendimiento al intentar calcular una consulta compleja. No he usado Cassandra pero espero que tenga el mismo problema.

Por otro lado, si se espera que su carga sea la de muchas consultas pequeñas, y desea poder escalar fácilmente, podría aprovechar la consistencia eventual que ofrece la mayoría de los DB NoSql. Tenga en cuenta que la coherencia eventual no es realmente una característica de un modelo de datos no relacionales, pero es mucho más fácil de implementar y configurar en un sistema basado en NoSql.

Para una consulta única y muy pesada, cualquier motor RDBMS moderno puede hacer un trabajo decente paralelizando partes de la consulta y aprovechar la cantidad de CPU y memoria que le arrojas (en una sola máquina). Las bases de datos NoSql no tienen suficiente información sobre la estructura de los datos para poder hacer suposiciones que permitirán una paralelización verdaderamente inteligente de una gran consulta. Le permiten escalar fácilmente más servidores (o núcleos), pero una vez que la consulta alcanza un nivel de complejidad, básicamente se ve obligado a dividirla manualmente en partes que el motor NoSql sabe cómo tratar de manera inteligente.

En mi experiencia con MongoDB, al final debido a la complejidad de la consulta, Mongo no pudo hacer mucho para optimizarla y ejecutar partes de ella en múltiples datos. Mongo paraleliza múltiples consultas, pero no es tan bueno para optimizar una sola.

Leamos algunos casos del mundo real:

http://planetcassandra.org/apache-cassandra-use-cases/

En este artículo: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Explicaron que la razón por la que no eligieron MySql es porque la sincronización de db es demasiado lenta.

(También debido a la confirmación de 2 frases, FK, PK)

Cassandra está basada en papel de Amazon Dynamo

caracteristicas:

Estabilidad

Alta disponibilidad

El respaldo funciona bien

Leer y escribir es mejor que HBase, (clon de BigTable en Java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Su conclusión es:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

A partir de 2018,

Recomendaría usar ScyllaDB para reemplazar la clásica cassandra, si necesita soporte de espalda.

El complemento kv de Postgres también es rápido que cassandra. Sin embargo, nunca tendrá escalabilidad de varias instancias.

Me centraré aquí en algunos de los aspectos importantes que pueden ayudarlo a decidir si realmente necesita a Cassandra. La lista no es exhaustiva, solo algunos de los puntos que tengo en mente:

• No considere a Cassandra como la primera opción cuando tenga un requisito estricto sobre la relación (en todo su conjunto de datos).

• Cassandra por defecto es el sistema AP (de CAP). Pero, es compatible con la consistencia ajustable, lo que significa que también se puede configurar para admitir como CP. Así que no lo ignore solo porque haya leído en alguna parte que es AP y está buscando sistemas CP. Cassandra se denomina con mayor precisión "sintonizablemente consistente", lo que significa que le permite decidir fácilmente el nivel de consistencia que necesita, en equilibrio con el nivel de disponibilidad.

• No use Cassandra si su escala no es demasiado o si puede manejar un DB no distribuido.

• Piense mejor si su equipo piensa que todos sus problemas se resolverán si usa bases de datos distribuidas como Cassandra. Comenzar con estos DB es muy simple, ya que viene con muchos valores predeterminados, pero optimizarlo y dominarlo para resolver un problema específico requeriría una buena (si no mucho) esfuerzo de ingeniería.

• Cassandra está orientada a columnas, pero al mismo tiempo cada fila también tiene una clave única. Por lo tanto, podría ser útil considerarlo como una tienda indexada orientada a filas. Incluso puede usarlo como un almacén de documentos.

• Cassandra no te obliga a definir los campos de antemano. Entonces, si está en un modo de inicio o sus características están evolucionando (como en ágil), Cassandra lo acepta. Así que mejor, primero piense en las consultas y luego piense en los datos para responderlas.

• Cassandra está optimizada para un rendimiento realmente alto en escrituras. Si su caso de uso es de lectura pesada (como caché), Cassandra podría no ser una opción ideal.

Otra situación que facilita la elección es cuando desea utilizar funciones agregadas como suma, mínimo, máximo, etc. y consultas complejas (como en el sistema financiero mencionado anteriormente), entonces una base de datos relacional es probablemente más conveniente que una base de datos nosql ya que ambas son no es posible en un nosbl databse a menos que use realmente muchos índices invertidos. Cuando usa nosql, tendría que hacer las funciones agregadas en el código o almacenarlas por separado en su propia familia de columnas, pero esto hace que todo sea bastante complejo y reduce el rendimiento que obtuvo al usar nosql.

Si necesita una base de datos totalmente coherente con semántica SQL, Cassandra NO es la solución para usted. Cassandra admite búsquedas de valor clave. No admite consultas SQL. Los datos en Cassandra son "eventualmente consistentes". Las búsquedas simultáneas de datos pueden ser inconsistentes, pero eventualmente las búsquedas son consistentes.

Si necesita una semántica estricta y necesita soporte para consultas SQL, elija otra solución como MySQL, PostGres o combine el uso de Cassandra con Solr.

Cassandra es una buena opción si:

1. No necesita las propiedades ACID de su base de datos.

2. Habría una gran cantidad de escrituras en la base de datos.

3. Hay un requisito para integrarse con Big Data, Hadoop, Hive y Spark.

4. Existe la necesidad de análisis de datos en tiempo real y generación de informes.

5. Hay un requisito de mecanismo impresionante de tolerancia a fallas.

6. Hay un requisito de sistema homogéneo.

7. Hay un requisito de mucha personalización para el ajuste.

Mongodb tiene funciones agregadas muy poderosas y un marco agregado expresivo. Tiene muchas de las características que los desarrolladores están acostumbrados a usar del mundo de la base de datos relacional. Su estructura de datos / almacenamiento de documentos permite modelos de datos más complejos que Cassandra, por ejemplo.

Todo esto viene con compensaciones, por supuesto. Entonces, cuando seleccione su base de datos (NoSQL, NewSQL o RDBMS), observe qué problema está tratando de resolver y sus necesidades de escalabilidad. Ninguna base de datos lo hace todo.

Según DataStax, Cassandra no es el mejor caso de uso cuando es necesario

1- Dispositivos de hardware de alta gama. 2- Compatible con ACID sin reversión (transacción bancaria)

• No admite la gestión completa de transacciones en todas las tablas.
• Índice secundario no compatible.
• Debe confiar en Elastic search / Solr para el índice secundario y se debe escribir el componente de sincronización personalizado.
• Sistema no compatible con ACID.
• El soporte de consultas es limitado.

Apache cassandra es una base de datos distribuida para administrar grandes cantidades de datos estructurados en muchos servidores básicos, al tiempo que proporciona un servicio de alta disponibilidad y ningún punto único de falla.

La arquitectura se basa puramente en el teorema del límite, que es la disponibilidad y la tolerancia de partición, e interesantemente eventualmente consistente.

No lo use, si no está almacenando volúmenes de datos en racks de clústeres, no lo use si no está almacenando datos de series de tiempo, no lo use si no está haciendo un parche de sus servidores, no lo use si requiere una consistencia sólida.