ACID contra Stores base de dados
Uma característica dos sistemas de banco de dados relacional é algo conhecido como cumprimento ACID. Como você deve ter adivinhado, ACID é um acrônimo - as letras individuais, pretende descrever uma característica das operações de banco de dados individuais, pode ser expandido conforme descrito nesta lista:
Atomicidade: A transação deve completamente ter sucesso ou falhar completamente. O sucesso parcial não é permitido.
Consistência: Durante a operação de banco de dados, o RDBMS progride de um estado válido para outro. O estado nunca é inválido.
Isolamento: operação de banco de dados do cliente devem ocorrer de forma isolada a partir de outros clientes que tentam transaccionar com o RDBMS.
Durabilidade: A operação de dados que foi parte da transação deve reflectir-se armazenamento não-volátil (Memória de computador que pode recuperar a informação armazenada, mesmo quando não alimentado - como um disco rígido) e persistem depois que a transação for concluída com êxito. falhas de transações não podem deixar os dados em um estado parcialmente comprometida.
Alguns casos de uso para RDBMSs, como processamento de transações on-line, dependem de transações ACID-compliant entre o cliente eo RDBMS para o sistema para funcionar corretamente. Um grande exemplo de uma transação ACID-compliant é uma transferência de fundos de uma conta bancária para outra.
Este divide-se em duas operações de banco de dados, onde a conta de origem mostra uma retirada, e a conta de destino mostra um depósito. Obviamente, estas duas operações têm que ser amarrados juntos, a fim de ser válido para que, se qualquer um deles falhar, toda a operação deve deixar de garantir tanto saldos permanecem válidas.
-se Hadoop tem nenhum conceito de transações (ou mesmo registros, para que o assunto), por isso claramente não é um sistema ACID-compliant. Pensando mais especificamente sobre o armazenamento de dados e projetos de processamento em todo o ecossistema Hadoop, nenhum deles é totalmente ACID-compliant, qualquer um. No entanto, eles Faz reflectir propriedades que você vê frequentemente em armazenamentos de dados NoSQL, para que haja algum precedente para a abordagem Hadoop.
Um conceito chave por trás armazenamentos de dados NoSQL é que nem todo aplicativo realmente precisa transações ACID-compliant. Relaxamento em certas propriedades ACID (e se afastando do modelo relacional) abriu um leque de possibilidades, que permitiram que alguns armazenamentos de dados NoSQL para alcançar escalabilidade e desempenho para suas aplicações de nicho.
Considerando ACID define as características-chave necessárias para o processamento de transações de confiança, o mundo NoSQL requer características diferentes para permitir flexibilidade e escalabilidade. Estas características opostas são habilmente capturado na sigla BASE:
BasicallyUMAvailable: O sistema é garantido que estará disponível para consulta por todos os usuários. (Sem isolamento aqui.)
SEstado oft: Os valores armazenados no sistema pode mudar devido ao modelo de consistência eventual, como descrito na próxima bala.
Eventually consistente: Como os dados são adicionados ao sistema, o estado do sistema está gradualmente replicadas em todos os nós. Por exemplo, em Hadoop, quando um arquivo é gravado no HDFS, as réplicas dos blocos de dados são criados em diferentes nós de dados após os blocos de dados originais foram escritos. Para o curto período antes que os blocos são replicadas, o estado do sistema de arquivos não é consistente.
O acrônimo base é um pouco artificial, como a maioria dos armazenamentos de dados NoSQL não abandonar completamente todos as características ACID - não é realmente o conceito oposto que o nome implica, em outras palavras. Além disso, o Estado Macio e características Eventualmente consistentes atingir a mesma coisa, mas o ponto é que, ao relaxar a consistência, o sistema pode horizontalmente escala (muitos nós) e garantir a disponibilidade.
Nenhuma discussão sobre NoSQL seria completa sem mencionar o teorema PAC, que representa os três tipos de garantias que os arquitetos visam fornecer em seus sistemas:
Consistência: Semelhante ao C no ácido, todos os nós no sistema teria a mesma visão dos dados a qualquer momento.
Disponibilidade: O sistema sempre responde às solicitações.
tolerância partição: O sistema permanece on-line se problemas de rede ocorrer entre nós do sistema.
O teorema CAP afirma que em sistemas de rede distribuída, arquitetos tem que escolher duas dessas três garantias - você não pode prometer seus usuários todos os três. Isso te deixa com as três possibilidades mostradas:
Os sistemas que utilizam tecnologias relacionais tradicionais normalmente não são particionar Tolerante, para que eles possam garantir a consistência e disponibilidade. Em suma, se uma parte desses sistemas tecnologias relacionais tradicionais está offline, todo o sistema está offline.
Sistemas onde a tolerância partição e disponibilidade são de importância primária não pode garantir a consistência, porque actualizações (que destruidor de consistência) pode ser feita em ambos os lados da partição. As lojas de valor-chave do Dínamo e do CouchDB e na loja coluna da família de Cassandra são exemplos populares de divisórias tolerantes / disponibilidade (PA).
Sistemas onde a tolerância partição e consistência são de importância primária não pode garantir a disponibilidade, pois os sistemas de retornar erros até que o estado particionado seja resolvido.
armazenamentos de dados com base em Hadoop são considerados sistemas de CP (consistent e partition tolerante). Com os dados armazenados de forma redundante através de muitos nós escravos, interrupções para grandes porções (partições) de um cluster Hadoop podem ser tolerados. Hadoop é considerado para ser coerente porque tem um repositório de metadados central (o NameNode) que mantém uma visão única e consistente de dados armazenados no cluster.
