Quando NÃO usar Cassandra?


199

Ultimamente tem havido muita conversa relacionada a Cassandra .

Twitter, Digg, Facebook, etc, todos usam.

Quando faz sentido:

  • use Cassandra,
  • não use Cassandra e
  • use um RDMS em vez de Cassandra.

7
Provavelmente deve ser CW? Isso é basicamente apenas bancos de dados NoSQL x Relacional, que é IMO bastante subjetivo.
Ed James

3
Gostaria de saber se é adequado para o sistema de mensagens. Suponho que se o Twitter usá-lo, então tudo bem, mas eles podem não usá-lo para todo o Twitter?
Lucas

Respostas:


164

Não há nada como uma bala de prata, tudo é construído para resolver problemas específicos e tem seus próprios prós e contras. Depende de você, qual é a declaração do problema e qual é a melhor solução adequada para esse problema.

Tentarei responder suas perguntas uma a uma na mesma ordem em que você as fez. Como o Cassandra é baseado na família de bancos de dados NoSQL, é importante que você entenda por que usar um banco de dados NoSQL antes de responder suas perguntas.

Por que usar o NoSQL

No caso do RDBMS, fazer uma escolha é bastante fácil, porque todos os bancos de dados como MySQL, Oracle, MS SQL e PostgreSQL nesta categoria oferecem quase o mesmo tipo de soluções orientadas para propriedades ACID. Quando se trata de NoSQL, a decisão se torna difícil, porque cada banco de dados NoSQL oferece soluções diferentes e você precisa entender qual é o mais adequado para os requisitos de aplicativo / sistema. Por exemplo, o MongoDB é adequado para casos de uso em que seu sistema exige um armazenamento de documentos sem esquema. O HBase pode ser adequado para mecanismos de pesquisa, análise de dados de log ou qualquer local onde a digitalização de grandes tabelas bidimensionais sem junção seja necessária. O Redis foi desenvolvido para fornecer pesquisa na memória por variedades de estruturas de dados como árvores, filas, listas vinculadas etc. e pode ser uma boa opção para criar tabelas de classificação em tempo real, tipo de sistema pub-sub. Da mesma forma, existem outros bancos de dados nesta categoria (incluindo Cassandra) que são adequados para diferentes declarações de problemas. Agora vamos passar para as perguntas originais e respondê-las uma a uma.

Quando usar Cassandra

Como parte da família NoSQL, o Cassandra oferece uma solução para problemas em que um de seus requisitos é ter um sistema de gravação muito pesado e você deseja ter um sistema de relatórios bastante responsivo sobre os dados armazenados. Considere o caso de uso da análise da Web, em que os dados de log são armazenados para cada solicitação e você deseja criar uma plataforma analítica em torno deles para contar os hits por hora, pelo navegador, pelo IP etc. em tempo real. Você pode consultar esta postagem do blog para entender mais sobre os casos de uso em que Cassandra se encaixa.

Quando usar um RDMS em vez de Cassandra

Cassandra é baseado em um banco de dados NoSQL e não fornece ACID e propriedades de dados relacionais. Se você possui um forte requisito para propriedades ACID (por exemplo, dados financeiros), o Cassandra não seria adequado nesse caso. Obviamente, você pode fazer uma solução alternativa para isso, no entanto, você acabará escrevendo muito código do aplicativo para simular propriedades do ACID e perderá tempo no mercado mal. Também gerenciar esse tipo de sistema com Cassandra seria complexo e tedioso para você.

Quando não usar Cassandra

Acho que não precisa ser respondido se a explicação acima fizer sentido.


1
O problema com a resposta é que ele reúne todas as soluções NoSQL. Consulte dataconomy.com/sql-vs-nosql-need-know para obter mais informações. No cenário NoSQL, as divisões básicas são documento, valor-chave, gráfico e tabela grande. Eles têm características diferentes para diferentes problemas. Uma solução adequada para o mongo pode não ser adequada para o cassandra.
Yehosef 08/02

17
A única maneira de essa resposta "agrupar todas as soluções NoSQL" é pela categoria NoSQL; além disso, o post faz um ótimo trabalho em apontar que cada banco de dados NoSQL "oferece uma solução diferente" para problemas diferentes. Não tive a sensação de que o autor sugerisse levemente que o mongo, cassandra ou qualquer outro banco de dados NoSQL resolvesse os mesmos problemas.
Nick Suwyn

NoSQL databasenão é uma coisa. NoSQLé apenas um termo usado para bancos de dados não relacionais modernos (consulte o wiki ).
EddyP23 08/09/16

2
Além disso, observe que nem todos os bancos de dados NoSQL não são ACID. Os DBs do gráfico são geralmente ACID.
EddyP23 08/09/16

O Cassandra suporta operação atômica no nível de linha e Atômica e Isolamento por partição usando transações leves. Se meu requisito é ter o ACID no nível da linha, não posso usar o Cassandra? Mesmo para dados críticos?
TechEnthusiast

52

Ao avaliar sistemas de dados distribuídos, é necessário considerar o teorema do CAP - você pode escolher dois dos seguintes itens: consistência, disponibilidade e tolerância de partição.

Cassandra é um sistema tolerante a partições disponível que suporta consistência eventual. Para obter mais informações, consulte este post do blog que escrevi: Guia Visual para Sistemas NoSQL .


Quando foi a última vez que você viu uma partição em que ambas eram grandes? Veja minha pergunta stackoverflow.com/questions/7969874/…
Aaron Watters

5
Cassandra também aparentemente permite que você especifique a sua exigência de consistência na consulta tempo, o que pode ser um compromisso útil para alguns casos de uso
Richard Marr

30

Cassandra é a resposta para um problema específico: o que você faz quando possui tantos dados que não cabem em um servidor? Como você armazena todos os seus dados em muitos servidores e não quebra sua conta bancária e não deixa seus desenvolvedores loucos? O Facebook recebe 4 Terabytes de novos dados compactados TODOS OS DIAS. E esse número provavelmente crescerá mais de duas vezes dentro de um ano.

Se você não tiver tantos dados ou se tiver milhões para pagar pela instalação do cluster Enterprise Oracle / DB2 e especialistas necessários para configurá-los e mantê-los, estará bem com o banco de dados SQL.

No entanto, o Facebook não usa mais o cassandra e agora usa o MySQL quase exclusivamente movendo o particionamento para cima na pilha de aplicativos para obter desempenho mais rápido e melhor controle.


27

A idéia geral do NoSQL é que você deve usar o armazenamento de dados que melhor se adequar ao seu aplicativo. Se você tiver uma tabela de dados financeiros, use SQL. Se você tiver objetos que exigiriam consultas complexas / lentas para mapear para um esquema relacional, use um objeto ou armazenamento de chave / valor.

É claro que praticamente qualquer problema do mundo real em que você se encontra está entre esses dois extremos e nenhuma solução será perfeita. Você precisa considerar os recursos de cada loja e as consequências de usar um sobre o outro, que serão muito específicos para o problema que você está tentando resolver.


3
É improvável que o esquema mude, ele se encaixa bem em uma estrutura de tabela e dados perdidos / inconsistentes podem causar problemas reais.
Tom Clarkson

4
Não entendo por que dados inconsistentes podem causar problemas reais nos bancos. Cenário: você tem uma conta bancária, com US $ 100 acima do limite e dois cartões bancários. Ao tentar sacar dinheiro com os dois cartões ao mesmo tempo em 2 caixas eletrônicos diferentes, você receberá 2 vezes US $ 100 e uma carta com uma taxa extra em sua caixa postal. O banco ganha dinheiro (a taxa extra por estar abaixo do limite) usando dados inconsistentes. É difícil conectar todos os caixas eletrônicos do mundo através de um grande banco de dados relacional. Você pode dar um exemplo em que dados financeiros inconsistentes podem ser um problema?
Paco

5
Esse material é todo COBOL e processamento em lote, e não tão bem projetado / estável quanto você imagina. Os caixas eletrônicos não se conectam a nenhum tipo de armazenamento de dados unificado; portanto, dificilmente são um exemplo adequado. É como dizer que o SQL não é adequado para aplicativos da Web porque você não pode dar a todos na Internet acesso direto ao seu banco de dados. Além disso, nunca disse nada sobre bancos - pense em pedidos em um site de comércio eletrônico em que você não precisa lidar com uma organização tão conservadora que o SQL seja considerado novo e não confiável.
Tom Clarkson

6
@Paco: O primeiro caixa eletrônico lê seu saldo (US $ 100) e o segundo caixa eletrônico faz o mesmo. Ambos os caixas eletrônicos deduzem US $ 100 de US $ 100 e gravam o saldo final de US $ 0 na sua conta. Resultado: o banco perde US $ 100.
Seun Osewa

9
@Paco: O ponto é que, sem o isolamento adequado da transação, o banco normal nem saberá que a conta foi excedida. Eles nem vão saber.
Seun Osewa

14

Além das respostas dadas acima sobre quando usar e quando não usar o Cassandra, se você decidir usá-lo, considere não usar o próprio Cassandra, mas um dos seus primos por aí.

Algumas respostas acima já apontaram para vários sistemas "NoSQL" que compartilham muitas propriedades com o Cassandra, com algumas diferenças pequenas ou grandes, e podem ser melhores que o próprio Cassandra para suas necessidades específicas.

Além disso, recentemente (vários anos após a pergunta inicial), um clone de Cassandra chamado Scylla (consulte https://en.wikipedia.org/wiki/Scylla_(database ) foi lançado. O Scylla é uma reimplementação de código-fonte aberto do Cassandra em C ++, que afirma ter uma taxa de transferência significativamente mais alta e latências mais baixas que o Java Cassandra original, embora seja principalmente compatível com ele (em recursos, APIs e formatos de arquivo). Portanto, se você já está considerando Cassandra, também pode considerar Scylla.


9

Conversando com alguém no meio da implantação do Cassandra, ele não lida bem com muitos para muitos. Eles estão fazendo um trabalho de hack para fazer seus testes iniciais. Conversei com um consultor da Cassandra sobre isso e ele disse que não recomendaria se você tivesse esse problema definido.


4

Você deve fazer as seguintes perguntas:

  1. (Volume, velocidade) Você estará escrevendo e lendo toneladas de informações, tantas informações que nenhum computador pode lidar com as gravações.
  2. (Global) Você precisará desse recurso de escrita e leitura em todo o mundo para que as gravações em uma parte do mundo sejam acessíveis em outra parte do mundo?
  3. (Confiabilidade) Você precisa que esse banco de dados esteja em funcionamento o tempo todo e nunca seja desativado, independentemente de qual nuvem, qual país, seja VM, contêiner ou metal nu?
  4. (Capacidade de escala) Você precisa deste banco de dados para poder continuar crescendo facilmente e dimensionar linearmente
  5. (Consistência) Você precisa da consistência TUNABLE em que algumas gravações podem ocorrer de forma assíncrona, enquanto outras precisam ser certificadas?
  6. (Habilidade) Você está disposto a fazer o necessário para aprender essa tecnologia e a modelagem de dados que acompanha a criação de um banco de dados distribuído globalmente que possa ser rápido para todos, em qualquer lugar?

Se, em alguma dessas perguntas, você pensou "talvez" ou "não", deveria usar outra coisa. Se você teve "inferno sim" como resposta para todos eles, então você deve usar Cassandra.

Use RDBMS quando você puder fazer tudo em uma caixa. Provavelmente é mais fácil do que a maioria e qualquer pessoa pode trabalhar com isso.


3

Consulta única pesada versus carga de consulta leve de gazilhões é outro ponto a considerar, além de outras respostas aqui. É inerentemente mais difícil otimizar automaticamente uma única consulta em um banco de dados no estilo NoSql. Eu usei o MongoDB e tive problemas de desempenho ao tentar calcular uma consulta complexa. Eu não usei Cassandra, mas espero que ele tenha o mesmo problema.

Por outro lado, se sua carga é esperada para muitas consultas pequenas e você deseja escalar facilmente, você pode tirar proveito da consistência eventual oferecida pela maioria dos DBs NoSql. Observe que a consistência eventual não é realmente um recurso de um modelo de dados não relacionais, mas é muito mais fácil de implementar e configurar em um sistema baseado no NoSql.

Para uma consulta única e muito pesada, qualquer mecanismo RDBMS moderno pode fazer um trabalho decente paralelizando partes da consulta e aproveitar a quantidade de CPU e memória que você coloca nela (em uma única máquina). Os bancos de dados NoSql não têm informações suficientes sobre a estrutura dos dados para poder fazer suposições que permitirão uma paralelização verdadeiramente inteligente de uma grande consulta. Eles permitem escalar facilmente mais servidores (ou núcleos), mas quando a consulta atinge um nível de complexidade, você é basicamente forçado a dividi-la manualmente em partes com as quais o mecanismo NoSql sabe lidar de maneira inteligente.

Na minha experiência com o MongoDB, no final, devido à complexidade da consulta, não havia muito que o Mongo pudesse fazer para otimizá-lo e executar partes dele em vários dados. O Mongo paralela várias consultas, mas não é tão bom em otimizar uma única.


3

Vamos ler alguns casos do mundo real:

http://planetcassandra.org/apache-cassandra-use-cases/

Neste artigo: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Eles elaboraram a razão pela qual não escolheram o MySql, porque a sincronização do banco de dados é muito lenta.

(Também devido ao commit de duas frases, FK, PK)


Cassandra é baseado no papel Amazon Dynamo

Recursos:

Estabilidade

Alta disponibilidade

O backup funciona bem

A leitura e gravação é melhor que o HBase, (clone do BigTable em java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Sua conclusão é:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

A partir de 2018,

Eu recomendaria o uso do ScyllaDB para substituir o cassandra clássico, se você precisar de suporte de volta.

O plugin Postgres kv também é rápido que o cassandra. No entanto, nunca haverá escalabilidade em várias instâncias.


Você não precisa se contentar com apenas uma tecnologia de banco de dados. Você pode ter um combo e usar o que for apropriado para o problema específico.
Pepito Fernandez 12/10

3

Vou me concentrar aqui em alguns dos aspectos importantes que podem ajudá-lo a decidir se você realmente precisa de Cassandra. A lista não é exaustiva, apenas alguns dos pontos que tenho no topo da minha mente:

  • Não considere Cassandra como a primeira escolha quando você tiver um requisito estrito no relacionamento (em todo o conjunto de dados).

  • Cassandra por padrão é o sistema AP (do CAP). Mas, ele suporta consistência ajustável, o que significa que também pode ser configurado para suportar o CP. Portanto, não o ignore apenas porque você lê em algum lugar que é AP e está procurando por sistemas de CP. O Cassandra é denominado com mais precisão de “consistência sintonizável”, o que significa que permite que você decida facilmente o nível de consistência necessário, em equilíbrio com o nível de disponibilidade.

  • Não use o Cassandra se sua balança não for grande ou se você puder lidar com um banco de dados não distribuído.

  • Pense mais se sua equipe pensa que todos os seus problemas serão resolvidos se você usar DBs distribuídos como Cassandra. Para começar com esses bancos de dados, é muito simples, pois é fornecido com muitos padrões, mas otimizá-lo e dominá-lo para resolver um problema específico exigiria uma boa (se não muita) quantidade de esforço de engenharia.

  • Cassandra é orientado a colunas, mas ao mesmo tempo cada linha também possui uma chave exclusiva. Portanto, pode ser útil pensar nele como uma loja indexada e orientada a linhas. Você pode até usá-lo como uma loja de documentos.

  • Cassandra não força você a definir os campos de antemão. Portanto, se você estiver no modo de inicialização ou seus recursos estiverem evoluindo (como no ágil) - Cassandra o adota. Então, melhor, pense primeiro em consultas e depois em dados para respondê-las.

  • Cassandra é otimizado para um rendimento realmente alto em gravações. Se o seu caso de uso for pesado para leitura (como cache), o Cassandra pode não ser a escolha ideal.


2

Outra situação que facilita a escolha é quando você deseja usar funções agregadas como sum, min, max, etcetera e consultas complexas (como no sistema financeiro mencionado acima), um banco de dados relacional provavelmente é mais conveniente que um banco de dados nosql, pois ambos são não é possível em um banco de dados nosql, a menos que você use realmente muitos índices invertidos. Quando você usa o nosql, precisa executar as funções agregadas no código ou armazená-las separadamente em sua própria família de colunas, mas isso torna tudo bastante complexo e reduz o desempenho obtido com o uso do nosql.


O CouchdB, por exemplo, permite calcular funções agregadas com muita facilidade: wiki.apache.org/couchdb/… . Tecnicamente, isso está "no código", mas não é tão "complexo" para ser realizado como seria com Cassandra.
user359996

2
Na verdade, concordo que pode levar um dia para você escrever um código agregado, mas você pode escrevê-lo para rodar em um servidor back-end que utilizará quase 0 ciclos do banco de dados. Com um banco de dados SQL, você obtém o resultado escrevendo uma linha, o que pode levar 5 minutos. mas diminuirá o banco de dados inteiro toda vez que você o executar. Portanto, existem prós e contras nos dois sentidos. Meu banco, por exemplo, fecha todos os acessos ao site no meio da noite por cerca de 10 a 15 minutos. Certamente eles estão usando COBOL, mas esse é um problema muito semelhante.
Alexis Wilke

1

Se você precisar de um banco de dados totalmente consistente com semântica SQL, o Cassandra NÃO é a solução para você. Cassandra suporta pesquisas de valores-chave. Não suporta consultas SQL. Os dados no Cassandra são "eventualmente consistentes". Pesquisas simultâneas de dados podem ser inconsistentes, mas eventualmente as pesquisas são consistentes.

Se você precisar de semântica estrita e precisar de suporte para consultas SQL, escolha outra solução como MySQL, PostGres ou combine o uso do Cassandra com o Solr.


1
A Cassandra Query Language (CQL) é bastante semelhante ao SQL, no entanto. Na verdade, eu diria que o CQL é uma vantagem do Cassandra sobre outras opções NoSQL para quem procura uma interface semelhante ao SQL.
precisa saber é o seguinte

1
Cassandra não é tecnicamente eventualmente consistente. O Cassandra permite trocar a consistência pela disponibilidade. Cassandra está basicamente equilibrando o teorema da PAC. Você pode eventualmente ter gravação consistente e, em seguida, ler consistentemente, vice-versa ou consistente em ambos, e tudo isso depende do fator de replicação combinado ao seu nível de leitura / gravação. Eu recebi a resposta colocou "eventualmente consistente" entre aspas provavelmente por esse motivo, mas sinto que há alguma clareza em ordem.
tsturzl

1

Cassandra é uma boa escolha se:

  1. Você não precisa das propriedades ACID do seu banco de dados.

  2. Haveria um número enorme e enorme de gravações no banco de dados.

  3. É necessário integrar-se ao Big Data, Hadoop, Hive e Spark.

  4. Há uma necessidade de análise de dados em tempo real e geração de relatórios.

  5. Há um requisito de mecanismo impressionante tolerante a falhas.

  6. Há um requisito de sistema homogêneo.

  7. Há um requisito de muita personalização para ajuste.


0

O Mongodb possui funções agregadas muito poderosas e uma estrutura agregada expressiva. Ele tem muitos dos recursos que os desenvolvedores estão acostumados a usar no mundo dos bancos de dados relacionais. Sua estrutura de dados / armazenamento de documentos permite modelos de dados mais complexos que o Cassandra, por exemplo.

Tudo isso vem com compensações, é claro. Portanto, quando você seleciona seu banco de dados (NoSQL, NewSQL ou RDBMS), observe qual problema você está tentando resolver e suas necessidades de escalabilidade. Nenhum banco de dados faz tudo.


0

De acordo com o DataStax, o Cassandra não é o melhor caso de uso quando há necessidade de

1- Dispositivos de hardware avançados. 2- ACID compatível sem reversão (transação bancária)


0
  • Ele não oferece suporte ao gerenciamento completo de transações entre as tabelas.
  • Índice secundário não suportado.
  • É necessário confiar na pesquisa Elastic / Solr para índice secundário e o componente de sincronização personalizado deve ser gravado.
  • Sistema não compatível com ACID.
  • O suporte à consulta é limitado.

0

O Apache cassandra é um banco de dados distribuído para gerenciar grandes quantidades de dados estruturados em muitos servidores comuns, enquanto fornece serviço altamente disponível e nenhum ponto único de falha.

A arquitectura é puramente baseada no teorema da tampa, que é a disponibilidade e a tolerância da partição e, curiosamente, eventualmente consistente.

Não use, se você não estiver armazenando volumes de dados em racks de clusters, Não use se você não estiver armazenando dados de séries temporais, Não use se você não estiver configurando seus servidores, Não use se precisar de consistência forte.


A consistência forte garante, um servidor sempre grava e todas as leituras fornecem as mais recentes.
Remario
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.