Mudar a partir do MySQL para Cassandra - Prós/Contras?

Question

Para um pouco de fundo esta questão trata de um projeto em execução em um único pequena instância EC2, e está prestes a migrar para uma média.Os principais componentes são o Django, MySQL e um grande número de análises personalizadas ferramentas de escrita em python e java, o que fazer pesados levantamento.A mesma máquina que está executando o Apache bem.

O modelo de dados se parece com o seguinte - uma grande quantidade de dados em tempo real vem em transmitido em rede de vários sensores, e idealmente, eu gostaria de estabelecer um tempo-enquete abordagem, em vez da atual consulta a cada 15 minutos abordagem (uma limitação de computação estatísticas e escrever no próprio banco de dados).Uma vez que os dados vem, eu store a versão-prima em MySQL, permitem a análise de ferramentas soltos sobre esses dados e armazenamento de estatísticas em algumas tabelas.Tudo isso é processado utilizando o Django.

Recursos relacionais eu precisaria -

• Ordem [SliceRange em Cassandra API parece satisy isso]
• Grupo
• Manytomany relações entre as várias tabelas [Cassandra SuperColumns parecem fazer bem para um-para-muitos]
• Esfinge sobre isso me dá um bom texto completo do motor, pois isso é uma necessidade também. [Em Cassandra, a Lucandra projeto parece satisfazer esta necessidade]

Meu grande problema é que lê dados são extremamente lentas (e escreve não são tão quente também).Eu não quero jogar um monte de dinheiro e hardware-lo agora, e eu prefiro algo que pode escalar facilmente com o tempo.Verticalmente escala MySQL não é trivial em que sentido (ou barato).

Então, basicamente, depois de ter lido muito sobre NOSQL e experimentou coisas como MongoDB, Cassandra e Voldemort, minhas perguntas são,

• Em uma média instância do EC2, será que eu ganho de quaisquer benefícios que lê/escreve deslocando-se para algo como Cassandra? Este artigo (pdf) definitivamente, parece sugerir que.Atualmente, eu diria que algumas centenas de gravações por minuto seria a norma.Para lê - desde as alterações de dados a cada 5 minutos ou assim, a invalidação do cache tem de acontecer muito rapidamente.Em algum ponto, ele deve ser capaz de lidar com um grande número de usuários simultâneos bem.O desempenho do aplicativo atualmente é morto no MySQL fazendo algumas associações em tabelas grandes, mesmo se os índices são criados, algo da ordem de 32 k linhas leva mais de um minuto para processar.(Isso pode ser um artefato do EC2 virtualizados e/S também).Tamanho das tabelas é de cerca de 4-5 milhões de linhas, e há cerca de 5 tais tabelas.

• Todo mundo fala sobre o uso de Cassandra em vários nós, dado o teorema CAP e consistência eventual.Mas, para um projeto que está apenas começando a crescer, faz sentido para implantar um nó de cassandra servidor?Há ressalvas?Por exemplo, ele pode substituir o MySQL como um back-end para o Django?[Isso é recomendado?]

• Se eu fizer a mudança, eu estou supondo que eu vou ter que reescrever partes do aplicativo para fazer muito mais "administrivia" desde que eu teria que fazer várias pesquisas para buscar linhas.

• Ele faria qualquer sentido usar o MySQL como um valor de chave de armazenamento de em vez de um mecanismo relacional, e ir com isso?De que maneira eu poderia utilizar um grande número estável de APIs disponíveis, bem como um estável do motor (e ir relacional, conforme necessário).(Brett Taylor post do Friendfeed no esta - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)

Insights de pessoas que fizeram uma mudança seria muito apreciado!

Obrigado.

Answer 1

Cassandra e a outras bases de dados distribuídas hoje disponíveis não fornecem o tipo de consulta ad-hoc apoio que vocês estão acostumados a partir do sql.Isso é porque você não pode distribuir consultas com associações performantly, por isso a ênfase está no denormalization em vez disso.

No entanto, Cassandra 0.6 (beta oficialmente para amanhã, mas você pode construir a partir de 0,6 ramo de si mesmo se você está impaciente) suporta o Hadoop mapear/reduzir para o google analytics, o qual, na verdade, soa como um bom ajuste para você.

Cassandra oferece um excelente suporte para a adição de novos nós de forma indolor, mesmo para um grupo inicial de um.

O que disse, em algumas centenas de gravações/minuto você está indo bem no mysql por um longo, longo tempo.Cassandra é muito melhor ser uma chave/valor store (ainda melhor, chave/columnfamily), mas o MySQL é muito melhor ser um banco de dados relacional.:)

Não há django suporte para Cassandra (ou outro banco de dados nosql) ainda.Eles estão falando sobre fazer algo para a próxima versão após 1.2, mas com base em falar com django devs na pycon, ninguém está realmente certo de que ficará ainda.

Answer 2

Se você é um desenvolvedor de banco de dados relacional (como eu sou), eu sugiro que/ponto de saída:

• Obter alguma experiência de trabalho com Cassandra antes de confirmar a sua utilização em um sistema de produção...especialmente se esse sistema de produção tem um disco rígido de prazo para a conclusão.Talvez usá-lo como o back-end para algo sem importância, em primeiro lugar.
• Ele está provando mais desafiador do que eu tinha previsto fazer coisas simples que eu tomamos para concedido sobre a manipulação de dados usando o SQL motores.Em particular, os dados de indexação e classificação de conjuntos de resultados não é algo trivial.
• Modelagem de dados provou um desafio bem.Como um desenvolvedor de banco de dados relacional você vem para a mesa com um monte de bagagem...você precisa estar disposto a aprender como para o modelo de dados de forma muito diferente.

Estas coisas disse, eu recomendo fortemente a construção de algo em Cassandra.Se você gosta de mim, então isso irá desafiar o seu entendimento de armazenamento de dados e fazer você repensar um banco de dados único para todas as situações-outlook que eu nem percebeu eu segurei.

Alguns bons recursos encontrei incluem:

• Dominic Williams Cassandra postagens do blog
• Índices secundários em Cassandra
• Mais de Ed Anuff na indexação
• Cassandra livro (a não ser fantástico, mas um bom começo)
• "WTF é um SuperColumn" em pdf

Answer 3

O Django-cassandra é uma versão beta do modo.Também o Django não feita por não-bancos de dados sql.A chave em Django ORM é baseado em SQL (Django recomenda o uso do PostgreSQL).Se você precisa usar SOMENTE não-sql (você pode misturar sql e não-sql no mesmo aplicativo) que você precisa para arriscado utilizar o no-sql ORM (é significativamente mais lento do que o tradicional SQL orm ou utilização directa da Não-SQL de armazenamento).Ou você precisará completamente cheio de reconfiguração de django ORM.Mas neste caso eu não posso presumir, por que você precisa de Django.Talvez você pode usar algo mais, como Tornados?