Última atualização: 24/07/2026
O Apache Cassandra é um banco de dados NoSQL distribuído e de código aberto, projetado para lidar com grandes volumes de dados em vários servidores. A arquitetura descentralizada elimina pontos únicos de falha, o que o torna uma escolha confiável para cargas de trabalho de alta disponibilidade e com muita gravação, que precisam permanecer on-line, independentemente de interrupções de nós ou data centers.
Os engenheiros do Facebook (agora Meta), Avinash Lakshman e Prashant Malik, criaram o Cassandra para fomentar a pesquisa da caixa de entrada do Facebook. Eles precisavam de um sistema que pudesse armazenar e pesquisar conjuntos de dados enormes em vários servidores sem perder velocidade.
Para criá-lo, a equipe se inspirou em dois outros modelos de banco de dados estabelecidos: combinou o modelo de armazenamento de colunas amplas do artigo Bigtable de 2006 do Google com a arquitetura de anel distribuído do Dynamo da Amazon. Eles deram ao projeto o nome da profetisa troiana da mitologia, uma referência à "maldição" de fazer previsões que os outros não acreditavam.
O projeto evoluiu rapidamente à medida que seu potencial ficou claro para a comunidade de engenharia:
Devido ao seu legado, muitas empresas confiam nele para alimentar os próprios sistemas. Embora o Cassandra continue sendo uma escolha comprovada para sistemas de alta disponibilidade, avaliar as vantagens e desvantagens do design ajuda as equipes a decidir se o autogerenciamento de uma arquitetura legada atende às necessidades dos aplicativos modernos.
O Cassandra costuma ser usado para trabalhos que envolvem um fluxo constante de dados, como informações de sensores inteligentes (IoT), registro de aplicativos e pipelines de monitoramento. Além disso, é muito usado para rastreamento de eventos e sistemas de recomendação, em que salvar e consultar dados rapidamente em escala é fundamental.
Sistemas que não podem ficar inativos usam o Cassandra porque a replicação em vários data centers e as gravações assíncronas permitem que um data center inteiro fique off-line sem interromper o serviço ou perder dados. Muitas empresas globais dependem disso para manter os apps funcionando 24 horas por dia em diferentes regiões.
O Cassandra usa um design ponto a ponto em que todos os nós são idênticos. Esses nós são configurados em um anel descentralizado e usam um método chamado hashing consistente para distribuir dados de maneira uniforme, evitar gargalos e garantir que não haja pontos únicos de falha. Também é possível escolher o nível de rigor do banco de dados ao verificar o sucesso de uma leitura ou gravação, o que permite decidir entre velocidade e ter os dados mais atualizados com base nas necessidades específicas do seu aplicativo.
O banco de dados usa um modelo chamado armazenamento de colunas amplas, que ajuda a organizar seus dados em keyspaces, linhas e colunas dinâmicas, semelhante a uma planilha normal, mas com mais flexibilidade. Isso permite projetar os dados de uma forma que seja fácil de mudar conforme o app cresce.
Recurso | Apache Cassandra | RDBMS tradicional |
Modelo de dados | Dados desnormalizados | Normalizada |
Flexibilidade de esquema | Pode alterar durante a execução | Requer inatividade |
Estrutura do índice | Árvore de mesclagem estruturada em logs | B-tree |
Otimização de gravação | Principal | Secundário |
Posicionamento CAP (consistência, disponibilidade, tolerância a partições) | AP (disponível e tolerância a partições) | CA (consistente e disponível) |
Capacidade de consulta | CQL (sem JOINs) | SQL completo com JOINs |
Modelo de dados
Dados desnormalizados
Normalizada
Flexibilidade de esquema
Pode alterar durante a execução
Requer inatividade
Estrutura do índice
Árvore de mesclagem estruturada em logs
B-tree
Otimização de gravação
Principal
Secundário
Posicionamento CAP (consistência, disponibilidade, tolerância a partições)
AP (disponível e tolerância a partições)
CA (consistente e disponível)
Capacidade de consulta
CQL (sem JOINs)
SQL completo com JOINs
O mecanismo de armazenamento do Cassandra conta com uma árvore de mesclagem estruturada em log (LSM, na sigla em inglês) para lidar com os dados. As gravações recebidas são registradas em um registro de confirmação para durabilidade e mantidas na memória por meio de uma Memtable. Quando ficam cheias, as Memtables são transferidas para o disco como tabelas de strings ordenadas (SSTables) imutáveis.
Esse design de adição ao final é o motivo pelo qual o Cassandra se destaca em capacidades de processamento com alto volume de gravação. Ao evitar atualizações no local, o sistema pode processar os dados recebidos muito mais rápido do que os sistemas tradicionais que dependem de E/S de disco aleatória.
Aqui estão as respostas para algumas perguntas comuns sobre o Cassandra.
É um banco de dados distribuído voltado para apps que precisam estar sempre on-line e processar grandes volumes de gravação de dados, como logs de streaming ou dados de sensores.
O Cassandra é um banco de dados NoSQL. Ele usa uma linguagem chamada CQL, que se parece com SQL, mas não oferece suporte a todos os mesmos recursos, como junções complexas ou segurança de transações profundas.
O Kafka é usado para mover dados em tempo real, enquanto o Cassandra é usado para armazenar esses dados com segurança. Essas duas soluções costumam ser usadas juntas em um sistema.
O Cassandra é ideal para gravar um grande volume de dados em larga escala. O MongoDB é um banco de dados orientado a documentos, sendo geralmente a melhor opção para realizar buscas em diferentes tipos de dados com estruturas flexíveis.
O Cassandra foi desenvolvido para processamento de transações on-line (OLTP), o que significa que ele é bom para lidar com leituras e gravações simples e de alta velocidade. Ele não foi criado para tarefas analíticas complexas, como gerar relatórios grandes ou verificar todos os dados de uma só vez.
Escalonabilidade
Você pode adicionar mais nós para lidar com mais trabalho, e não precisa desligar o sistema para fazer isso.
Nenhum ponto único de falha
Como todos os nós são iguais, o sistema é muito estável.
Cópia automática de dados
O sistema salva seus dados automaticamente em vários lugares.
Gravações rápidas
O design do armazenamento foi criado para acomodar um grande número de gravações de uma só vez.
Consistência ajustável
Você pode controlar o nível de rigor dos seus dados por consulta. Escolha "Todos" os nós para ter precisão perfeita ou "Um" nó para ter a maior velocidade possível.
Sem dependência de fornecedores
Como ele roda em hardware padrão, você não se restringe a provedores de nuvem específicos. Você pode mover seus dados entre configurações locais e diferentes nuvens, se necessário.
Manter seu próprio sistema Cassandra gera uma grande carga operacional. Você precisa planejar o espaço necessário, configurar os servidores, cuidar das manutenções, garantir a realização de backups e fazer atualizações com o sistema em operação.
Os serviços gerenciados mudam esse cenário ao cuidar do trabalho pesado para você.
Ao transferir essas tarefas operacionais para uma plataforma gerenciada, sua equipe pode deixar de se preocupar com a infraestrutura básica do banco de dados e focar em gerar valor para os usuários.
Ao decidir como executar suas cargas de trabalho do Cassandra, existem três caminhos principais.
A escolha do caminho ideal depende de equilibrar a experiência da sua equipe com as necessidades específicas do seu negócio. Use esta lista de verificação para orientar sua tomada de decisão:
Pergunta | Se sim… | Se não… |
Temos tempo para corrigir e ajustar o banco de dados? | Você pode lidar com clusters autogerenciados se tiver engenheiros dedicados para "infraestrutura de banco de dados". | Escolha um serviço gerenciado para evitar gastar o tempo da equipe de engenharia com a manutenção da infraestrutura. |
"Permanecer on-line" é mais importante do que a consistência perfeita? | O modelo AP do Cassandra é ideal para apps de alta disponibilidade. | Considere o Cloud Spanner, que oferece a escala de um sistema distribuído com segurança de dados rigorosa. |
Precisamos escalonar verticalmente com rapidez à medida que crescemos? | Use serviços gerenciados ou o Bigtable, que oferecem escalonamento automático para lidar com picos de tráfego. | Um cluster estático pode funcionar, mas você corre o risco de ter gargalos de desempenho durante períodos de pico. |
Um serviço gerenciado tornaria nosso trabalho mais confiável? | Com certeza. Os serviços gerenciados automatizam backups e patches para evitar erros humanos. | Você aceita o risco maior de manutenção manual e possíveis erros de configuração. |
Nosso objetivo é a portabilidade da infraestrutura? | A opção autogerenciada oferece total liberdade para migrar entre nuvens ou executar as operações localmente. | Você se sente confortável com os benefícios específicos da nuvem em troca de um menor esforço operacional. |
Pergunta
Se sim…
Se não…
Temos tempo para corrigir e ajustar o banco de dados?
Você pode lidar com clusters autogerenciados se tiver engenheiros dedicados para "infraestrutura de banco de dados".
Escolha um serviço gerenciado para evitar gastar o tempo da equipe de engenharia com a manutenção da infraestrutura.
"Permanecer on-line" é mais importante do que a consistência perfeita?
O modelo AP do Cassandra é ideal para apps de alta disponibilidade.
Considere o Cloud Spanner, que oferece a escala de um sistema distribuído com segurança de dados rigorosa.
Precisamos escalonar verticalmente com rapidez à medida que crescemos?
Use serviços gerenciados ou o Bigtable, que oferecem escalonamento automático para lidar com picos de tráfego.
Um cluster estático pode funcionar, mas você corre o risco de ter gargalos de desempenho durante períodos de pico.
Um serviço gerenciado tornaria nosso trabalho mais confiável?
Com certeza. Os serviços gerenciados automatizam backups e patches para evitar erros humanos.
Você aceita o risco maior de manutenção manual e possíveis erros de configuração.
Nosso objetivo é a portabilidade da infraestrutura?
A opção autogerenciada oferece total liberdade para migrar entre nuvens ou executar as operações localmente.
Você se sente confortável com os benefícios específicos da nuvem em troca de um menor esforço operacional.
Se você quiser deixar de gerenciar o Cassandra por conta própria, o Google Cloud oferece duas soluções úteis: o Bigtable e o Spanner.
Se você já usa o Cassandra pelo armazenamento de colunas largas capacidade de processamento com alto volume de gravação, o Bigtable pode ser uma ótima opção. Para usá-lo, basta mapear seus keyspaces e tabelas do Cassandra para tabelas do Bigtable e atualizar o código do seu aplicativo para usar as bibliotecas de cliente do Cloud Bigtable. Por ser totalmente gerenciado, o Bigtable lida automaticamente com a fragmentação e o balanceamento de carga que antes você precisava ajustar manualmente no Cassandra.
Se a sua carga de trabalho do Cassandra cresceu a ponto de exigir uma consistência mais forte ou se você precisa de recursos relacionais de SQL, o Spanner também pode ser uma boa opção. Para usá-lo, defina o esquema usando SQL padrão, o que pode exigir a normalização de alguns dos seus dados do Cassandra que estejam desnormalizados. Ele oferece a mesma escala horizontal que o Cassandra, mas com o benefício de uma consistência sólida e global e suporte completo a SQL relacional.
Comece a criar no Google Cloud com US$ 300 em créditos e mais de 20 produtos do programa Sempre gratuito.