Cassandra foi projetado para obter alto rendimento e operações de gravação mais rápidas.
A chave primária identifica exclusivamente cada linha de uma tabela. No Cassandra, a chave primária tem duas partes:
PRIMARY KEY (city_id, event_id)
. Esta chave primária consiste em duas partes, representadas pelas duas colunas:
1. city_id
serve como chave de partição, o que significa que os dados serão particionados com base no campo city_id
, resultando em todas as linhas com o mesmo city_id
sendo armazenadas no mesmo nó.
2. event_id
atua como chave de cluster. Dentro de cada nó, os dados são organizados e armazenados em ordem de classificação com base na coluna event_id
.
Cada linha com partição key = "Paris" será armazenada no mesmo nó, ordenada pelo valor da coluna event_id.
O particionador no Cassandra é responsável por decidir como os dados são distribuídos no anel Hash Consistente. Quando os dados são inseridos em um cluster Cassandra, o particionador aplica um algoritmo de hash à chave de partição . O resultado desse algoritmo de hash determina o intervalo em que os dados caem e determina o nó no qual os dados serão armazenados.
O nó que recebe a solicitação é conhecido como coordenador e pode ser qualquer nó do cluster. Caso uma chave não pertença ao intervalo do coordenador, a solicitação é encaminhada para as réplicas responsáveis por esse intervalo.
Cassandra se destaca em aplicações que exigem o tratamento de grandes volumes de dados e priorizam a disponibilidade dos dados em detrimento da consistência. É adequado para :
1. Aplicativos de Internet das Coisas (IoT) : Cassandra é uma escolha ideal para ambientes IoT, pois pode lidar com grandes quantidades de dados gerados por dispositivos e sensores. Sua arquitetura distribuída permite o gerenciamento de dados geograficamente dispersos e em grande escala.
2. Dados de série temporal : aplicativos que lidam com dados de série temporal, como métricas, sistemas de monitoramento e dados de telemetria, se beneficiam das operações de gravação eficientes e da escalabilidade horizontal do Cassandra. Esses recursos são cruciais para armazenar e gerenciar grandes volumes de dados com registro de data e hora.
3. Aplicativos Web e Móveis : Cassandra oferece alto rendimento e acesso a dados de baixa latência, tornando-o adequado para plataformas web e móveis com grandes bases de usuários que geram quantidades significativas de dados. Isso inclui plataformas de mídia social, aplicativos de jogos e sites de comércio eletrônico.
4. Análise de Big Data em tempo real : Cassandra oferece suporte ao processamento de big data em tempo real, tornando-o uma escolha valiosa para aplicativos que exigem insights imediatos de grandes conjuntos de dados. Os exemplos incluem mecanismos de recomendação e sistemas de detecção de fraude.
5. Data Warehouses Distribuídos : Empresas com grandes conjuntos de dados distribuídos podem aproveitar o Cassandra como uma solução de data warehouse. Sua capacidade de replicar dados em vários data centers garante alta disponibilidade e recuperação de desastres.
6. Sistemas de mensagens : o alto rendimento de gravação e leitura do Cassandra o torna adequado para sistemas de mensagens que lidam com grandes volumes de dados, como registro de eventos, trilhas de auditoria ou filas de mensagens.
7. Sistemas de personalização e gerenciamento de conteúdo : aplicativos que exigem entrega de conteúdo personalizado em escala, como sistemas de gerenciamento de conteúdo, se beneficiam da velocidade e escalabilidade do Cassandra na entrega de conteúdo personalizado para um grande número de usuários simultaneamente.
8. Aplicativos distribuídos geograficamente : O suporte do Cassandra para vários data centers o torna uma excelente escolha para aplicativos que exigem dados distribuídos geograficamente. Garante acesso a dados de baixa latência em diferentes regiões e fornece alta resiliência.
Embora o Apache Cassandra seja poderoso e escalável, pode não ser adequado para todos os aplicativos ou casos de uso. É menos adequado para aplicativos com muitas transações, consultas complexas e cenários que exigem consistência forte ou alterações rápidas de esquema. Os sistemas tradicionais de gerenciamento de banco de dados relacional (RDBMS) ou outras soluções NoSQL podem ser mais apropriados nesses casos. Aqui estão vários cenários em que Cassandra pode não ser a escolha ideal :
Projetos de pequena escala : a complexidade e os requisitos de recursos do Cassandra podem ser excessivos para projetos ou aplicações de pequena escala com conjuntos de dados limitados. Soluções de banco de dados mais simples podem oferecer uma alternativa mais econômica e gerenciável.
Sistemas transacionais que requerem propriedades ACID : Cassandra não oferece suporte total às propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Se a sua aplicação requer transações complexas normalmente encontradas em sistemas bancários ou financeiros, um RDBMS tradicional pode ser mais adequado.
Junte-se a consultas e agregações pesadas : se seu aplicativo depende muito de junções, subconsultas ou agregações complexas, o Cassandra pode não ser a escolha mais adequada. Ele foi projetado para gravações e leituras rápidas, mas não para processamento de consultas complexas.
Dados com fortes requisitos de consistência : Cassandra fornece consistência eventual, o que pode não ser adequado para casos de uso que exigem forte consistência para cada operação de leitura e gravação.
Leituras e gravações de baixa latência em um único cluster : embora o Cassandra tenha um bom desempenho em ambientes distribuídos de vários nós, ele pode não ser a escolha ideal para implantações de nó único ou de cluster pequeno que exigem leituras e gravações de baixa latência.
Armazenamento de Blob : Cassandra não é otimizado para armazenar grandes objetos binários (blobs), como imagens ou vídeos. Outras soluções de armazenamento são mais adequadas para lidar eficientemente com grandes blobs.
Aplicativos que exigem consultas ad-hoc : os recursos de consulta do Cassandra são limitados em comparação com bancos de dados SQL completos. Não é adequado para aplicativos que dependem fortemente de consultas e relatórios ad-hoc.
No Cassandra, o design das tabelas está intimamente ligado à forma como os dados serão acessados, enfatizando os padrões de consulta em vez de focar apenas nos relacionamentos entre as entidades de dados. Isso difere da abordagem do RDBMS, onde o design do esquema é baseado em princípios de normalização.
Evolução rápida do esquema : se o seu aplicativo exigir alterações frequentes no esquema do banco de dados, o gerenciamento de esquema do Cassandra pode ser menos flexível em comparação com sistemas RDBMS tradicionais ou outras soluções NoSQL.
Aplicativos de data warehouse que envolvem consultas complexas, junções e análise de dados históricos : embora o Cassandra seja adequado para cargas de trabalho com gravação intensa e acesso a dados em tempo real, pode não ser a escolha mais adequada para cenários de data warehouse que exigem consultas complexas, junções e análise de dados históricos.
Existem vários aspectos interessantes de Cassandra que abordarei em meu próximo artigo. Inscreva-se para não perder!