Introdução

Já pensou se sua aplicação viraliza de um dia para o outro?

E se a sua empresa conseguir um contrato novo que fará dobrar o número de acessos à aplicação?

Seja qual for o motivo, as empresas estão se preocupando cada vez mais para lidar com o sucesso repentino.

Em maio deste ano, após a justiça determinar o bloqueio do WhatsApp, o Telegram, aplicativo concorrente, ganhou milhões de usuários brasileiros em menos de 24 horas. (Fonte: Telegram ama o Brasil: bloqueio do WhatsApp leva usuários em massa à plataforma rival)

Mas o que as empresas devem fazer para enfrentar cenários como este? Na notícia acima, podemos observar duas características de extrema importância: escalabilidade e alta disponibilidade.

Se o WhatsApp não tivesse ficado fora por horas (vamos imaginar que a indisponibilidade se deu por falhas técnicas) seus usuários provavelmente não teriam procurado outra alternativa. Por outro lado, se o Telegram não tivesse capacidade para absorver todos esses usuários,  provavelmente ele não teria sido a alternativa escolhida.

Apache Cassandra

Escalabilidade e Alta Disponibilidade. Aqui entra o Apache Cassandra.

thumb_cassandra_logo

O Apache Cassandra é um sistema de banco de dados distribuído, open source, baseado na tecnologia NoSQL. Inicialmente desenvolvido pelo Facebook e atualmente mantido pela fundação Apache, o Cassandra é a escolha ideal para soluções que exigem alta disponibilidade e escalabilidade sem afetar o desempenho. É um dos mais populares da categoria.

NoSQL (Not Only SQL) é uma classe de banco de dados não-relacional criada para tentar resolver uma necessidade crescente de manipular grandes volumes de dados sem perder o desempenho.

Alto nível de escalabilidade, desempenho e disponibilidade contínua são habilidades atribuídas à arquitetura utilizada pelo Cassandra. Ao contrário de usar um esquema master-slave, Cassandra tem um desenho de “anel” que é elegante, fácil de configurar e de manter, onde todos os nós se comunicam igualmente entre si e não existe um nó mestre. Dessa forma o Cassandra é capaz de trabalhar grandes massas de dados com milhares de usuários ou operações concorrentes por segundo, mesmo distribuído em múltiplos data centers, como se estivesse gerenciando pequenas operações e usuários por vez. Como o Cassandra não tem “single point of failure”, é possível adicionar novos nós em um cluster existente, permitindo um tempo de atividade contínua. A aplicação não vai parar se um determinado nó falhar.

cassandra-ring-architecture

Um pouco sobre o seu funcionamento:

  • Permite qualquer usuário autorizado conectar em qualquer nó de qualquer data center usando a linguagem CQL (Cassandra Query Language).
  • Fornece distribuição automática de dados entre os nós de um anel ou cluster.
  • Replicação embutida e customizável realiza cópias redundantes entre os nós participantes de um anel. Significa que se um nó falhar, uma ou mais cópias estarão disponíveis em outras máquinas do cluster.
  • Para fornecer escalabilidade linear, o Cassandra permite adicionar novos nós a qualquer momento. Por exemplo, se dois nós suportam 100 mil transações por segundo, quatro nós suportarão 200 mil transações por segundo. E assim por diante.

cassandra-linear-scalability

  • Diferentemente dos bancos de dados relacionais, o armazenamento de dados no Cassandra é desnormalizado.

Na documentação oficial do Cassandra é possível encontrar dicas de boas práticas para aproveitar seus benefícios. Seguem algumas em destaque:

  • Não tentar levar regras aplicáveis em bancos de dados relacionais para o Cassandra.
    Exemplo, não preocupar tanto com o número de escritas no banco de dados, Cassandra foi desenvolvido para prover alta taxa de transferência. Se tiver que escrever mais para facilitar o mecanismo de busca, prefira fazê-lo. Desnormalização e redundância fazem parte do projeto Cassandra. Espaço em disco é um recurso barato em relação aos demais e não deve ser um problema, mas sim a solução para uma leitura mais eficiente.
  • Manter os dados distribuídos uniformemente entre as partições e tentar minimizar o número de partições de leitura. É importante haver um equilíbrio entre a distribuição dos dados e a quantidade de partições. As partições são grupos de registros que possuem a mesma chave de partição. Uma leitura se torna cara se tiver que acessar um número grande de partições.
  • A modelagem deve ser em torno das consultas e não em torno de tabelas e relacionamentos.
    Primeiro: determinar quais consultas devem ser suportadas.
    Segundo: tentar criar uma tabela para satisfazer a consulta através da leitura de uma partição (aproximadamente).

Busque mais

Mais documentação:

Exemplo de modelagem de dados no Cassandra
♦ Data modeling example

Como funciona a consistência de dados no Cassandra
♦ Data consistency

Usando CQL
♦ Using CQL

Planejamento e testes de Clusters
♦ Planning and testing cluster deployments

Várias empresas relataram sucesso ao adotarem o Cassandra em seus projetos. Alguns exemplos: Apple, Comcast, Instagram, Spotify, eBay, Rackspace e Netflix. A Netflix disponibililzou os resultados de um benchmark realizado para avaliar o Cassandra. Segue o link:
♦ Benchmarking Cassandra Scalability on AWS – Over a million writes per second

Para mais informações, acesse a documentação do projeto:
♦ About Apache Cassandra

Outros Links

♦ Alta Disponibilidade com Cloud Computing e Apache Cassandra
♦ O que é NoSQL?
♦ What is Apache Cassandra?


Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *