Vamos falar hoje sobre NoSQL, você já ouviu falar disto? O nosso desenvolvedor André Zarlenga vai te contar tudo que sabe sobre eles.

 

Introdução

No passado, quando queríamos aumentar nosso poder de processamento, a opção comum era escalar verticalmente (obter máquinas com maior capacidade de processamento) ou otimizar ainda mais a base de códigos existentes.

No entanto, com os avanços no processamento paralelo e nos sistemas distribuídos, é mais comum expandir horizontalmente ou ter mais máquinas para executar a mesma tarefa em paralelo.

No cenário de banco de dados, temos uma gama de opções para trabalhar de forma escalável, e o primeiro termo que nos é dito: NOSQL.

Mas antes de tomar essa decisão sobre qual utilizar, devemos conhecer algo muito relevante

para escolher efetivamente, é necessária uma ideia básica do Teorema CAP.

O Teorema CAP é um conceito que descreve o comportamento do sistema distribuído. Seu comportamento apresenta nós interconectados no compartilhamento de dados de 2 itens dos 3 disponíveis.

Consistência

Indica que os dados são os mesmos no cluster, para que você possa ler ou escrever em qualquer nó e obter os mesmos dados.

Disponibilidade

Indica a capacidade de acessar o cluster, mesmo se um nó no cluster ficar inativo.

Tolerância de Partição

Indica que o cluster continua funcionando mesmo se houver uma “partição” (quebra de comunicação) entre dois nós (ambos os nós estão ativos, mas não podem se comunicar).

Quando penso em NOSQL, me vem à mente a palavra: Abdicar. Devemos abdicar de dois itens acima, para se trabalhar com algum banco de dados NOSQL.

A web tem exigido um nível de armazenamento e disponibilidade exorbitante e crescente. O banco relacional não se mostra tão eficiente em alguns cenários, e arrisco a dizer que é dispendioso.

Em alguns cenários não é possível trabalhar somente com NOSQL, ou somente com relacional, muitos softwares tem caminhado para trabalhar com diversas fontes de dados, para atender seus requisitos. Como você vai entender abaixo.

Em resposta ao crescente tamanho de armazenamento, os sistemas NOSQL evitavam a natureza normalizada, ao invés de otimizar a gravação e a flexibilidade de leitura. O NOSQL enfatizou a otimização de leitura, através de dados que devem ser organizados para permitir pesquisas simples e rápidas para casos de uso específicos.

Essa natureza desnormalizada também facilitou a fragmentação horizontal de seus dados. Anteriormente, espalhar subconjuntos de dados por várias máquinas poderia encarecer ao criar JOINs entre elas, pois a I/O da rede é significativamente mais lenta do que a memória ou o disco.

No entanto, se seus dados forem pré-montados no formato necessário ao cliente sem JOINs, cada consulta poderá atingir o nó específico que contém os dados relevantes sem qualquer comunicação entre nós.

ACID – (Atomicidade, Consistência, Isolamento e Durabilidade)

Não posso descrever sobre as escolhas do teorema CAP, sem discorrer sobre ACID.

As propriedades do ACID se concentram na consistência e são abordagens tradicionais dos bancos de dados relacionais, que garantem a integridade do dados.

Atomicidade (A)

Todos os sistemas se beneficiam de operações atômicas. Quando o foco é a disponibilidade, os dois lados de uma partição ainda devem usar operações atômicas. Além disso, essas operações de nível superior (do tipo que o ACID implica), na verdade, simplificam a recuperação.

 

Consistência (C)

Significa que uma transação preserva previamente todas as regras do banco de dados, como chaves exclusivas. A transação cria um novo estado válido dos dados, ou em caso de falha, retorna todos os dados ao seu estado anterior ao início dela.

 

Isolamento (I)

Uma transação em andamento, mas ainda não validada, deve permanecer isolada de qualquer outra operação, ou seja, garantimos que a transação não será interferida por nenhuma outra concorrente.

 

Durabilidade (D)

Dados validados são registados pelo sistema de tal forma que mesmo no caso de uma falha e/ou reinício do sistema, estarão disponíveis em seu estado correto.

 

As regras citadas acima definem se o banco de dados pode encaixar-se como um SGBD (existem mais regras, como integridade referencial. Não vou me aprofundar nestes detalhes no artigo).

Com o ACID temos a garantia de que um determinado dado em uma transação é coerente, ou é mantido por completo, ou descartado como igual. Por exemplo, Imagine um cenário onde temos que inserir um pedido de compra. Neste processo, temos que incluir nos itens do pedido os dados de pagamento.

Nesse meio tempo, caso ocorra um erro, ao inserir o pagamento, por exemplo, a transação será desfeita por completo.

Este pode parecer um cenário simples, mas vamos adicionar um regra que pode fazer a diferença. No momento da compra, deve ser realizada uma baixa no estoque do referido produto, e que o sistema não permita vender o produto duas vezes.

Vamos para um exemplo um pouco mais complexo, supondo um cenário onde um sistema vende frações de ações, com valor de mercado variado, conforme um índice. Seria impraticável vender um conjunto de frações por um valor desatualizado, mesmo que seja por nano segundos (o tempo não vira argumento de justificativa), se tratando de um ambiente multi usuário, isso pode ocorrer.

 

Escolha do modo de operação

Como mencionei anteriormente, devemos escolher um modo que pretendemos trabalhar com o NOSQL, são eles:

CA (Consistente e Disponível)

Os sistemas de CA são sistemas consistentes e disponíveis na ausência de qualquer partição de rede. Geralmente, os servidores de banco de dados de um único nó são classificados como sistemas de CA. Os servidores de banco de dados de nó único não precisam lidar com a tolerância de partição.

 

CP (Consistente e Tolerante a partições)

Um sistema consistente e tolerante a partições, mas nunca disponível. O CP está se referindo a uma categoria de sistemas em que a disponibilidade é sacrificada apenas no caso de uma partição de rede.

AP (Disponível e Tolerante a partições)

Estes são sistemas disponíveis e tolerantes a partições, mas não podem garantir consistência.

Representação de CAP

 

O que não te disseram sobre NOSQL - Representação de CAP

Representação de CAP

 

CA (Consistente e Disponível)

Este modelo fornece consistência e disponibilidade em todos os nós. No entanto, não é possível fazer isso se houver uma partição entre dois nós no sistema e, portanto, não oferecer tolerância a falhas.

O que não te disseram sobre NOSQL- CA Consistente e Disponível

CA Consistente e Disponível

 

AP (Disponível e Tolerante a partições)

Este modelo, ao contrário do CP, possui uma arquitetura sem mestre e, como resultado, possui vários pontos de falha, em vez de um único.

AP oferece disponibilidade e tolerância à partição, mas não pode fornecer consistência o tempo todo. Como não possui um nó principal, todos os nós devem estar disponíveis continuamente, ou seja, fornecendo consistência eventual, permitindo que os clientes gravem em qualquer nó a qualquer momento e reconciliando inconsistências o mais rápido possível.

 

O que não te disseram sobre NOSQL - AP (Disponível e Tolerante a partições

AP (Disponível e Tolerante a partições)

 

CP (Consistente e Tolerante a partições)

Quando o nó primário ficar indisponível, o nó secundário com o log de operações mais recente será eleito como o novo nó primário. Depois que todos os outros nós secundários alcançarem o novo mestre, o cluster ficará disponível novamente. Como os clientes não podem fazer nenhuma solicitação de gravação durante esse intervalo, os dados permanecerão consistentes em toda a rede.

 

O que não te disseram sobre NOSQL - CP (Consistente e Tolerante a partições)

CP (Consistente e Tolerante a partições)

Conclusão

Os sistemas distribuídos nos permitem atingir um nível de capacidade e disponibilidade de computação que simplesmente não estavam disponíveis no passado.

Nossos sistemas têm maior desempenho, menor latência e maior disponibilidade. Porém vai muito além de trabalhar com o requisito do NOSQL e onde aplicar. Não é atoa que o SGBD está vivo até hoje, estamos nos referindo a operações matemáticas, onde uma mesma condição de um dado, não pode ser 2 ao mesmo tempo, ou seja, cabe escolher o modelo adequado do tipo de armazenamento.

É necessário entender a complexidade incorrida nos sistemas distribuídos, fazer as trocas apropriadas para a tarefa em questão (CAP) e selecionar a ferramenta certa para o trabalho com a escala horizontal.