[SP-pm] [OT] NoSQL

[Nuba Princigalli]

Caros,

Pertinente à discussão, reparar que a discussao continua muito boa nos comentarios:
http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext

Abraco,

Nuba

On Sun, 6 Jun 2010, Otávio Fernandes wrote:

> Date: Sun, 6 Jun 2010 10:58:33 +0200
> From: Otávio Fernandes <otaviof em gmail.com>
> Reply-To: saopaulo-pm em mail.pm.org
> To: saopaulo-pm em mail.pm.org
> Subject: Re: [SP-pm] [OT] NoSQL
> 
> 2010/6/4 Thiago Rondon <thiago em aware.com.br>:
>> Em 04/06/10 05:51, Otávio Fernandes escreveu:
>>>
>>> O meu ponto de vista sobre este assunto é ligado ao CAP Theorem
>>> (http://en.wikipedia.org/wiki/CAP_theorem). Para os que não conhecem,
>>> vou tentar resumir:
>>>
>>> O Teorema CAP afirma que é impossível para um sistema distribuído
>>> garantir simultaneamente todos os três itens abaixo:
>>>
>>> * Consistência: todos os nós veem o mesmo dado ao mesmo tempo;
>>> * Disponibilidade: falhas entre os nós não previnem que os
>>> sobreviventes continuem a funcionar;
>>> * Tolerância ao Particionamento: o sistema continua a operar mesmo com
>>> perda arbitraria de mensagens entre os nós;
>>>
>>> De acordo com o teorema, um sistema distribuído consegue apenas
>>> satisfazer dois destes requisitos.
>>>
>>> A resposta que define se você é um candidato ou não para um NoSQL e
>>> para saber qual deles serve para a sua necessidade, é perguntar-se
>>> qual dos pontos acima você pode abrir mão. Porque, (sem entrar em
>>> detalhes) em um banco relacional (leia-se SQL), tentam garantir os
>>> três, e por isso, sofrem ao tentar abraçar grandes requisições (e este
>>> resultado é o esperado).
>>>
>>
>> Otávio,
>>
>> Eu discordo contigo sobre um banco relacional garantir todos os itens do
>> teorema de CAP, os bancos tradicionais como PosgreSQL/Oracle são apenas
>> "C-A" (Consistency-Availability), enquanto os que estão fora de um esquema
>> de relacionamento são "A-P" (Availability-Partition Tolerance).
>
> E quanto as soluções de cluster? Elas foram feitas para cobrir a parte
> de particionamento, porem, tem um custo técnico muito alto, e, a
> capacidade de escalar é limitada.
>
>> Em relação a definição de "tolerância ao particionamento",  em um sistema
>> relacional quando os servidores se dividem por um problema de rede, você
>> precisa escolher que "lado" esta "certo".
>
> Neste caso, vai depender da solução adotada. Eu não sou DBA, mas vejo
> que os sistemas de cluster (SQL-like) são feitos para evitar este tipo
> de problema (se isso acontece na vida real ou não, são "outros
> quinhentos"). Se for uma estrutura de replicação, o problema é mais
> fácil de resolver.
>
>> Quando você  esta orientado a consistência e a disponibilidade, teoricamente
>> você deve abrir mão da tolerância de falhas no particionamento.
>
> Sim, este é o trade-off que eu havia comentado no primeiro e-mail (CAP
> Theorem). É é exatamente o que um Oracle Cluster, por exemplo, tenta
> evitar.
>
>> Meus centavos,
>> -Thiago Rondon
>> _______________________________________________
>> SaoPaulo-pm mailing list
>> SaoPaulo-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
> um abraço,
>
>

--