Cassandra em vez de MySQL para aplicativo de rede social

Question

Estou no meio da construção de um novo aplicativo que terá recursos muito semelhantes aos do Facebook e, embora obviamente nunca tenha que lidar com 400 bilhões de usuários, ainda será usado por uma base substancial de usuários e a maioria deles exigirá ele funciona muito rapidamente.

Tenho vasta experiência com MySQL, mas um aplicativo social oferece complexidades às quais o MySQL também não é adequado.Eu sei que o Facebook, o Twitter etc. mudaram para Cassandra para obter muitos de seus dados, mas não tenho certeza de até onde ir com isso.

Por exemplo, você armazenaria dados do usuário - nome de usuário, senhas, endereços, etc. no Cassandra?Você armazenaria e-mails, comentários, atualizações de status, etc. no Cassandra?Também li muito que algo como o neo4j é muito melhor para representar as relações de amizade usadas por aplicativos sociais, pois é um banco de dados gráfico.Estou apenas começando a rota do NoSQL, então qualquer orientação será muito apreciada.

Alguém poderia me aconselhar sobre isso?Espero não estar sendo muito genérico!

Answer 1

Por exemplo, você armazenaria dados do usuário - nome de usuário, senhas, endereços, etc. no Cassandra?

Não, pois não garante consistência.Cassandra é eventualmente consistente.Certamente não deveria haver simultaneidade nos dados de uma determinada conta de usuário, mas eu não gostaria de apostar nisso.Talvez você não precise de consistência em sua pesquisa de texto completo, caixa de entrada de mensagens, etc.mas você deseja consistência em tudo relacionado à segurança.

Também li muito que algo como o neo4j é muito melhor para representar as relações de amizade usadas por aplicativos sociais, pois é um banco de dados gráfico.

Sou um grande fã da ferramenta certa para o trabalho certo.Não usei o neo4j, mas tenho usado o db4o (que é um banco de dados de objetos) e acho-o muito útil.Torna o desenvolvimento mais fácil usar uma ferramenta que atenda nativamente às suas necessidades.Como você precisa de gráficos e trabalhar com gráficos em SQL é uma tarefa difícil, recomendo dar uma olhada e avaliar se ele atende às suas necessidades específicas.

Misturar bancos de dados me parece uma boa ideia, desde que a escolha seja natural (ou seja,o respectivo banco de dados é útil para trabalhos específicos, um banco de dados gráfico para gráficos, uma tabela para tabelas, bancos de dados ACID para qualquer coisa que precise de segurança nas transações, etc...).

Answer 2

Eu sugeriria fazer alguns testes com MySQL e Cassandra.Quando tivemos que escolher entre PostgreSQL e MongoDB em um de meus trabalhos, comparamos o tempo de consulta em milhões de registros em ambos e descobrimos que com cerca de 10 milhões de registros o Postgres nos forneceria tempos de resposta adequados.

Sabíamos que não chegaríamos a esse número de registros por pelo menos alguns anos e tínhamos experiência com Postgres (embora o MongoDB não estivesse muito maduro na época), então optamos pelo Postgres.

O que quero dizer é que você provavelmente pode observar os benchmarks do MySQL, fazer alguns testes de desempenho, estimar o tamanho do seu conjunto de dados e como ele crescerá e tomar uma decisão informada dessa forma.

Quanto a misturar bancos de dados relacionais e não relacionais, é algo que também consideramos, mas decidimos que seria muito trabalhoso, pois isso significaria manter dois tipos de software e escrever um pouco de código cola para obter o dados de ambos.Acho que Cassandra seria perfeitamente capaz de armazenar todos os seus dados.

Answer 3

Facebook não mover para Cassandra, eles o criaram.:) Que eu saiba, DBMSes noSQL não exigem ou mesmo mencionar (graças ao mnemosyn pela correção, o Facebook usa Oracle e Cassandra) rodando lado a lado com um banco de dados relacional. Esse é um exemplo oposto (armazenamento de informações do usuário em um banco de dados noSQL).

Eu diria que se Cassandra for boa o suficiente para o Facebook, provavelmente será boa o suficiente para o seu projeto.Pode não fazer mal tentar abstrair a lógica de persistência para que você tenha a possibilidade de mudar para outra coisa, se for o caso.

Isenção de responsabilidade:Eu (ainda?) não tive nenhuma experiência prática com bancos de dados noSQL:o que sei vem da leitura sobre isso.

Answer 4

Cassandra fornece uma boa solução distribuída e provavelmente melhor para uma plataforma semelhante ao Facebook do que MySQL (se for necessário escalar).Mas o Cassandra não é adequado para relacionamentos de dados onde você terá um desafio de relacionamento muitos-para-muitos.Um banco de dados gráfico vinculado ao Cassandra forneceria as necessidades de volume em massa, além de um recurso de consulta de relacionamento muito rápido.Estamos trabalhando em algo que combine as duas tecnologias, e sempre interessados ​​nos tipos de requisitos que sua plataforma apresentaria.Se você tiver alguma dúvida sobre como lidar com determinados problemas relacionados a dados, adoraria ouvi-la, talvez possamos ajudar a descobrir.