2
Na verdade, havia o FoundationDB que era compatível com o ácido. Agora a Apple o pegou
—
O usuário sem chapéu
Respostas:
Vou postar isso como uma resposta puramente para apoiar a conversa - Tim Mahy , nawroth e CraigTP sugeriram bancos de dados viáveis. O CouchDB seria o meu preferido devido ao uso do Erlang , mas existem outros por aí.
Eu diria que o ACID não contradiz ou nega o conceito de NoSQL ... Embora pareça haver uma tendência seguindo a opinião expressa por pomba , eu argumentaria que os conceitos são distintos.
O NoSQL é fundamentalmente sobre um esquema de valor-chave simples (por exemplo, Redis) ou estilo de documento (pares de valores-chave coletados em um modelo de "documento", por exemplo, MongoDB) como uma alternativa direta ao esquema explícito nos RDBMSs clássicos. Ele permite que o desenvolvedor trate as coisas de forma assimétrica, enquanto os mecanismos tradicionais impõem rígida uniformidade em todo o modelo de dados. O motivo é tão interessante porque fornece uma maneira diferente de lidar com as alterações e, para conjuntos de dados maiores, oferece oportunidades interessantes para lidar com volumes e desempenho.
O ACID fornece princípios que regem como as alterações são aplicadas a um banco de dados. De uma maneira muito simplificada, ele afirma (minha própria versão):
A conversa fica um pouco mais animada quando se trata da ideia de propagação e restrições . Alguns mecanismos RDBMS fornecem a capacidade de impor restrições (por exemplo, chaves estrangeiras) que podem ter elementos de propagação (à la cascata ). Em termos mais simples, uma "coisa" pode ter um relacionamento com outra "coisa" no banco de dados e, se você alterar um atributo de uma, pode exigir que a outra seja alterada (atualizada, excluída, ... muitas opções). Os bancos de dados NoSQL , sendo predominantemente (no momento) focados em altos volumes de dados e alto tráfego, parecem estar lidando com a idéia de atualizações distribuídas que ocorrem dentro de prazos arbitrários (da perspectiva do consumidor). Essa é basicamente uma forma especializada de replicação gerenciada viatransação - então eu diria que, se um banco de dados distribuído tradicional pode suportar ACID, o mesmo ocorre com um banco de dados NoSQL.
Alguns recursos para leitura adicional:
ATUALIZAÇÃO (27 de julho de 2012): o link para o artigo da Wikipedia foi atualizado para refletir a versão atual do artigo quando esta resposta foi publicada. Observe que o artigo atual da Wikipedia foi extensivamente revisado!
Bem, de acordo com uma versão mais antiga de um artigo da Wikipedia sobre NoSQL :
O NoSQL é um movimento que promove uma classe pouco definida de armazenamentos de dados não relacionais que rompe com um longo histórico de bancos de dados relacionais e garantias ACID.
e também:
O nome foi uma tentativa de descrever o surgimento de um número crescente de armazenamentos de dados distribuídos e não relacionais que geralmente não tentavam fornecer garantias ACID.
e
Os sistemas NoSQL geralmente oferecem garantias de consistência fraca, como consistência eventual e transações restritas a itens de dados únicos, mesmo que se possa impor garantias completas de ACID adicionando uma camada suplementar de middleware.
Então, resumindo, eu diria que um dos principais benefícios de um repositório de dados "NoSQL" é sua distinta falta de propriedades ACID . Além disso, IMHO, quanto mais você tenta implementar e aplicar as propriedades ACID , mais distante do "espírito" de um repositório de dados "NoSQL" você obtém e mais próximo de um RDBMS "verdadeiro" você obtém (relativamente falando, é claro )
No entanto, tudo o que foi dito, "NoSQL" é um termo muito vago e aberto a interpretações individuais, e depende muito de quanto ponto de vista purista você tem. Por exemplo, a maioria dos dias modernos RDBMS sistemas realmente não aderir a todos de Edgar F. Codd 's 12 regras de seu modelo de relação !
Adotando uma abordagem pragmática, parece que o CouchDB do Apache está mais próximo de incorporar a conformidade com ACID, mantendo a mentalidade "NoSQL" não-relacional e pouco acoplada.
Certifique-se de que você leia a introdução Martin Fowler sobre bancos de dados NoSQL . E o vídeo correspondente.
Primeiro de tudo, podemos distinguir dois tipos de bancos de dados NoSQL:
Por design, a maioria dos bancos de dados orientados a gráficos são ACID !
Então, e os outros tipos?
Nos bancos de dados orientados a agregados, podemos colocar três subtipos:
O que chamamos de Agregado aqui, é o que Eric Evans definiu em seu Design Orientado a Domínio como auto-suficiente de Entidades e Objetos de Valor em um determinado Contexto Limitado.
Como conseqüência, um agregado é uma coleção de dados com os quais interagimos como uma unidade. Agregados formam os limites para operações ACID com o banco de dados. (Martin Fowler)
Portanto, no nível agregado, podemos dizer que a maioria dos bancos de dados NoSQL pode ser tão segura quanto o ACID RDBMS , com as configurações adequadas. De origem, se você ajustar o servidor para a melhor velocidade, poderá entrar em algo que não seja ACID. Mas a replicação ajudará.
Meu ponto principal é que você precisa usar os bancos de dados NoSQL como eles são, não como uma alternativa (barata) ao RDBMS. Já vi muitos projetos abusando das relações entre documentos. Isso não pode ser ACID. Se você permanecer no nível do documento, ou seja, nos limites Agregados, não precisará de nenhuma transação. E seus dados estarão tão seguros quanto com um banco de dados ACID, mesmo que não seja verdadeiramente ACID, pois você não precisa dessas transações! Se você precisar de transações e atualizar vários "documentos" de uma só vez, não estará mais no mundo NoSQL - portanto, use um mecanismo RDBMS!
alguma atualização de 2019: a partir da versão 4.0, para situações que exigem atomicidade para atualizações em vários documentos ou consistência entre leituras para vários documentos, o MongoDB fornece transações com vários documentos para conjuntos de réplicas .
O FoundationDB é compatível com ACID:
Ele possui transações adequadas, para que você possa atualizar vários itens de dados diferentes de maneira ACID. Isso é usado como base para manter os índices em uma camada superior.
Nesta pergunta, alguém deve mencionar o OrientDB : O OrientDB é um banco de dados NoSQL, um dos poucos que suporta transações totalmente ACID. O ACID não é apenas para RDBMS porque não faz parte da álgebra relacional. Portanto, é possível ter um banco de dados NoSQL que suporte ACID.
Esse recurso é o que mais sinto falta no MongoDB
ACID e NoSQL são completamente ortogonais. Um não implica o outro.
Eu tenho um caderno na minha mesa, eu o uso para fazer anotações sobre coisas que ainda tenho que fazer. Este notebook é um banco de dados NoSQL. Eu o consulta usando uma pesquisa linear com um "cache de página", para que nem sempre seja necessário pesquisar todas as páginas. Também é compatível com ACID, pois asseguro que escrevo apenas uma coisa de cada vez e nunca enquanto estiver lendo.
NoSQL simplesmente significa que não é SQL. Muitas pessoas ficam confusas e acham que isso significa armazenamento altamente escalável-oeste selvagem-super-rápido. Não faz. Isso não significa armazenamento de valores-chave ou consistência eventual. Tudo o que isso significa é "não SQL", existem muitos bancos de dados neste planeta e a maioria deles não é SQL [citação necessária] .
Você pode encontrar muitos exemplos nas outras respostas, portanto não preciso listá-las aqui, mas existem bancos de dados não SQL com conformidade com ACID para várias operações, alguns são apenas ACID para gravações de objeto único, enquanto outros garantem muito mais. Cada banco de dados é diferente.
"NoSQL" não é um termo bem definido. É um conceito muito vago. Como tal, nem é possível dizer o que é e o que não é um produto "NoSQL". Nem todos os produtos tipicamente marcados com o rótulo são lojas de valor-chave.
Sim, o MarkLogic Server é uma solução NoSQL (banco de dados de documentos que gosto de chamar) que funciona com transações ACID
O avô do NoSQL: ZODB é compatível com ACID. http://www.zodb.org/
No entanto, é apenas Python.
Como um dos criadores do NoSQL (fui colaborador inicial do Apache CouchDB e palestrante no primeiro evento do NoSQL realizado na CBS Interactive / CNET em 2009), estou entusiasmado ao ver novos algoritmos criarem possibilidades que antes não existiam antes. . O protocolo Calvin oferece uma nova maneira de pensar em restrições físicas como CAP e PACELC .
Em vez de replicação assíncrona ativa / passiva ou replicação síncrona ativa / ativa, o Calvin preserva a correção e a disponibilidade durante interrupções de réplica usando um protocolo semelhante a RAFT para manter um log de transações. Além disso, as transações são processadas deterministicamente em cada réplica, removendo o potencial de conflitos, de modo que é alcançado um acordo com apenas uma única rodada de consenso. Isso o torna rápido mesmo em implantações em várias nuvens em todo o mundo.
O FaunaDB é a única implementação de banco de dados usando o protocolo Calvin, tornando-o adequado para cargas de trabalho que exigem integridade de dados do tipo mainframe com escala e flexibilidade NoSQL.
Se você está procurando um armazenamento de chave / valor compatível com ACID, existe o Berkeley DB . Entre os bancos de dados gráficos, pelo menos o Neo4j e o HyperGraphDB oferecem transações ACID (o HyperGraphDB atualmente usa o Berkeley DB para armazenamento de baixo nível no momento).
Este conceito que os colaboradores da Wikipedia definem como:
[…] Uma classe de sistemas modernos de gerenciamento de banco de dados relacional que procuram fornecer o mesmo desempenho escalável dos sistemas NoSQL para cargas de trabalho de leitura e gravação de processamento de transações on-line (OLTP), mantendo as garantias ACID de um sistema tradicional de banco de dados.
[1][2][3]
[1] Nancy Lynch e Seth Gilbert, “Conjectura de Brewer e a viabilidade de serviços da Web consistentes, disponíveis e tolerantes a partições” , ACM SIGACT News, Volume 33 Edição 2 (2002), pág. 51-59.
[2] "Teorema da tampa de cerveja" tampa , julianbrowne.com, recuperado em 02/03/2010
[3] "Teorema da cervejaria CAP em sistemas distribuídos" , royans.net
O MongoDB anunciou que sua versão 4.0 será compatível com ACID para transações com vários documentos.
Versão 4.2. deve suportá-lo em configurações fragmentadas.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
O FoundationDB foi mencionado e, na época, não era de código aberto. Ele foi aberto pela Apple há dois dias: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Eu acredito que é compatível com ACID.
Para adicionar à lista de alternativas, outro banco de dados NoSQL totalmente compatível com ACID é GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (recurso ACID) é proprietário, mas o Hyperdex é gratuito.
db4o
Diferentemente da persistência ou serialização de roll-your-own, o db4o é seguro para transações ACID e permite a consulta, replicação e alterações de esquema durante o tempo de execução
Tarantool é um banco de dados totalmente ACID NoSQL. Você pode emitir operações CRUD ou procedimentos armazenados, tudo será executado em estrita conformidade com uma propriedade ACID. Você também pode ler sobre isso aqui: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
O MarkLogic também é compatível com ACID. Eu acho que é um dos maiores jogadores agora.
A espera acabou.
Lançado o NoSQL DB compatível com ACID ----------- dê uma olhada no citrusleaf
O BergDB é um banco de dados NoSQL leve, de código aberto, projetado desde o início para executar transações ACID. Na verdade, o BergDB é "mais" ACID do que a maioria dos bancos de dados SQL, no sentido de que a única maneira de alterar o estado do banco de dados é executar transações ACID com o nível de isolamento mais alto (termo SQL: "serializable"). Nunca haverá problemas com leituras sujas, leituras não repetíveis ou leituras fantasmas.
Na minha opinião, o banco de dados ainda tem alto desempenho; mas não confie em mim, eu criei o software. Tente você mesmo.
Muitas soluções modernas de NoSQL não suportam transações ACID (atualizações atômicas de várias chaves isoladas), mas a maioria delas suporta primitivas que permitem implementar transações no nível do aplicativo.
Se um repositório de dados suporta linearização por chave e comparação e configuração (atomicidade no nível do documento), basta implementar transações do lado do cliente, além de você ter várias opções para escolher:
Se você precisar do nível de isolamento serializável, poderá seguir o mesmo algoritmo usado pelo Google para o sistema Percolator ou pelo Cockroach Labs for CockroachDB . Eu escrevi sobre o blog e criei uma visualização passo a passo . Espero que ajude você a entender a principal idéia por trás do algoritmo.
Se você espera uma alta contenção, mas não há problema em você ter o nível de isolamento Read Committed, consulte as transações de RAMP de Peter Bailis.
A terceira abordagem é usar transações compensatórias, também conhecidas como padrão de saga. Foi descrito no final dos anos 80 no jornal Sagas , mas se tornou mais atual com o aumento dos sistemas distribuídos. Consulte a palestra Aplicando o padrão da saga para se inspirar.
A lista de armazenamentos de dados adequados para transações do lado do cliente inclui Cassandra com transações leves, Riak com buckets consistentes, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB e outros.
O YugaByte DB suporta txns distribuídos compatíveis com ACID , bem como compatibilidade com API Redis e CQL na camada de consulta.
O VoltDB é um participante que reivindica conformidade com ACID e, embora ainda use SQL, seus objetivos são os mesmos em termos de escalabilidade
O nó levelUP é transacional e desenvolvido no leveldb https://github.com/rvagg/node-levelup#batch
O DynamoDB é um banco de dados NoSQL e possui transações ACID .
Não apenas o NoSQL não é compatível com ACID por design. O movimento NoSQL adota o BASE (Basicamente disponível, estado suave, consistência eventual) que afirma ser o oposto de ACID. O banco de dados NoSQL costuma ser chamado de banco de dados eventualmente composto. Para entender as diferenças, você deve se aprofundar no teorema da CAP (também conhecido como teorema de Brewer)
Visite http://www.julianbrowne.com/article/viewer/brewers-cap-theorem