
é 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 Dynamo, Cassandra 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