Probablemente debería ser CW? Esto es prácticamente solo NoSQL vs bases de datos relacionales, que es bastante IMO subjetiva.
Ed James
3
Me gustaría saber si es adecuado para el sistema de mensajería. Supongo que si Twitter lo usa, entonces estaría bien, sin embargo, ¿podrían no usarlo para todo Twitter?
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.
El problema con la respuesta es que agrupa todas las soluciones NoSQL. Consulte dataconomy.com/sql-vs-nosql-need-know para obtener más información. En el panorama NoSQL, las divisiones básicas son documento, clave-valor, gráfico y tabla grande. Tienen diferentes características para diferentes problemas. Una solución que sea buena para Mongo puede no ser buena para Cassandra.
Yehosef
17
La única forma en que esta respuesta "agrupa todas las soluciones NoSQL" es por la categoría NoSQL; Aparte de eso, la publicación hace un gran trabajo al señalar que cada base de datos NoSQL "ofrece una solución diferente" para diferentes problemas. No tuve la sensación de que el autor incluso insinuó un poco que Mongo, Cassandra o cualquier otra base de datos NoSQL resuelvan los mismos problemas.
Nick Suwyn
NoSQL databaseno es una cosa NoSQLes solo un término utilizado para bases de datos modernas no relacionales (ver wiki ).
eddyP23
2
Además, tenga en cuenta que no todas las bases de datos NoSQL no son ACID. Los DB de gráficos son generalmente ACID.
eddyP23
Cassandra admite operación atómica a nivel de fila y Atómica y aislamiento por partición utilizando transacciones de peso ligero. Si mi requisito es tener ACID a nivel de fila, ¿no puedo usar Cassandra? ¿Incluso para datos críticos?
Entusiasta tecnológico
52
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 .
Al parecer, Cassandra también le permite especificar su requisito de coherencia en el momento de la consulta, lo que puede ser un compromiso útil para algunos casos de uso
Richard Marr
30
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.
Es poco probable que el esquema cambie, se ajusta bien en una estructura de tabla y los datos perdidos / inconsistentes podrían causar problemas reales.
Tom Clarkson el
44
No entiendo por qué los datos inconsistentes pueden causar problemas reales con los bancos. Escenario: tiene una cuenta bancaria, con $ 100 por encima del límite, y dos tarjetas bancarias. Cuando intente retirar dinero con las dos tarjetas al mismo tiempo en 2 cajeros automáticos diferentes, recibirá 2 veces $ 100 y una carta con una tarifa adicional en su casilla de correo. El banco gana dinero (la tarifa adicional por estar por debajo del límite) al usar datos inconsistentes. Es difícil conectar todos los cajeros automáticos del mundo entre sí a través de una gran base de datos relacional. ¿Puede dar un ejemplo donde los datos financieros inconsistentes pueden ser un problema?
Paco
55
Todo eso es COBOL y procesamiento por lotes, y no tan bien diseñado / estable como podría pensar. Los cajeros automáticos no se conectan a ningún tipo de almacén de datos unificado, por lo que no son un ejemplo adecuado. Es como decir que SQL no es adecuado para aplicaciones web porque no puede dar a todos en Internet acceso directo a su base de datos. Además, nunca dije nada sobre los bancos: piense cosas como pedidos en un sitio de comercio electrónico donde no tiene que tratar con una organización tan conservadora que SQL se considera nuevo y no confiable.
Tom Clarkson el
66
@Paco: el primer cajero automático lee su saldo ($ 100), y el segundo cajero automático hace lo mismo. Ambos cajeros automáticos deducen $ 100 de $ 100 y devuelven el saldo final de $ 0 a su cuenta. Resultado: el banco pierde $ 100.
Seun Osewa 01 de
9
@Paco: El punto es que, sin un aislamiento de transacción adecuado, el banco normal ni siquiera sabrá que la cuenta ha sido sobregirada. Ni siquiera lo sabrán.
Seun Osewa
14
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.
(Volumen, velocidad) ¿Escribirás y leerás TONELADAS de información, tanta información que ninguna computadora podría manejar las escrituras?
(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?
(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?
(Capacidad de escala) ¿Necesita esta base de datos para poder seguir creciendo fácilmente y escalar linealmente?
(Consistencia) ¿Necesita consistencia TUNABLE donde algunas escrituras pueden ocurrir de forma asíncrona donde otras necesitan ser certificadas?
(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.
No tiene que conformarse con una sola tecnología de base de datos. En realidad, puede tener un combo y usar el que sea apropiado para el problema específico.
Pepito Fernández
3
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.
CouchdB, por ejemplo, permite calcular funciones agregadas muy fácilmente: wiki.apache.org/couchdb/… . Técnicamente, esto está "en código", pero no es tan "complejo" de lograr como lo sería con Cassandra.
user359996
2
En realidad, estoy de acuerdo en que puede llevarle un día escribir un agregado en el código, pero puede escribirlo para ejecutarlo en un servidor de fondo que utilizará cerca de 0 ciclos de la base de datos. Con una base de datos SQL, obtendrá el resultado escribiendo una línea que puede llevarle 5 minutos. pero ralentizará toda la base de datos cada vez que la ejecute. Así que hay ventajas y desventajas en ambos sentidos. Mi banco, por ejemplo, cierra todos los accesos al sitio web en medio de la noche durante aproximadamente 10 a 15 minutos. Ciertamente están usando COBOL, pero ese es un problema muy similar.
Alexis Wilke
1
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.
Sin embargo, Cassandra Query Language (CQL) es bastante similar a SQL. De hecho, diría que CQL es una ventaja de Cassandra sobre otras opciones NoSQL para aquellos que buscan una interfaz similar a SQL.
arussell84
1
Cassandra no es técnicamente consistente al final. Cassandra le permite intercambiar consistencia por disponibilidad. Cassandra está básicamente equilibrando el teorema de CAP. Con el tiempo, puede tener una escritura consistente y luego leer de manera consistente, viceversa o consistente en ambos, y todo esto depende de su factor de replicación combinado con su nivel de lectura / escritura. Me parece que la respuesta puso "eventualmente consistente" entre comillas probablemente por esta razón, pero siento que es necesario un poco de claridad.
tsturzl
1
Cassandra es una buena opción si:
No necesita las propiedades ACID de su base de datos.
Habría una gran cantidad de escrituras en la base de datos.
Hay un requisito para integrarse con Big Data, Hadoop, Hive y Spark.
Existe la necesidad de análisis de datos en tiempo real y generación de informes.
Hay un requisito de mecanismo impresionante de tolerancia a fallas.
Hay un requisito de sistema homogéneo.
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.
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.
Respuestas:
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.
fuente
NoSQL databaseno es una cosaNoSQLes solo un término utilizado para bases de datos modernas no relacionales (ver wiki ).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 .
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
Debes hacerte las siguientes preguntas:
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.
fuente
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.
fuente
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:
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.
fuente
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.
fuente
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.
fuente
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.
fuente
Cassandra es una buena opción si:
No necesita las propiedades ACID de su base de datos.
Habría una gran cantidad de escrituras en la base de datos.
Hay un requisito para integrarse con Big Data, Hadoop, Hive y Spark.
Existe la necesidad de análisis de datos en tiempo real y generación de informes.
Hay un requisito de mecanismo impresionante de tolerancia a fallas.
Hay un requisito de sistema homogéneo.
Hay un requisito de mucha personalización para el ajuste.
fuente
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.
fuente
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)
fuente
fuente
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.
fuente