¿Por qué nosql con cassandra en lugar de mysql?

Question

Trabajo en una gran base de datos (cientos de GB) y Mysql ahora me da más o menos satisfacción. Dudo en cassandra en el lanzamiento.

Lo que quiero saber todo antes, por lo que este tipo de DBMS NoSQL se supone que es más rápido que MySQL?

varios puntos:

• El cambio en el número de columna de una fila en MySQL, todos ellos deben ser definidos con antelación. Las columnas se establecen en la estructura de la tabla. NoSQL en, se pueden variar. ¿Hay un rendimiento de diferencia real en una estructura fija? y por qué ?

• No haga que la relación sea beneficiosa para el rendimiento. Ok, pero no estoy obligado a hacer una tabla relacional Mysql. Utilizo tablas agregadas, es decir, tablas que contienen solo datos derivados de otras tablas, I para evitar las uniones demasiado caras. ¿De nuevo qué nivel de diferencia de rendimiento si uso este modelo en Mysql? Para tomar un ejemplo, el autor de http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/ inserte X veces el seguidor en el mensaje USERLINE empujador. Podría hacerlo en MySQL.

• Escalabilidad, escalabilidad, escalabilidad ... Me gusta, ¿me permite cassandra almacenar mis datos en diferentes servidores (sin SAN)? No estoy hablando aquí de replicación, hablo de un solo servidor NoSQL en múltiples servidores físicos.

• En vivo en los cálculos. MySQL proporciona funciones como SUM, AVG ... que son muy útiles para evitar que vuelva a agregar mis datos en otras tablas. No he visto el equivalente cassandra?

• ¿Qué pasa con los índices. En Mysql indexo varios campos en uno. Por ejemplo, mis tablas tienen una clave principal en varias columnas y selecciono están en funcional. Casandra sobre cómo escribirlo? ¿Concatenado para un identificador único para cada fila? Creo que no he captado por completo la gestión de los índices. ¿Se recalculan para la integración o en sentido ascendente?

• Las solicitudes asincrónicas. Un argumento falso que me parece, Mysql se puede hacer con INSERT/UPDATE LOW_PRIORITY.

Creo que voy por ahí. Gracias por iluminarme

Answer 1

Realmente no entiendo por qué las personas comparan proveedores de datos como Cassandra y MySQL juntos: realmente está comparando manzanas y naranjas aquí.

Sí, las soluciones de No SQL pueden dar un mejor rendimiento que SQL en algunos casos. Pero no se olvide de que el razón proporcionan esa velocidad: renuncian a varias de las comprobaciones que a menudo dan por sentado en SQL. Por ejemplo, no verá cosas como transacciones en un sistema NoSQL, ni tendrá los tipos de uniones y funciones de agregación de datos que obtiene como parte de un sistema SQL. Obtienes muy pocas garantías con respecto a la coherencia de los datos.

Para el 99% de las aplicaciones, simplemente no vale la pena el tiempo y el esfuerzo.Si eres Facebook o Twitter, donde tienes enormes cantidades de datos no estructurados, donde no te importa si realmente pierdes algunos datos en la barajadura de las cosas, o tienes retrasos con respecto a cuándo los datos están disponibles después de insertarlos, NoSQL está bien. Sin embargo, para la gran mayoría de las aplicaciones, aún debería seguir con SQL.

En cuanto a la escalabilidad, si un sitio enorme como Stack Overflow o Ebay puede ejecutarse sobre SQL, no veo por qué su aplicación no puede ejecutarse sobre SQL.

Answer 2

Sí, definitivamente puedes sintonizar un MySQL para darte rendimiento al reducir muchos de los gastos generales. NoSQL corta los gastos generales al no tener la función para habilitarlos en primer lugar.

Las aplicaciones de NoSQL son muy diferentes de la estructura SQL tradicional. Los SQL están sintonizados por defecto para el rendimiento de OLTP con estructuras de esquema normalizadas y la capacidad de tener consultas de combinación, etc. NoSQL, por otro lado, es una buena estructura de lectura/escritura rápida. Un buen ejemplo sería un feed de actividad en twitter/facebook (no sé si Twitter/FB usa NoSQL, solo estoy tomando un ejemplo).

Answer 3

playOrm está ayudando a que cada vez más sistemas OLTP entren en la cima de los sistemas no SQL. Es muy SQL pero hay diferencias. Necesita particionar tablas que espera crecer a tamaños MUY GRANDES y luego puede consultar en esas particiones. Incluso puedes hacer combinaciones en particiones. Mantiene sus tamaños de partición del mismo tamaño que las tablas RDBMS típicas y puede escalar según sus deseos.

por lo tanto, para sus preguntas de indexación y cálculo, creo que se construirán cada vez más herramientas en los sistemas nosql. De todos modos, esa puede ser una solución para sus problemas.