O teorema CAP Claro que todos os benefcios no vem sem custo, comparado com os bancos de dados tradicionais vamos

perder alguma funcionalidade/garantia para ganhar outra. Consistancy: todos os clientes ver os dados atuais, independentemente da atualizao ou excluir Availability: o sistema continua a funcionar como o esperado, mesmo com falhas nos ns Partition Tolerance: o sistema continua a funcionar como o esperado, apesar de falhas de rede ou mensagens de erro. No teorema preciso escolher entre consistncia forte (C Consistency), alta disponibilidade (A availability) e tolerncia a particionamento dos dados na rede(P Network Partition Tolerance). Segundo o teorema CAP, entre as trs propriedades, somente duas podem ser garantidas ao mesmo tempo: Partition-Tolerance Poder particionar nossos dados em diferentes ns de um cluster um dos recursos que aparecem com frequncia nos bancos NoSQL. Saber lidar com a separao/particionamento das dados devido uma falha na rede conhecido como Partition-Tolerant. No entanto, segundo o teorema CAP, em troca eles iro sacrificar a consistncia forte ou a alta disponibilidade. Isso diferente dos bancos tradicionais, que no possuem essa caracterstica no design do sistema ou delegam isso para o filesystem. NoSQL 1: Sistemas CP Para sistemas que precisam da consistncia forte e tolerncia a particionamento (CP) necessrio abrir a mo da disponibilidade (um pouco). Pode acontecer, caso haja particionamento e o sistema no entre em consenso, que uma escrita seja rejeitada. Claro que os sistemas tentam evitar isso ao mximo, tanto que no costuma existir, por exemplo, uma transao distribuda e sim um protocolo de consensos para garantir a consistncia forte. Exemplos desses sistemas CP soBigTable, HBase ou MongoDB entre vrios outros. NoSQL 2: Sistemas AP Por outro lado existem sistemas que jamais podem ficar offline (24/7), portanto no desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com um tolerncia a particionamento (PA) preciso prejudicar a consistncia (eventual-consistency). A ideia aqui que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois ( read-consistency). Ento pode ter uma janela de inconsistncia. Exemplos aqui so Amazon Dynamo, Cassandra ou Riak. Sistemas CA Os sistemas com consistncia forte e alta disponibilidade (CA) (alta disponibilidade de um n apenas) no sabem lidar com a possvel falha de uma partio. Caso ocorra, sistema inteiro pode ficar indisponvel at o membro do cluster voltar. Exemplos disso so algumas configuraes clssicas de bancos relacionais. Qual a diferena entra 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 no haver tantas diferenas entre CA ou CP. SEMPRE teremos consistncia forte, no entanto, um sistema fica indisponvel (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 no, que no pior dos casos tambm pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocnio podemos perceber que a consistncia e disponibilidade so extremos quando h particionamento. Isso foi uma dvida que me incomodou bastante antes da minha palestra no Caelumday 2009. Podemos concluir que quando h particionamento (P) ter alta disponibilidade (A) ou consistncia (C) forte: P?(A|C)

2.1Teorema Cap
Existem muitos motivos para se usar os bancos de dados NoSQL, como por exemplo usar um modelo mais adequado para os seus dados ou facilitar alteraes no esquema, ou at melhorar o desempenho e simplificar a replicao para se alcanar a escalabilidade linear. Como no conseguimos usar todos esses benefcios sem um custo, vamos perder alguma funcionalidade para se ganhar outra. Primeiramente explicaremos cada um dos 3 pontos

do Teorema CAP, que so a Consistncia, Disponibilidade e a Tolerncia a falhas. Consistency (Consistncia): Consistncia a caracterstica que descreve como e se o estado de um sistema fica consistente aps uma operao. Num sistema distribudo de dados, isto, normalmente significa que uma vez escrito um registo, este fica disponvel para ser utilizado imediatamente, ou seja, cada cliente tem sempre a mesma viso dos dados. Availability (Disponibilidade): Refere-se concepo e implementao de um sistema de modo que seja assegurado que este permanece ativo durante um determinado perodo

de tempo. Neste contexto, significa que um sistema tolerante a falhas de software/hardware e normalmente tambm permanece disponvel durante a atualizao de software e hardware. Um bom exemplo seria falar que todos os clientes de uma empresa que acessam um a aplicao web, podem sempre ler e atualizar dados na aplicao.

Partition Tolerance (Tolerncia ao Particionamento): Refere-se a capacidade de um sistema continuar operando mesmo depois uma falha na rede. Ou seja, significa garantir que operaes sero completadas, mesmo que componentes individuais no estejam disponveis. Tolerncia ao Particionamento a capacidade de um sistema se manter operante mesmo em casos onde ocorra uma interrupo parcial de alguns componentes.

Explicado os trs pontos principais que um sistema web dever ter, o teorema CAP explica que em sistema distribudo preciso escolher entre duas dessas propriedades, nunca conseguindo usar as trs ao mesmo tempo. Assim preciso escolher entre Consistncia forte, alta disponibilidade e tolerncia ao particionamento. Sendo que entre as trs propriedades, somente duas podem ser garantidas ao mesmo tempo. Seguindo essa ideia podemos ter trs tipos de sistemas:

Sistemas CA: Os sistemas com consistncia forte e alta disponibilidade (CA) (alta disponibilidade de um n apenas) no sabem lidar com a possvel falha de uma partio. Caso ocorra, sistema inteiro pode ficar indisponvel at o membro do cluster voltar. Exemplos disso so algumas configuraes clssicas de bancos relacionais.

Sistemas CP: Para sistemas que precisam da consistncia forte e tolerncia a particionamento necessrio abrir a mo da disponibilidade (um pouco). Pode acontecer, caso haja particionamento e o sistema no entre em consenso, que uma escrita seja rejeitada. Claro que os sistemas tentam evitar isso ao mximo, tanto que no costuma existir, por exemplo, uma transao distribuda e sim um protocolo de consensos para garantir a consistncia forte. Exemplos desses sistemas CP so BigTable, HBase ou MongoDB entre vrios outros.

Sistemas AP: Por outro lado existem sistemas que jamais podem ficar offline, portanto no desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com uma tolerncia a particionamento preciso prejudicar a consistncia. A ideia aqui que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento

depois (read-consistency). Ento pode ter uma janela de inconsistncia. Exemplos aqui so Amazon Dynamo, Cassandra ou Riak.