database - ventajas - ¿Cuándo NO debes usar Cassandra?

install cassandra (16)

Se han hablado mucho sobre Cassandra últimamente.

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

¿Cuándo tiene sentido hacer lo siguiente?

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

@Paco Perdón por explotar tu burbuja, pero especialmente con los datos financieros, la coherencia transaccional es CRÍTICA. Como se ha resaltado con bases de datos como Cassandra, una secuencia de comandos fallida puede dejar efectos secundarios, que pueden incluir una tabla actualizada y otra no. Un ejemplo: £ 100 es pasar de la cuenta del usuario 1 a la cuenta del usuario 2. Se registra una transacción en cada cuenta, que muestra que se eliminó de una y se agregó a la otra. Por supuesto, depende de tu diseño. En otro escenario, se realiza un pago al banco. Los fondos deben eliminarse de una cuenta y agregarse a otra. La falta de consistencia dejaría la posibilidad de que el dinero "desaparezca" del sistema o se cuente dos veces. De cualquier manera, el banco se encuentra en problemas.

Existen muchos casos en los que la coherencia transaccional es fundamental para las empresas. O bien, la aplicación lo maneja de manera segura y efectiva, o la base de datos debe manejarlo completamente, siendo esta última la opción "segura".

La falta de soporte de unión a través de cassandra también limita su uso, a menos que se utilicen otras aplicaciones adecuadas. En esa nota, también faltan las funciones de activación, las teclas foráneas, etc. En última instancia todo se reduce a lo que necesita. Si usted es un proveedor de búsqueda, por ejemplo, y tiene una gran base de clientes, Cassandra podría ser una opción perfecta. Para OLTP, y algunos casos de informes, por otro lado, o volúmenes de carga más pequeños, puede ser una falta de coincidencia completa con los requisitos.

Además de las respuestas dadas anteriormente sobre cuándo usar y cuándo no usar Cassandra, si decides usar Cassandra, quizás quieras considerar no usar a Cassandra, sino a uno de sus muchos primos.

Algunas de las 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 esta pregunta se realizó originalmente), se lanzó un clon de Cassandra llamado Scylla (ver https://en.wikipedia.org/wiki/Scylla_(database) ). Scylla es una reimplementación de código abierto de Cassandra en C ++, que dice tener un rendimiento significativamente más alto y latencias menores que el Java Cassandra original, mientras que es más compatible con él (en características, API y formatos de archivo). Entonces, si ya estás considerando a Cassandra, también deberías considerar a Scylla.

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

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

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

La arquitectura está basada puramente en el teorema de la tapa, que es la disponibilidad y la tolerancia de partición, e interesantemente eventual.

No lo use, si no almacena volúmenes de datos en grupos de clústeres, no lo utilice si no está almacenando datos de series de tiempo, no lo usa si no está implementando sus servidores, no lo use si necesita una consistencia fuerte.

Cassandra es la respuesta a un problema en particular: ¿qué haces cuando tienes tanta información que no cabe 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 datos comprimidos nuevos TODOS LOS DÍAS. Y es probable que este número crezca más de dos veces en un año.

Si no tiene esta cantidad de datos o si tiene millones para pagar 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 moviendo casi exclusivamente la partición en la pila de aplicaciones para un rendimiento más rápido y un mejor control.

Cassandra es una buena opción si:

No necesita las propiedades ACID de su base de datos.
Habría una cantidad enorme y enorme de escrituras en la base de datos.
Existe un requisito para integrarse con Big Data, Hadoop, Hive y Spark.
Existe una necesidad de análisis de datos en tiempo real y generación de informes.
Existe un requisito de un impresionante mecanismo tolerante a fallas.
Hay un requisito de sistema homogéneo.
Existe un requisito de mucha personalización para el ajuste.

Hablar con alguien en medio de la implementación de Cassandra no es bueno para muchos. Están haciendo un trabajo de hack para hacer su prueba inicial. Hablé con un asesor de Cassandra sobre esto y me dijo que no lo recomendaría si tuvieras este problema.

La idea general de NoSQL es que debe usar el almacén de datos que sea más adecuado para su aplicación. Si tiene una tabla de datos financieros, use SQL. Si tiene objetos que requieren consultas complejas / lentas para mapear a un esquema relacional, use un objeto o almacén de claves / valores.

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

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

Explican por qué no eligieron MySql porque la sincronización db es demasiado lenta.

Cassandra es como Amazon Dynamo y otra base de datos NoSQL de alta disponibilidad.

Funciones en estabilidad, alta disponibilidad. La copia de seguridad funciona lo más rápido posible. Lee y escribe

mejor que HBase , que también es un clon de BigTable. [wiki http://en.wikipedia.org/wiki/Apache_Cassandra]

La conclusión es:

We looked at HBase, Dynamo, Mongo and Cassandra. Cassandra was simply the best storage solution for the majority of our data.

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 las bases de datos relacionales. 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 selecciona su base de datos (NoSQL, NewSQL o RDBMS), observe qué problema está tratando de resolver y cuáles son sus necesidades de escalabilidad. Ninguna base de datos lo hace todo.

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é declaración de problema tiene y cuál es la mejor solución para ese problema.

Trataré de responder a sus preguntas una por una en el mismo orden en que las solicitó. 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 de ACID. Cuando se trata de NoSQL, la decisión se vuelve difícil debido a que cada base de datos NoSQL ofrece diferentes soluciones y usted debe entender cuál es la más adecuada para sus requisitos de aplicaciones / sistema. Por ejemplo, MongoDB es apto para casos de uso en los que su sistema exige una tienda de documentos sin esquema. HBase puede ser apropiado para motores de búsqueda, análisis de datos de registro o cualquier lugar donde escanear enormes tablas bidimensionales sin unión es un requisito. Redis está diseñado para proporcionar una variedad de estructuras de datos en la memoria, como árboles, colas, listas enlazadas, etc., y puede ser una buena opción para crear tablas de clasificación en tiempo real, tipo sub-pub. De manera similar, hay otras bases de datos en esta categoría (incluyendo Cassandra) que son aptas para diferentes declaraciones de problemas. Ahora pasemos a las preguntas originales y respóndelas una a una.

Cuándo usar Cassandra

Como 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 análisis web donde los datos de registro se almacenan para cada solicitud y desea construir una plataforma analítica a su alrededor para contar visitas por hora, por navegador, por IP, etc. en tiempo real. Puede consultar this publicación en el blog para comprender mejor los casos de uso en los que Cassandra se ajusta.

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 requerimiento de propiedades de ACID (por ejemplo, datos financieros), Cassandra no encajaría 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á a tiempo para comercializar mal. También administrar ese tipo de sistema con Cassandra sería complejo y tedioso para ti.

Cuándo no usar Cassandra

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

Otra situación que facilita la elección es cuando desea usar la función agregada 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 databse nosql a menos que use realmente muchos índices Invertidos. Cuando use nosql, deberá hacer las funciones agregadas en el código o almacenarlas por separado en su propia familia de columnas, pero esto lo hace todo bastante complejo y reduce el rendimiento que obtuvo al utilizar nosql.

Según DataStax, Cassandra no es el mejor caso de uso cuando hay una necesidad de

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

Si necesita una base de datos totalmente consistente con semántica de SQL, Cassandra NO es la solución para usted. Cassandra admite búsquedas de valores clave. No es compatible con consultas SQL. Los datos en Cassandra son "eventualmente consistentes". Las búsquedas concurrentes 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.

La consulta única 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 única consulta en un DB de estilo NoSql. Utilicé MongoDB y encontré problemas de rendimiento cuando intentaba calcular una consulta compleja. No he usado a 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 escalar fácilmente, puede aprovechar la consistencia eventual que ofrece la mayoría de los DB NoSql. Tenga en cuenta que la coherencia final no es realmente una característica de un modelo de datos no relacional, pero es mucho más fácil de implementar y configurar en un sistema basado en NoSql.

Para una única consulta, muy pesada, cualquier motor RDBMS moderno puede hacer un trabajo decente paralelizando partes de la consulta y aprovechar la mayor 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 permitan la 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 dividirlo manualmente en partes que el motor NoSql sabe cómo manejar inteligentemente.

En mi experiencia con MongoDB, al final debido a la complejidad de la consulta no había mucho que Mongo pudiera hacer para optimizarlo y ejecutar partes de él en múltiples datos. Mongo paraleliza múltiples consultas pero no es tan bueno para optimizar una sola.

No es compatible con la gestión completa de transacciones en todas las tablas.
Índice secundario no admitido.
Debe confiar en Elastic search / Solr para el índice secundario y el componente de sincronización personalizada debe escribirse.
No es compatible con el sistema ACID.
El soporte de consultas es limitado.