Cambiar de MySQL a Cassandra - Pros/Contras?

Question

Para tener un poco de contexto: esta pregunta se refiere a un proyecto que se ejecuta en una única instancia pequeña de EC2 y está a punto de migrar a una versión mediana. Los componentes principales son Django, MySQL y una gran cantidad de herramientas de análisis personalizadas escritas en python y java, que realizan el pesado proceso de elevación . La misma máquina ejecuta Apache también.

El modelo de datos tiene el siguiente aspecto: una gran cantidad de datos en tiempo real se transmiten desde diversos sensores de red, y idealmente, me gustaría establecer un enfoque de larga duración en lugar de la encuesta actual cada 15 minutos (una limitación de las estadísticas informáticas y la escritura en la base de datos en sí). Una vez que entran los datos, almaceno la versión en bruto en MySQL, dejo que las herramientas de análisis se pierdan en estos datos y almacene las estadísticas en otras pocas tablas. Todo esto se representa con Django.

características relacionales que necesitaría -

• Ordenar por [SliceRange en la API de Cassandra parece satisy esto]
• Grupo de
• las relaciones de muchos a muchos entre varias tablas [Cassandra SuperColumns parecen hacer bien para uno a muchos]
• Sphinx en esto me da un buen motor de texto completo, por lo que es una necesidad también. [En Cassandra, el proyecto Lucandra parece satisfacer esta necesidad]

Mi principal problema es que las lecturas de datos son extremadamente lento (y escrituras no son tan caliente tampoco). No quiero arrojar mucho dinero y hardware en este momento, y preferiría algo que pueda escalar fácilmente con el tiempo. Escalar verticalmente MySQL no es trivial en ese sentido (o es barato).

Así que, esencialmente, después de haber leído mucho sobre NoSQL y experimentado con cosas como MongoDB, Cassandra y Voldemort, mis preguntas son,

• En una instancia EC2 medio, qué gano ningún beneficio en lee/escribe al cambiar a algo como Cassandra? This article (pdf) definitivamente parece sugerir eso. Actualmente, diría que unos cientos de escrituras por minuto serían la norma. Para lecturas: dado que los datos cambian cada 5 minutos aproximadamente, la invalidación de la caché debe ocurrir bastante rápido. En algún momento, debería ser capaz de manejar una gran cantidad de usuarios concurrentes también. El rendimiento de la aplicación actualmente se elimina en MySQL haciendo algunas combinaciones en tablas grandes, incluso si se crean índices, algo del orden de 32k filas tarda más de un minuto en renderizarse. (Esto también puede ser un artefacto de E/S virtualizada EC2). El tamaño de las tablas es de alrededor de 4-5 millones de filas, y hay alrededor de 5 de esas tablas.

• Todo el mundo habla sobre el uso de Cassandra en múltiples nodos, dado el teorema CAP y la consistencia eventual. Pero, para un proyecto que recién comienza a crecer, tiene sentido desplegar un servidor de cassandra de un nodo? ¿Hay alguna advertencia? Por ejemplo, ¿puede reemplazar a MySQL como back-end para Django? [¿Es esto recomendable?]

• Si cambio, supongo que tendré que volver a escribir partes de la aplicación para hacer mucho más "administrivia" ya que tendría que hacer múltiples búsquedas para buscar filas .

• ¿Tendría algún sentido sólo tiene que utilizar MySQL como un almacén de valor clave en lugar de un motor relacional, e ir con eso? De esa forma podría utilizar una gran cantidad de API estables disponibles, así como también un motor estable (e ir relacional según sea necesario). (Post de Brett Taylor de Friendfeed en esto - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)

Cualquier ideas de la gente que ha hecho un cambio sería muy apreciada!

Gracias.

Answer 1

Cassandra y las otras bases de datos distribuidas disponibles hoy en día no proporcionan el tipo de soporte de consultas ad-hoc al que está acostumbrado desde sql. Esto se debe a que no puede distribuir consultas con combinaciones de manera performante, por lo que se hace hincapié en la desnormalización.

Sin embargo, Cassandra 0.6 (beta oficialmente saldrá mañana, pero puedes construir desde la rama 0.6 si estás impaciente) es compatible con Hadoop map/reduce para análisis, que realmente suena como una buena opción para ti.

Cassandra proporciona una excelente compatibilidad para agregar nuevos nodos sin dolor, incluso a un grupo inicial de uno.

Dicho esto, en unos pocos cientos de escrituras/minuto estarás bien en mysql durante mucho, mucho tiempo. Cassandra es mucho mejor en ser una tienda clave/valor (incluso mejor, key/columnfamily) pero MySQL es mucho mejor en ser una base de datos relacional. :)

Aún no hay soporte django para Cassandra (u otra base de datos nosql). Están hablando de hacer algo para la próxima versión después del 1.2, pero basado en hablar con desarrolladores de django en Pycon, nadie está realmente seguro de cómo será.

Answer 2

Si eres un desarrollador de bases de datos relacionales (como yo), me gustaría sugerir/señalar:

• conseguir un poco de experiencia de trabajo con Cassandra antes de comprometerse a su uso en un sistema de producción .. especialmente si ese sistema de producción tiene una fecha límite difícil para su finalización. Tal vez usarlo como back-end para algo sin importancia primero.
• Está resultando más desafiante de lo que había previsto hacer cosas simples que doy por hecho acerca de la manipulación de datos usando motores SQL. En particular, los datos de indexación y los conjuntos de resultados de clasificación no son triviales.
• El modelado de datos también ha sido un desafío. Como desarrollador de bases de datos relacionales, usted llega a la mesa con un montón de equipaje ... debe estar dispuesto a aprender a modelar los datos de forma muy diferente.

Estas cosas dijo, os recomiendo la construcción de algo en Cassandra. Si eres como yo, hacerlo desafiará tu comprensión del almacenamiento de datos y te hará reconsiderar una perspectiva de base de datos relacional para todas las situaciones que ni siquiera sabía que tenía.

Algunos buenos recursos que he encontrado son:

• Dominic Williams' Cassandra blog posts
• Secondary Indexes in Cassandra
• More from Ed Anuff on indexing
• Cassandra book (not fantastic, but a good start)
• "WTF is a SuperColumn" pdf

Answer 3

El Django-cassandra es un modo beta temprano. También Django no hizo para las bases de datos sin sql. La clave en Django ORM se basa en SQL (Django recomienda utilizar PostgreSQL). Si necesita utilizar SOLAMENTE no-sql (puede mezclar SQL y no-SQL en la misma aplicación), debe utilizar ORM sin SQL de forma arriesgada (es significativamente más lento que el orm SQL tradicional o el uso directo de almacenamiento sin SQL). O necesitarás reescribir completamente el django ORM. Pero en este caso no puedo suponer, por qué necesita Django. ¿Tal vez puedas usar algo más, como Tornado?