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) quando você faz algo para alterar um banco de dados, a alteração deve funcionar ou falhar como um todo
(C) o banco de dados deve permanecer consistente (este é um tópico bastante amplo)
(I) se outras coisas estiverem acontecendo ao mesmo tempo, elas não poderão ver as coisas no meio da atualização
(D) se o sistema explodir (hardware ou software), o banco de dados precisa ser capaz de se recuperar; e se ele diz que terminou de aplicar uma atualização, precisa ter certeza
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.
Boa resposta. Você pode ter NoSQL + ACID e não-ACID-RDBMS (pense em MySQL + MyISAM). Eu normalmente consideraria o NoSQL "eventualmente consistente". Também vou jogar o teorema da PAC ... :-)
gbn 27/02
+1 @gbn pela menção do teorema da PAC. Estar mais familiarizado com os bancos de dados "nosql" agora do que eu era naquela época apenas reforçou a separação dos conceitos. Além disso, bancos de dados de valor-chave e doc, pois existem diferenças arquiteturais.
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!
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.
+1 Não tenho certeza se concordo que a falta de ACID seja uma característica essencial do "NoSQL", mas eu realmente aprecio a sua descrição. Em última análise, deve ser sobre uma solução que se encaixa.
AJ.
2
Eu editei (revisão pendente) para tentar deixar ainda mais claro. Não há nada nos datamodels NoSQL que implique que transações ACID não sejam possíveis. Alguns sistemas distribuídos NoSQL não os possuem. Alguns realmente ficam sem nenhuma "camada de middleware".
Eric Bloch
2
Isso nunca foi correto e até perdeu a fonte. Realmente deve ser excluído.
Lennart Regebro 15/05
2
Bem, o que é mais evidente: "em poucas palavras, eu diria que um dos principais benefícios de um repositório de dados" NoSQL "é sua distinta falta de propriedades ACID". Você também implica que o NoSQL e o ACID de alguma forma são mutuamente exclusivos, o que é definitivamente incorreto. Este é um bom exemplo de quando um grande número de pessoas ignorantes promove uma resposta incorreta, porque parece razoável. O fato de a maioria dos bancos de dados NoSQL não ser compatível com ACID é principalmente porque as pessoas implementadas não sabiam o que era / por que era importante / não se importavam.
Lennart Regebro
@LennartRegebro - Eu não impliquei nada disso. A conformidade com o ACID foi de fato evitada pela maioria dos bancos de dados NoSQL existentes e atuais em favor da velocidade / desempenho e eventual consistência. Eu nunca disse que você não poderia ter NoSQL com conformidade com ACID.
Primeiro de tudo, podemos distinguir dois tipos de bancos de dados NoSQL:
Bancos de dados agregados;
Bancos de dados orientados a gráficos (por exemplo, Neo4J).
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:
Bancos de dados NoSQL baseados em documentos (por exemplo, MongoDB, CouchDB);
Bases de dados NoSQL de chave / valor (por exemplo, Redis);
Bancos de dados NoSQL da família de colunas (por exemplo, Hibase, Cassandra).
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 .
Há casos em que há um grande processo / saga que lida com muitos agregados. Há casos em que um comando enviado a um agregado pode acionar alguns eventos que alteram outros agregados. Nesses casos, você precisa de repositórios de dados compatíveis com ACID.
Tudor
1
@TudorTudor, mas neste caso você está violando um dos princípios nosql, já que o está usando como um rdbms. Você só precisa de agregados maiores ou versões dos documentos (como no couchdb). O db orientado a documentos do Nosql é ácido nos limites do documento / agregado.
Arnaud Bouchez
Nenhum dos que você listou é compatível com ácidos. O Mongo simplesmente não é compatível com ACID. O CouchDB finge que é compatível com ácido, desde que você não esteja atualizando dois documentos. O Redis possui apenas "suporte parcial para transações". O HBase não é compatível com ácidos (dos desenvolvedores) , nem Cassandra. Essa resposta está de fato errada. Nenhum desses bancos de dados suporta o ACID, e a maioria deles possui-o abertamente com uma simples pesquisa no Google.
Evan Carroll
@EvanCarroll Eu nunca escrevi que o MongoDB é compatível com ACID, no mesmo significado de uma transação ACID RDBMS. Não há transação disponível. O que escrevi é que a maioria dos bancos de dados NoSQL pode ser tão segura quanto o ACID RDBMS, com as configurações adequadas . Por exemplo, verifique o operador MongoDB $ isolado para um banco de dados sem nenhum cluster compartilhado. Eu nunca usaria o MongoDB para processos financeiros, mas poderia confiar em seu processo de gravação até certo ponto, para operações do tipo ACID, se o A for Atomicity for suficiente. Desculpe se minha resposta é confusa.
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.
infelizmente, não é de código aberto. Mas parece um banco de dados muito bom.
Kevin Cox
Para adicionar a resposta @ Ken-Tindell, o djondb também é NoSQL e implementa transações e é compatível com ACID. djondb.com Concordo que NoSQL é apenas um termo para cunhar todos os bancos de dados que não seguem as regras tradicionais do RDBMS, não significa "livrar-se dos sistemas TX" ou esquecer os relacionamentos.
Cruz
3
Minha resposta foi discutida pela aquisição da Foundation DB pela Apple.
Ken Tindell
1
foundationdb agora é open
source da
17
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.
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.
Só para ser pedante, mas isso normalmente significa 'Não só SQL' :-)
shmish111
4
@ shmish111 não realmente. Significou "No SQL" quando o termo foi cunhado pela primeira vez. O "o" é pequeno, afinal não é capital. Mais tarde, houve tentativas de reinicializar o termo como "Não apenas SQL" quando alguns desses (produtos NoSQL) começaram a adicionar interfaces de linguagem de consulta semelhantes a SQL.
precisa saber é o seguinte
11
"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.
Melhor resposta. Sempre que ocorre essa guerra de chamas, eu gostaria de perguntar à outra parte quais recursos definidores eles exigem explicitamente de um banco de dados NoSQL e geralmente se sobrepõe aos recursos que podem ser encontrados em um RDBMS - não porque um ou RDBMSs se encaixam no tema NoSQL, mas simplesmente porque os 'requisitos' de recursos são tão vagos que não negam completamente, recursos encontrados em (nem todos necessariamente) RDMBSs. +1 para o seu comentário companheiro!
StartupGuy
8
Sim, o MarkLogic Server é uma solução NoSQL (banco de dados de documentos que gosto de chamar) que funciona com transações ACID
O MarkLogic possui transações ACID, transações com vários documentos, transações com várias instruções e suporte para XA - tudo em todo o cluster / distribuído.
Para aqueles que desejam fazer a transição da biblioteca "arquivar" do python, achei o ZODB quase sem aparência. Não precisei reescrever todas as minhas funções - basta acessar o ZODB como um dicionário, assim como arquivar, mas é uma ordem de magnitude mais rápida.
Michael Galaxy
8
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).
[…] 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]
Sim, agora as transações ACID para vários documentos são suportadas no MongoDB. Consulte mongodb.com/transactions para obter mais informações e vídeos detalhados sobre como eles foram implementados.
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 Aerospike suporta transações ACID com várias chaves? AKAIK é limitado a transações de chave única.
eonil
1
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 criador do VoltDB mencionou que eles não se rotulam como NoSQL, mas mais como NewSql (ainda usando SQL, mas com uma melhor aplicação do que aqueles RDBMs construído na década de oitenta)
Matt W
0
Embora seja apenas um mecanismo incorporado e não um servidor, o leveldb tem WriteBatch e a capacidade de ativar gravações síncronas para fornecer comportamento 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)
Eu acho que o ponteiro para o teorema da PAC é muito relevante para esta questão!
Mxro
2
Alguns bancos de dados NoSQL têm transações ACID.
Eric Bloch
1
Alguns afirmam NoSQL para ser compatível com ACID mas quando u drill down dentro de você descobrir que apenas em alguns casos particulares que eles estão ACID tão IMHO como não existe 'eventualmente, ACID' eles definitivamente não são ACID
Ste
1
Você está fundamentalmente aplicando mal o CAP. CAP e ACID são vagamente relacionados, na melhor das hipóteses, mas o CAP não impede que um sistema distribuído seja compatível com ACID. O CAP descreve trocas necessárias de um sistema distribuído - um sistema NoSQL que seja fortemente consistente pode estar indisponível durante uma partição, mas isso não impede que seja compatível com ACID.
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:
fonte
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 :
e também:
e
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.
fonte
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.
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 .
fonte
O FoundationDB é compatível com ACID:
http://www.foundationdb.com/
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.
fonte
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
fonte
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.
fonte
"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.
fonte
Sim, o MarkLogic Server é uma solução NoSQL (banco de dados de documentos que gosto de chamar) que funciona com transações ACID
fonte
O avô do NoSQL: ZODB é compatível com ACID. http://www.zodb.org/
No entanto, é apenas Python.
fonte
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.
fonte
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).
fonte
NewSQL
Este conceito que os colaboradores da Wikipedia definem como:
Referências
[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.netfonte
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
fonte
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.
fonte
dê uma olhada no teorema da PAC
EDIT: RavenDB parece ser compatível com ACID
fonte
Para adicionar à lista de alternativas, outro banco de dados NoSQL totalmente compatível com ACID é GT.M .
fonte
Hyperdex Warp http://hyperdex.org/warp/ Warp (recurso ACID) é proprietário, mas o Hyperdex é gratuito.
fonte
db4o
http://www.db4o.com/about/productinformation/db4o/
fonte
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
fonte
O MarkLogic também é compatível com ACID. Eu acho que é um dos maiores jogadores agora.
fonte
A espera acabou.
Lançado o NoSQL DB compatível com ACID ----------- dê uma olhada no citrusleaf
fonte
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.
fonte
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.
fonte
O YugaByte DB suporta txns distribuídos compatíveis com ACID , bem como compatibilidade com API Redis e CQL na camada de consulta.
fonte
O VoltDB é um participante que reivindica conformidade com ACID e, embora ainda use SQL, seus objetivos são os mesmos em termos de escalabilidade
fonte
Embora seja apenas um mecanismo incorporado e não um servidor, o leveldb tem WriteBatch e a capacidade de ativar gravações síncronas para fornecer comportamento ACID.
fonte
O nó levelUP é transacional e desenvolvido no leveldb https://github.com/rvagg/node-levelup#batch
fonte
O Google Cloud Datastore é um banco de dados NoSQL que suporta transações ACID
fonte
O DynamoDB é um banco de dados NoSQL e possui transações ACID .
fonte
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
fonte