Cassandra Archiarquitetura e fator de replicação
⚡ Resumo Inteligente
Cassandra A arquitetura distribui dados entre nós pares sem um único ponto de falha, usando comunicação por meio de gossip para coordenação e replicação para garantir a durabilidade. Esta página aborda todos os componentes, incluindo as estratégias de replicação, os níveis de consistência e os caminhos internos de leitura e escrita.

Cassandra é projetado para lidar com Big Data. CassandraA principal característica do é armazenar dados em vários nós sem nenhum ponto único de falha.
A razão para este tipo de CassandraA arquitetura do era que a falha de hardware pode ocorrer a qualquer momento. Qualquer nó pode estar inativo. Em caso de falha, dados armazenados em outro nó podem ser usados. Portanto, Cassandra é projetado com sua arquitetura distribuída.
Cassandra armazena dados em diferentes nós com uma arquitetura de estilo distribuído ponto a ponto.
Todos os nós trocam informações entre si usando Protocolo de fofoca. A fofoca é um protocolo em Cassandra pelo qual os nós podem se comunicar entre si.
Componentes de Cassandra Archiarquitetura
Existem os seguintes componentes no Cassandra Architextura:

O diagrama acima representa a estrutura dos componentes: os nós estão localizados dentro de um centro de dados, os centros de dados estão localizados dentro de um cluster, e o log de commits, a memtable e a SSTable residem dentro de cada nó individual.
Node
Nó é o local onde os dados são armazenados. É o componente básico Cassandra.
Data Center
Uma coleção de nós é chamada de data center. Muitos nós são categorizados como data center.
Cluster
O cluster é a coleção de muitos data centers.
Registro de confirmação
Cada operação de gravação é gravada no Commit Log. O log de confirmação é usado para recuperação de falhas.
Tabela Mem
Após os dados serem gravados no log de commit, os dados são gravados na tabela Mem. Os dados são gravados na tabela Mem temporariamente.
SSTable
Quando a Mem-table atinge um determinado limite, os dados são gravados em um arquivo SSTable no disco. As SSTables são imutáveis, portanto, uma atualização grava uma nova versão em vez de editar a antiga, e um processo em segundo plano chamado compactação posteriormente mescla essas versões e descarta as linhas substituídas.
Replicação de dados em Cassandra
Como podem ocorrer problemas de hardware ou o link pode cair a qualquer momento durante o processo de dados, é necessária uma solução para fornecer um backup quando o problema ocorrer. Assim, os dados são replicados para garantir que não haja nenhum ponto único de falha.
Cassandra coloca réplicas de dados em nós diferentes com base nesses dois fatores.
- Onde colocar a próxima réplica é determinado pelo Estratégia de replicação.
- Embora o número total de réplicas colocadas em nós diferentes seja determinado pelo Fator de replicação.
Um fator de replicação significa que há apenas uma única cópia dos dados, enquanto três fatores de replicação significa que há três cópias dos dados em três nós diferentes.
Para garantir que não haja um ponto único de falha, o fator de replicação deve ser três.
Existem dois tipos de estratégias de replicação em Cassandra.
SimpleStrategy em Cassandra
Estratégia Simples é usado quando você tem apenas um data center. O SimpleStrategy coloca a primeira réplica no nó selecionado pelo particionador. Depois disso, as réplicas restantes são colocadas no sentido horário no anel do Node.
Aqui está a representação pictórica do SimpleStrategy:

NetworkTopologyEstratégia em Cassandra
RedeTopologiaEstratégia é usado quando você tem mais de dois data centers. No NetworkTopologyStrategy, as réplicas são definidas para cada data center separadamente. NetworkTopologyStrategy coloca réplicas no sentido horário no anel até atingir o primeiro nó em outro rack. Esta estratégia tenta colocar réplicas em racks diferentes no mesmo data center.
Isso ocorre porque às vezes pode ocorrer falha ou problema no rack. Então, as réplicas em outros nós podem fornecer dados.
Aqui está a representação pictórica da estratégia de topologia de rede:

O fator de replicação determina quantas cópias existem. Quantas dessas cópias devem responder a uma determinada solicitação é uma configuração separada, descrita a seguir.
Níveis de consistência em Cassandra
O nível de consistência é definido por consulta, e não por cluster, o que faz a diferença. Cassandra Ajustável. Define quantas réplicas devem confirmar uma escrita ou responder a uma leitura antes que o coordenador responda ao cliente. Um nível baixo retorna mais rapidamente; um nível alto retorna dados com maior certeza de estarem atualizados.
| Nível | Comportamento | Uso típico |
|---|---|---|
| ONE | Uma réplica deve responder. | Registro de alto rendimento, onde uma leitura ocasional desatualizada é aceitável. |
| QUORUM | A maioria de todas as réplicas deve responder, calculada como (RF / 2) + 1. | A opção ideal para uso geral, que oferece equilíbrio entre consistência e disponibilidade. |
| QUÓRUM_LOCAL | A maioria das réplicas dentro do centro de dados local deve responder. | Clusters com múltiplos centros de dados, pois evitam a latência entre regiões. |
| TODAS | Cada réplica deve responder. | Raro. A falha de um único nó faz com que a solicitação falhe completamente. |
| QUALQUER (somente escrita) | Uma transferência sinalizada é considerada bem-sucedida mesmo que nenhuma réplica esteja acessível. | Disponibilidade máxima de escrita, permitindo flexibilidade na durabilidade. |
A consistência forte é garantida quando o nível de leitura somado ao nível de escrita excede o fator de replicação. Com um fator de replicação de três, escrever em QUORUM e ler em QUORUM satisfaz essa regra, pois dois mais dois é maior que três. Escrever em ONE e ler em ONE não satisfazem essa regra e, portanto, uma leitura pode retornar um valor mais antigo.
Quando uma réplica está inacessível, o coordenador armazena um sugerir e o reproduz assim que o nó retorna, que é como o nível ANY e grande parte de Cassandrao trabalho de comportamento de autocura.
Escreva Operação em Cassandra
O coordenador envia uma solicitação de gravação para as réplicas. Se todas as réplicas estiverem ativas, elas receberão uma solicitação de gravação, independentemente do seu nível de consistência.
Nível de consistência determina quantos nós responderão com a confirmação de sucesso.
O nó responderá com a confirmação de sucesso se os dados forem gravados com sucesso no log de commit e memTable.
Por exemplo, em um único data center com fator de replicação igual a três, três réplicas receberão solicitação de gravação. Se o nível de consistência for um, apenas uma réplica responderá com a confirmação de sucesso e as duas restantes permanecerão inativas.
Suponha que se as duas réplicas restantes perderem dados devido a falhas de nós ou algum outro problema, Cassandra tornará a linha consistente pelo mecanismo de reparo integrado em Cassandra.
Aqui é explicado como ocorre o processo de gravação em Cassandra,
- Quando a solicitação de gravação chega ao nó, primeiro ele é registrado no log de commit.
- Então Cassandra grava os dados na tabela mem. Os dados gravados na tabela mem em cada solicitação de gravação também são gravados no log de confirmação separadamente. Mem-table são dados armazenados temporariamente na memória enquanto o log de Commit registra os registros de transações para fins de backup.
- Quando a tabela mem está cheia, os dados são liberados para o arquivo de dados SSTable.

Como as SSTables nunca são editadas diretamente, uma exclusão não remove a linha imediatamente. Em vez disso, um marcador chamado `<nome_do_arquivo>` é adicionado ao registro da linha. lápide A linha é gravada e desaparece somente quando a compactação é executada após o período de tolerância. É por isso que cargas de trabalho de exclusão intensas tornam as leituras mais lentas até que a compactação consiga acompanhar o ritmo.
Leia Operação em Cassandra
Existem três tipos de solicitações de leitura que um coordenador envia para réplicas.
- Pedido direto
- Solicitação de resumo
- Ler solicitação de reparo
O coordenador envia solicitação direta para uma das réplicas. Depois disso, o coordenador envia a solicitação de resumo para o número de réplicas especificado pelo nível de consistência e verifica se os dados retornados são dados atualizados.
Depois disso, o coordenador envia uma solicitação de resumo para todas as réplicas restantes. Se algum nó fornecer um valor desatualizado, uma solicitação de reparo de leitura em segundo plano atualizará esses dados. Este processo é chamado de mecanismo de reparo de leitura.
Na réplica que recebe a solicitação direta, a ordem de pesquisa é projetada para evitar, sempre que possível, o acesso ao disco.
- O memtable é verificado primeiro, uma vez que as gravações mais recentes ainda não foram descarregadas.
- O cache de linhaSe ativada, pode responder a toda a solicitação sem trabalho adicional.
- A filtro de flor é consultado para cada SSTable. Ele responde "definitivamente não presente" ou "possivelmente presente", o que permite que a maioria das SSTables seja ignorada sem ser lida.
- O índice de partição e seu resumo localizam o deslocamento exato de bytes em qualquer SSTable que sobreviva à verificação do filtro de Bloom.
- Fragmentos correspondentes de várias SSTables são mesclados, sendo o registro de data e hora mais recente o que prevalece para cada coluna.
O filtro de Bloom é a etapa que mantém as leituras rápidas à medida que os dados aumentam, pois remove quase todas as SSTables da consideração antes que qualquer busca em disco ocorra. A aplicação desses mecanismos em várias máquinas é abordada em [referência]. Cassandra cacho tutorial.
