quarta-feira, 14 de janeiro de 2015

NoSQL - teorema CAP

Claro que todos os benefícios não vem sem custo, comparado com os bancos de dados tradicionais vamos perder alguma funcionalidade/garantia para ganhar outra. O tradeoff arquitetural é descritono bem conhecido CAP theorem.

é preciso escolher entre consistência forte (C – Consistency)alta disponibilidade (A – availability) e tolerância a particionamento dos dados na rede(P – Network Partition Tolerance). Segundo o teorema CAP, entre as três propriedades, somente duas podem ser garantidas ao mesmo tempo.

Assim temos vários tipos diferentes de Nosql, combinando 2 das 3 características.

NoSQL Sistemas CP -> Consistência + Tolerância a particionamento de dados: é necessário abrir um pouco a mão da disponibilidade. Pode acontecer caso haja um particionamento e o sistema não entre em consenso que uma escrita seja retirada. Claro que os sistemas tentam evitar ao máximo que isso ocorra minimizando os problemas.
Exemplos: MongoDB, HBase, BigTable

NoSQL Sistemas AP -> Disponibilidade + Tolerância a particionamento: Existem sistemas que jamais podem ficar offline porém não desejam sacrificar a disponibilidade. Assim, para ter alta disponibilidade com tolerância a particionamento é necessário é preciso sacrificar sua consistência A ideia aqui é que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois (read-consistency). Então pode ter uma janela de inconsistência. Exemplos aqui são Amazon DynamoCassandra ou Riak.

Sistemas CA (Bancos Tradicionais) -> Consistência + disponibilidade: Os sistemas com consistência forte e alta disponibilidade (CA) (alta disponibilidade de um nó apenas) não sabem lidar com a possível falha de uma partição. Caso ocorra, sistema inteiro pode ficar indisponível até o membro do cluster voltar. Exemplos disso são algumas configurações clássicas de bancos relacionais.

Diferença entre CA e CP:
Vimos brevemente o teorema CAP e a escolha que os sistemas NoSQL fazem (CP ou AP) comparado com os bancos tradicionais (CA). É importante mencionar que para o desenvolvedor não haverá tantas diferenças entre CA ou CP. SEMPRE teremos consistência forte, no entanto, um sistema fica indisponível (CA) quando há particionamento – pois tem apenas alta disponibilidade por nó – e o outro sistema (CP) tente chegar a um consenso se aceita uma escrita ou não, que no pior dos casos também pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocínio podemos perceber que a consistência e disponibilidade são extremos quando há particionamento.

“… se há particionamento (P), o sistema pode valorizar a disponibilidade (A) ou a consistência (C), senão, quando o sistema roda sem partições, o sistema pode favorecer o tempo da resposta/latência (L) ou a consistência (C).”


FONTE:
http://blog.caelum.com.br/nosql-do-teorema-cap-para-paccl/


Nenhum comentário:

Postar um comentário