Conheça o Apache Cassandra

Ele é um banco de dados distribuído, multi primary, bem resistente a falhas, com consistência ajustável. Vários termos interessantes, que vemos quase cotidianamente e que talvez nem precisássemos falar a respeito. Mas vamos brevemente discutir cada um destes pontos.

Banco de dados distribuído refere-se ao fato de que em um cluster todos os nodes são similares, executando a mesma função. Cada node é responsável por parte dos dados e recebe escritas e leituras. Não temos aquela estrutura primary-secondary tradicional em outros DBs, aqui todo mundo é primary.

O fato de ser resistente à falha é algo que o Cassandra herdou do DynamoDB. O DynamoDB (e consequentemente o Cassandra) foi construído para ser always writable. Se temos um cluster de 10 nodes e perdemos um node, qualquer outro node pode processar a requisição em seu lugar. Estas escritas ficam armazenadas em uma estrutura chamada hinted handoff, que merece um artigo inteiro para os detalhes. Estas escritas são então entregues para o node caso ele volte a vida. Além disso, normalmente o dado é replicado para outros nodes, que podem servir a leituras em caso de um node em falha. O número de réplicas é controlado pelo atributo Replication Factor das Keyspaces (falaremos disso mais tarde, mas é como um database em um mysql ou mongodb).

E nessa linha de réplicas a gente entra no tema consistência ajustável. Ainda sobre a tolerância a falhas, há casos em que não conseguimos manter tudo igual em todas as réplicas. Por default um node armazena hints handoff por 3 horas. Um node down por mais de 3 horas pode ser um problema pois ele vai perder parte das escritas. Para nossa sorte o Cassandra já vem com uma funcionalidade que repara estes problemas, mas o repair (como chamamos esse processo de sincronizar as réplicas) também é assunto para um ou mais artigos, dado sua importância. 

Agora que entendemos a origem de um dos problemas que causam uma bagunça nos dados (um de muitos, acredite) começa a fazer sentido a necessidade de controlar a consistência de leitura e escrita. Você pode querer escrever em apenas um node e deixar que a replicação seja feita (async). Em uma fração de segundos você pode consultar esse dado em outro node e ele estará replicado. Mas e se o node que receber a escrita falhar antes de replicar seu dado? Sim, pode acontecer e nesse caso você perde sua escrita. Aí entra o tema consistência (oba! Tema para mais um artigo). Em uma forma reduzida podemos dizer que o cliente tem a opção de escolher quantas réplicas ele deseja envolver na sua requisição: apenas uma, a maioria, a maioria em um datacenter (a mais comum), todas. Enfim, o cliente é quem manda.