Cassandra: banco de dados altamente escalável pronto para uso

Cassandra é um banco de dados de colunas largas distribuído, descentralizado, escalável e altamente disponível.

Em termos do teorema CAP, Cassandra significa AP (disponibilidade e tolerância de partição).

Isso significa que Cassandra prefere que todos os clientes possam encontrar dados mesmo nos casos em que nem todos os nós estejam disponíveis e funcionem conforme o esperado quando ocorrer uma falha parcial da rede. No entanto, isso também significa que a consistência dos dados pode ser comprometida em favor da disponibilidade e da tolerância à partição – os usuários verão os dados, mas eles poderão ficar obsoletos por um tempo.

Cassandra foi projetado para obter alto rendimento e operações de gravação mais rápidas.

E é precisamente o sacrifício da consistência que permite que Cassandra esteja altamente disponível.

Cassandra, sendo um banco de dados NoSQL, não oferece suporte a junções de tabelas, chaves estrangeiras ou a capacidade de adicionar colunas diferentes da chave primária na cláusula WHERE durante a consulta. Estas limitações devem ser levadas em consideração antes de escolher usar o Cassandra.

Blocos de construção de Cassandra

• Coluna : uma coluna representa um par chave-valor e serve como unidade fundamental da estrutura de dados.
• Linha : atua como um contêiner para colunas referenciadas pela chave primária.
• Keyspace : serve como um contêiner para tabelas que abrangem um ou mais nós Cassandra.
• Cluster : um contêiner de keyspaces dentro do Cassandra.
• Nó : refere-se a um sistema de computador que executa uma instância do Cassandra. Um nó pode ser um host físico, uma instância de máquina na nuvem ou até mesmo um contêiner Docker.

Como Cassandra armazena dados

Cassandra armazena os dados como um grupo de colunas. Ele serve como um contêiner para colunas referenciadas por uma chave primária.

Uma linha de um grupo de colunas inclui diversas colunas com chave e valor, e a chave da linha serve como chave primária:

Uma família de colunas pode armazenar um conjunto diferente de colunas para cada chave de linha:

Qual é a chave primária em Cassandra?

A chave primária identifica exclusivamente cada linha de uma tabela. No Cassandra, a chave primária tem duas partes:

No Cassandra, a chave de partição determina qual nó armazena os dados, enquanto a chave de cluster determina como os dados são armazenados em um nó. Por exemplo, considere uma tabela com um

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.

Particionamento de dados pronto para uso

Cassandra fornece particionamento de dados baseado em Hashing consistente para reduzir a latência em operações de leitura/gravação e aumentar o rendimento do sistema quando a quantidade de dados armazenados no banco de dados se torna grande.

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.

Nó coordenador

No Cassandra, cada nó está ciente das atribuições de token de outros nós por meio do protocolo gossip , permitindo que qualquer nó lide com solicitações para o intervalo de qualquer outro nó. Portanto, um cliente pode conectar-se a qualquer nó para iniciar consultas de leitura ou gravação.

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.

Replicação

Cassandra replica dados em vários nós para garantir alta disponibilidade. Cada nó no Cassandra serve como réplica para um intervalo de dados específico. Ao distribuir múltiplas cópias dos dados em diferentes réplicas, o Cassandra permite que outras réplicas lidem com consultas para esse intervalo de dados caso um nó esteja indisponível. Duas configurações afetarão o processo de replicação:

O fator de replicação determina quantos nós armazenarão cópias dos mesmos dados. Em um cluster com fator de replicação 3, cada linha será armazenada em três nós diferentes.

No Cassandra, a primeira réplica é atribuída ao nó que possui o intervalo com base no hash da chave de partição. As réplicas restantes são então colocadas em nós consecutivos no sentido horário. Cassandra usa duas estratégias de replicação para determinar quais nós serão responsáveis pelas réplicas:

Estratégia de replicação simples

Nesta estratégia, a primeira réplica é colocada em um nó determinado pelo particionador e as réplicas subsequentes são colocadas nos nós subsequentes no sentido horário.

Estratégia de topologia de rede

Para garantir a resiliência contra a perda completa de dados, réplicas adicionais dentro do mesmo data center são colocadas movendo-se no sentido horário ao longo do anel até chegar ao primeiro nó em um data center diferente. Esse arranjo ajuda a mitigar o impacto de falhas simultâneas que normalmente ocorrem no mesmo data center devido a problemas de energia, resfriamento ou rede.

Quando usar Cassandra

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.

Quando não usar Cassandra

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 :

1. 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.

   
   

2. 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.

   
   

3. 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.

   
   

4. 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.

   
   

5. 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.

   
   

6. 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.

   
   

7. 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.

   
   

8. 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.

   
   

9. 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.

Resumo

Este artigo fornece uma visão geral do Cassandra, um banco de dados de colunas largas altamente escalonável e distribuído. O Cassandra foi projetado para priorizar a disponibilidade e a tolerância à partição, tornando-o adequado para aplicações onde a consistência não é um requisito crítico. Ele oferece suporte a alto rendimento e operações de gravação mais rápidas.

Os blocos de construção do Cassandra incluem colunas, linhas, keyspaces, clusters e nós. As colunas representam pares de valores-chave, as linhas atuam como contêineres para colunas referenciadas pela chave primária, os espaços-chave servem como contêineres para tabelas que abrangem vários nós, os clusters contêm espaços-chave e os nós referem-se a sistemas de computador que executam instâncias do Cassandra.

Cassandra armazena dados em famílias de colunas, que são contêineres para colunas referenciadas por uma chave primária. O particionamento de dados é obtido por meio de hashing consistente, permitindo redução da latência e aumento do rendimento. O particionador distribui dados pelo anel Hash Consistente e um nó coordenador lida com consultas de leitura e gravação.

Cassandra fornece replicação para alta disponibilidade. As réplicas de dados são armazenadas em vários nós, garantindo que as consultas possam ser tratadas pelas réplicas se um nó ficar indisponível. Os fatores e estratégias de replicação determinam o número de réplicas e os nós responsáveis por elas.

Embora o Cassandra ofereça benefícios como escalabilidade e alta disponibilidade, ele tem limitações. Ele não oferece suporte a junções de tabelas, chaves estrangeiras ou a capacidade de adicionar colunas diferentes da chave primária na cláusula WHERE durante a consulta.

No geral, o Cassandra é uma solução de banco de dados poderosa para aplicativos altamente escaláveis, especialmente aqueles que priorizam a disponibilidade e a tolerância à partição em vez de uma consistência forte.

Saúde!