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. Por padrão, Cassandra foi projetado para ser eventualmente consistente, o que significa que pode não fornecer consistência forte. Isso torna o Cassandra adequado para aplicações onde a consistência não é um requisito crítico. No entanto, é possível configurar o Cassandra para fornecer consistência forte, embora isso possa afetar o desempenho. 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 : uma coluna representa um par chave-valor e serve como unidade fundamental da estrutura de dados. Coluna : atua como um contêiner para colunas referenciadas pela chave primária. Linha : serve como um contêiner para tabelas que abrangem um ou mais nós Cassandra. Keyspace : um contêiner de keyspaces dentro do Cassandra. Cluster : 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. Nó 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: Cassandra não armazena colunas com valores nulos, o que ajuda a economizar espaço de armazenamento significativo Qual é a chave primária em Cassandra? A identifica exclusivamente cada linha de uma tabela. No Cassandra, a chave primária tem duas partes: chave primária 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 . Esta chave primária consiste em duas partes, representadas pelas duas colunas: PRIMARY KEY (city_id, event_id) 1. serve como chave de partição, o que significa que os dados serão particionados com base no campo , resultando em todas as linhas com o mesmo sendo armazenadas no mesmo nó. city_id city_id city_id 2. 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 event_id As chaves de cluster determinam o arranjo de armazenamento de dados dentro de um nó. É possível ter diversas chaves de cluster e quaisquer colunas listadas após a chave de partição são chamadas de colunas de cluster. As colunas de cluster definem a ordem na qual os dados são organizados em um nó. 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 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. Hashing consistente O 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 à . 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. particionador chave de partição Nó coordenador No Cassandra, cada nó está ciente das atribuições de token de outros nós por meio , 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. do protocolo gossip O nó que recebe a solicitação é conhecido como 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. coordenador 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. Cada keyspace no Cassandra pode ter um fator de replicação diferente. 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. Essa estratégia de replicação é aplicável somente a um único cluster de datacenter. 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 se trata de configurações de vários datacenters, você deve considerar a estratégia de topologia de rede. Essa abordagem permite a especificação de diversos fatores de replicação para cada data center, possibilitando o controle sobre o número de réplicas a serem colocadas em cada local específico. 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. : 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. Aplicativos de Internet das Coisas (IoT) 2. : 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. Dados de série temporal 3. : 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. Aplicativos Web e Móveis 4. : 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. Análise de Big Data em tempo real 5. : 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. Data Warehouses Distribuídos 6. : 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. Sistemas de mensagens 7. : 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. Sistemas de personalização e gerenciamento de conteúdo 8. : 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. Aplicativos distribuídos geograficamente 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 : 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. Projetos de pequena escala : 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. Sistemas transacionais que requerem propriedades ACID : 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. Junte-se a consultas e agregações pesadas : 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. Dados com fortes requisitos de consistência : 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. Leituras e gravações de baixa latência em um único cluster : 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. Armazenamento de Blob : 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. Aplicativos que exigem consultas 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. : 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. Evolução rápida do esquema : 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. Aplicativos de data warehouse que envolvem 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. Existem vários aspectos interessantes de Cassandra que abordarei em meu próximo artigo. para não perder! Inscreva-se Saúde!
