Apache Cassandra: Modelando os dados de sua aplicação NoSQL

Atualmente, grande parte dos sistemas já opera através da Internet. Como consequência disso, eleva-se a quantidade potencial de usuários e passa-se a expor as limitações das tecnologias tradicionais.

Em muitos casos essa exposição se deu pelo fato dos sistemas terem apresentado um crescimento bastante elevado do número de acessos, o que culminou em um aumento exponencial do volume de dados a tal ponto que os bancos relacionais passaram a ter dificuldades em processar as requisições com um tempo de resposta satisfatório.

A solução, então, seria escalar o banco de dados verticalmente, adicionando mais recursos de hardware numa mesma máquina, de forma a garantir um desempenho aceitável para o sistema.

Entretanto, os custos com isso podem se tornar proibitivos, assim como em algum momento o limite dessa escalabilidade pode ser alcançado. Diante disso, os bancos de dados relacionais se tornaram um gargalo na arquitetura desses sistemas.

Essas limitações fizeram com que os pesquisadores buscassem alternativas para melhorar o desempenho e, a partir daí, criaram opções de replicação de dados dos bancos relacionais em vários nós (mestre-escravo, mestre-mestre) e os particionamentos vertical e horizontal.

Dessa forma, foi criada a possibilidade de se escalar horizontalmente um banco de dados relacional. Entretanto, os pesquisadores notaram que para grandes volumes de dados, o custo de se manter uma estrutura de hardware para escalar horizontalmente de forma satisfatória era proibitivo.

Esse elevado custo se dava por conta das características ACID (Atomicidade, Consistência, Integridade e Disponibilidade) do banco de dados. Para garantir essas propriedades, o banco terminava por fazer pesquisas em todos os nós do cluster de dados a fim de realizar as operações de JOIN, precisava fazer leituras (muitas vezes em vários nós) antes de escrever ou atualizar os dados, entre outros detalhes.

Todo esse comportamento levou a um custo muito alto para se realizar consultas, aumentando o tempo das mesmas de tal forma que se tornaram inviáveis. Nesse momento, negócios que necessitavam de respostas rápidas, principalmente os de operações críticas, começaram a sofrer com essas dificuldades e tiveram que buscar alternativas.

A opção que se encontrou foi baseada no teorema de CAP, o qual conceitua que é impossível, para um sistema distribuído, garantir as características de consistência (só existe um único valor em todo o cluster para um mesmo registro), disponibilidade (é possível executar operações com sucesso a qualquer momento/tempo razoável) e tolerância a falhas (sistema continua a operar mesmo se um nó tiver falha de rede).

Portanto, só é possível construir sistemas distribuídos que atendam a no máximo duas das características do teorema de CAP, sendo necessário, portanto, flexibilizar as regras de armazenamento de dados em troca de maior escalabilidade e performance.

Esse conceito é válido até mesmo para os bancos de dados relacionais, quando se opta por escalá-los horizontalmente, pois se houver falha de rede em algum nó, algumas consultas podem não ser executadas.

Obviamente, com o aumento do volume de dados, se faz necessário escalonar horizontalmente, a fim de aumentar a capacidade de processamento e armazenamento, diminuir custos (nós simples em vez de máquinas poderosas) e aumentar a disponibilidade.

Essa necessidade fez com que surgissem os bancos de dados NoSQL, como o Cassandra, o qual faz uso do conceito de consistência eventual, garantindo apenas a disponibilidade e tolerância a falhas.

A consistência eventual significa que se nenhuma atuali ...