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.
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.
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.
- 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).
Comentários