Quão longe você pode realmente ir com “eventual” consistência e nenhuma transação (aka SimpleDB)?

Question

Eu realmente quero usar SimpleDB, mas me preocupo que sem bloqueio real e transações de todo o sistema é fatalmente falho. Eu entendo que em alta leitura / low-escrever aplicativos que faz sentido, uma vez que, eventualmente, o sistema torna-se consistente, mas que sobre esse tempo entre os dois? Parece que a consulta direito em uma db inconsistente iria perpetuar o caos ao longo de todo o banco de dados de uma forma que é muito difícil de rastrear. Espero que eu esteja apenas sendo uma preocupação verruga ...

Answer 1

Esta é a batalha bastante clássica entre consistência e escalabilidade e - até certo ponto - a disponibilidade. Alguns dados nem sempre precisa ser tão consistente. Por exemplo, olhe para digg.com eo número de diggs contra uma história. Há uma boa chance de que valor é duplicado no registro "digg" ao invés de forçar o DB para fazer uma junção com a tabela da "user_digg". Não importa se esse número não é perfeitamente precisa? Provavelmente não. Em seguida, usando algo como SimpleDB pode ser um bom ajuste. No entanto, se você estiver escrevendo um sistema bancário, você deve provavelmente valor consistência acima de tudo. :)

Se você não sabe do dia 1 que você tem que lidar com escala maciça, gostaria de furar a simples sistemas mais convencionais, como RDBMS. Se você estiver trabalhando em algum lugar com um modelo de negócio razoável, você vai ver esperamos um grande aumento na receita se há um grande aumento no tráfego. Então você pode usar esse dinheiro para ajudar a resolver os problemas de escala. Scaling é difícil e de escala é difícil de prever. A maioria dos problemas de escala que ferem você vai ser aqueles que você nunca espera.

Eu prefiro obter um site fora do chão e passar algumas semanas correção de problemas de escala quando o tráfego pega então gastar tanto tempo se preocupando com escala que nunca fazê-lo para a produção porque ficar sem dinheiro. :)

Answer 2

Assumindo que você está falando sobre este SimpleDB, você 're não sendo um worrywart; há motivos reais para não usá-lo como um SGBD mundo real.

As propriedades que você recebe de suporte a transações em um SGBD pode ser abreviado pela sigla "A.C.I.D.": atomicidade, consistência, isolamento e durabilidade. A e D têm principalmente a ver com falhas no sistema, eo C e eu tenho a ver com a operação regular. Eles são todas as coisas que as pessoas totalmente tomar para concedido quando se trabalha com bases de dados comerciais, por isso, se você trabalha com um banco de dados que não tem um ou mais deles, você pode estar em qualquer número de surpresas desagradáveis.

Atomicity : Qualquer transação seja totalmente concluída ou não em todos (ou seja, ele quer confirmar ou anular limpa). Isto aplica-se às demonstrações individuais (como "UPDATE tabela ...") como transações bem como mais tempo, mais complicado. Se você não tem isso, então qualquer coisa que der errado (como, o disco ficar cheio, o computador travar, etc.) pode deixar algo meia-feito. Em outras palavras, você não pode nunca confiar nas DBMS para realmente fazer as coisas que você diga a ele, porque qualquer número de problemas do mundo real pode ficar no caminho, e até mesmo uma instrução UPDATE simples pode ficar parcialmente concluída.

Consistência : Todas as regras que você definiu-se sobre o banco de dados será sempre aplicada. Como, se você tem uma regra que diz que A é igual sempre B, então nada ninguém faz para o sistema de banco de dados pode quebrar essa regra - que vai deixar qualquer operação que tentativas. Esta não é tão importante se todo o seu código é perfeito ... mas realmente, quando é que alguma vez o caso? Além disso, se você está faltando esta rede de segurança, as coisas ficam realmente nojento quando você perde ...

Isolamento : Quaisquer ações tomadas no banco de dados será executado como se eles aconteceu em série (um de cada vez), mesmo que, na realidade, eles estão acontecendo simultaneamente (intercalados uns com os outros). Se mais de um usuário vai bater esse banco de dados, ao mesmo tempo, e você não tem isso, então as coisas que você não pode sequer sonhar vai dar errado; mesmo declarações atômicas podem interagir uns com os outros de maneiras imprevistas e estragar as coisas.

Durabilidade : Se você perder o poder ou as falhas de software, o que acontece com as operações de banco de dados que estavam em curso? Se você tem a durabilidade, a resposta é "nada - eles são todos seguros". Databases fazer isso usando algo chamado "Undo / Redo Log", onde cada pequena coisa que você faz para o banco de dados é registrado primeiro (geralmente em um disco separado para a segurança) de uma maneira tal que você pode reconstruir o estado atual após uma falha. Sem isso, as outras propriedades acima são uma espécie de inútil, porque você nunca pode ter 100% de certeza que as coisas vão ficar consistente depois de um acidente.

Não qualquer uma dessas coisas importa para você? A resposta tem tudo a ver com os tipos de transações que você está fazendo, e o que garante que você quer em uma situação de falha. Pode muito bem haver casos (como um banco de dados somente leitura), onde você não precisa destes, mas assim que você começar a fazer qualquer coisa não-trivial, e que algo ruim acontece, você vai desejar que você teve 'em. Talvez seja OK para você simplesmente reverter para uma qualquer momento algo de backup inesperado acontece, mas meu palpite é que ele não é.

Observe também que deixar cair todas estas proteções não torná-lo um dado que seu banco de dados terá um desempenho melhor; na verdade, é provavelmente o oposto. Isso porque o software do mundo real DBMS também tem toneladas de código para otimizar o desempenho da consulta. Então, se você escrever uma consulta que associa 6 mesas no SimpleDB, não pense que ele vai descobrir a melhor maneira de executar essa consulta - você pode acabar horas esperando por ele para completar, quando um SGBD comercial poderia usar um de hash indexada juntar e obtê-lo em .5 segundos. Há um zilhão de pequenos truques que você pode fazer para otimizar consulta performance, e acredite, você vai realmente sentir falta deles quando não funcionarem mais.

Nada disso é entendida como uma batida na SimpleDB; levá-lo a partir do autor do software: "Embora seja uma grande ferramenta de ensino, não posso imaginar que alguém iria querer usá-lo para qualquer outra coisa. "