ACID와 호환되는 NoSQL 데이터 저장소가 있습니까?
어떤 거기 되는 NoSQL 인 데이터 저장소 ACID의 준수는?
- 나는 대화를 지원하기 위해 순수하게 대답으로이 게재됩니다 팀 Mahy을 , nawroth 및 CraigTP이 가능한 데이터베이스를 제안했다. Erlang 사용으로 인해 CouchDB 가 선호 되지만 다른 곳도 있습니다.
ACID 가 NoSQL 의 개념을 모순하거나 부정하지 않는다고 말하고 싶습니다 ... dove가 표현한 의견에 따라 추세가있는 것처럼 보이지만 개념은 서로 다릅니다.
NoSQL 은 기본적으로 단순 RDBMS의 명시 적 스키마에 대한 직접적인 대안으로서 간단한 키-값 (예 : Redis) 또는 문서 스타일 스키마 (예 : "문서"모델에서 수집 된 키-값 쌍 (예 : MongoDB))에 관한 것입니다. 전통적인 엔진은 데이터 모델 전체에서 엄격한 동일성 을 유지 하면서 개발자는 사물을 비대칭 적 으로 처리 할 수 있습니다 . 이것이 흥미로운 이유는 변경을 처리하는 다른 방법을 제공 하기 때문이며 , 더 큰 데이터 세트의 경우 볼륨과 성능을 처리 할 흥미로운 기회를 제공하기 때문입니다.
ACID 는 변경 사항이 데이터베이스에 적용되는 방식을 관리하는 원칙을 제공합니다. 매우 단순화 된 방식으로 (내 자신의 버전)은 다음과 같습니다.
- (A) 데이터베이스를 변경하기 위해 무언가를 할 때 변경이 작동하거나 전체적으로 실패해야합니다.
- (C) 데이터베이스는 일관성을 유지해야한다 (이것은 꽤 광범위한 주제이다)
- (I) 다른 일이 동시에 진행되고 있다면 업데이트 도중에 일을 볼 수 없어야합니다.
- (D) 시스템이 고장 나면 (하드웨어 또는 소프트웨어) 데이터베이스가 자체적으로 백업 될 수 있어야합니다. 업데이트 적용이 완료되었다고 확신하면
대화는 전파와 제약 에 대한 생각에서 조금 더 흥분됩니다 . 일부 RDBMS 엔진은 전파 요소 (la cascade )를 가질 수있는 제한 조건 (예 : 외래 키)을 적용하는 기능을 제공합니다 . 간단히 말해서, 하나의 "thing"은 데이터베이스의 다른 "thing"과 관계가있을 수 있으며 하나의 속성을 변경하는 경우 다른 속성을 변경 (업데이트, 삭제, ... 많은 옵션)해야 할 수도 있습니다. 많은 양의 데이터와 많은 트래픽에 주로 초점을 둔 NoSQL 데이터베이스는 (소비자 관점에서) 임의의 시간 범위 내에서 발생하는 분산 업데이트에 대한 아이디어를 다루는 것 같습니다. 이것은 기본적으로 다음을 통해 관리되는 특수한 형태의 복제입니다.트랜잭션 -따라서 기존 분산 데이터베이스가 ACID를 지원할 수 있으면 NoSQL 데이터베이스도 지원됩니다.
추가로 읽을 수있는 자료 :
- ACID에 관한 Wikipedia 기사
- 전파 제한에 관한 Wikipedia
- 데이터베이스 정규화에 대한 Wikipedia (예, 사이트가 마음에 듭니다, 괜찮습니까?)
- ACID를 적용하는 방법에 대한 좋은 개요가있는 CouchDB의 Apache 문서
- 클러스터 컴퓨팅 에 관한 위키 백과
- 데이터베이스 트랜잭션에 대한 Wikipedia (다시 ...)
업데이트 (2012 년 7 월 27 일) : 이 답변이 게시 될 때 최신 기사 버전을 반영하도록 Wikipedia 기사 링크가 업데이트되었습니다. 있습니다 현재 위키 백과 문서가 광범위하게 개정되었습니다!
NoSQL 에 대한 Wikipedia 기사 의 이전 버전에 따르면 :
NoSQL은 관계형 데이터베이스와 ACID 보증의 오랜 역사를 깨는 느슨하게 정의 된 비 관계형 데이터 저장소 클래스를 홍보하는 운동입니다.
그리고 또한:
이 이름은 종종 ACID 보증을 제공하지 않는 비 관계형 분산 데이터 저장소가 점점 늘어나고 있음을 설명하려는 시도였습니다.
과
NoSQL 시스템은 보조 미들웨어 계층을 추가하여 완전한 ACID 보증을 부과 할 수 있지만 최종 일관성 및 단일 데이터 항목으로 제한되는 트랜잭션과 같은 약한 일관성 보장을 제공합니다.
간단히 말해서, "NoSQL"데이터 저장소의 주요 이점 중 하나 는 ACID 속성 이 뚜렷 하지 않다는 것 입니다 . 또한 IMHO는 ACID 속성 을 구현하고 시행하려고할수록 "NoSQL"데이터 저장소의 "정신"에서 멀어지고 "진정한" RDBMS에 가까워집니다 (물론 상대적으로 말하면 ).
그러나 "NoSQL"이라는 말은 매우 모호한 용어이며 개별 해석에 개방적이며 얼마나 순수한 견해를 가지고 있는지에 크게 좌우됩니다. 예를 들어, 대부분의 현대는 시스템이 실제로 준수하지 않는 RDBMS 모두 의 에드거 F. 커드 의 12 개 규칙을 자신의 관계 모델 !
실용적인 접근 방식을 취하면 Apache의 CouchDB 는 ACID 준수를 구현하는 동시에 가장 느슨하게 결합 된 비 관계형 "NoSQL"사고 방식을 유지하는 것으로 보입니다 .
FoundationDB는 ACID를 준수합니다.
적절한 트랜잭션이 있으므로 여러 개별 데이터 항목을 ACID 방식으로 업데이트 할 수 있습니다. 이는 상위 계층에서 인덱스를 유지하기위한 기초로 사용됩니다.
이 질문에서 누군가는 OrientDB 를 언급해야합니다 . OrientDB는 완전 ACID 트랜잭션을 지원하는 NoSQL 데이터베이스입니다. ACID는 관계 대수의 일부가 아니기 때문에 RDBMS 전용이 아닙니다. 따라서 ACID를 지원하는 NoSQL 데이터베이스를 보유 할 수 있습니다.
이 기능은 내가 몽고 DB에서 가장 그리워하는 기능입니다
확인하십시오 당신이되는 NoSQL 데이터베이스에 대한 마틴 파울러 소개를 읽어 . 그리고 해당 비디오.
우선 두 가지 유형의 NoSQL 데이터베이스를 구분할 수 있습니다.
- 집계 지향 데이터베이스;
- 그래프 지향 데이터베이스 (예 : Neo4J)
설계 상 대부분의 그래프 중심 데이터베이스는 ACID입니다 !
그렇다면 다른 유형은 어떻습니까?
집계 지향 데이터베이스에는 세 가지 하위 유형을 넣을 수 있습니다.
- 문서 기반 NoSQL 데이터베이스 (예 : MongoDB, CouchDB);
- 키 / 값 NoSQL 데이터베이스 (예 : Redis);
- 열 계열 NoSQL 데이터베이스 (예 : Hibase, Cassandra).
여기서 우리는 집합체 라고 부르며, Eric Evans는 도메인 기반 디자인 에서 주어진 경계 컨텍스트에서 엔티티와 가치 객체의 자급 자족으로 정의한 것입니다 .
결과적으로 집합은 우리가 단위로 상호 작용하는 데이터의 모음입니다. 집계는 데이터베이스와 ACID 작업의 경계를 형성합니다. (마틴 파울러)
So, at Aggregate level, we can say that most NoSQL databases can be as safe as ACID RDBMS, with the proper settings. Of source, if you tune your server for the best speed, you may come into something non ACID. But replication will help.
My main point is that you have to use NoSQL databases as they are, not as a (cheap) alternative to RDBMS. I have seen too much projects abusing of relations between documents. This can't be ACID. If you stay at document level, i.e. at Aggregate boundaries, you do not need any transaction. And your data will be as safe as with an ACID database, even if it not truly ACID, since you do not need those transactions! If you need transactions and update several "documents" at once, you are not in the NoSQL world any more - so use a RDBMS engine instead!
some 2019 update: Starting in version 4.0, for situations that require atomicity for updates to multiple documents or consistency between reads to multiple documents, MongoDB provides multi-document transactions for replica sets.
ACID and NoSQL are completely orthogonal. One does not imply the other.
I have a notebook on my desk, I use it to keep notes on things that I still have to do. This notebook is a NoSQL database. I query it using a linear search with a "page cache" so I don't always have to search every page. It is also ACID compliant as I ensure that I only write one thing at a time and never while I am reading it.
NoSQL simply means that it isn't SQL. Many people get confused and think it means highly-scaleable-wild-west-super-fast-storage. It doesn't. It doesn't mean key-value store, or eventual consistency. All it means is "not SQL", there are a lot of databases in this planet and most of them are not SQL[citation needed].
You can find many examples in the other answers so I need not list them here, but there are non-SQL databases with ACID compliance for various operations, some are only ACID for single object writes while some guarantee far more. Each database is different.
"NoSQL" is not a well-defined term. It's a very vague concept. As such, it's not even possible to say what is and what is not a "NoSQL" product. Not nearly all of the products typcially branded with the label are key-value stores.
Yes, MarkLogic Server is a NoSQL solution (document database I like to call it) that works with ACID transactions
If you are looking for an ACID compliant key/value store, there's Berkeley DB. Among graph databases at least Neo4j and HyperGraphDB offer ACID transactions (HyperGraphDB actually uses Berkeley DB for low-level storage at the moment).
The grandfather of NoSQL: ZODB is ACID compliant. http://www.zodb.org/
However, it's Python only.
As one of the originators of NoSQL (I was an early contributor to Apache CouchDB, and a speaker at the first NoSQL event held at CBS Interactive / CNET in 2009) I'm excited to see new algorithms create possibilities that didn't exist before. The Calvin protocol offers a new way to think of physical constraints like CAP and PACELC.
Instead of active/passive async replication, or active/active synchronous replication, Calvin preserves correctness and availability during replica outages by using a RAFT-like protocol to maintain a transaction log. Additionally, transactions are processed deterministically at each replica, removing the potential for deadlocks, so agreement is achieved with only a single round of consensus. This makes it fast even on multi-cloud worldwide deployments.
FaunaDB is the only database implementation using the Calvin protocol, making it uniquely suited for workloads that require mainframe-like data integrity with NoSQL scale and flexibility.
NewSQL
This concept Wikipedia contributors define as:
[…] a class of modern relational database management systems that seek to provide the same scalable performance of NoSQL systems for online transaction processing (OLTP) read-write workloads while still maintaining the ACID guarantees of a traditional database system.
[1][2][3]
References
[1] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.
[2] "Brewer's CAP Theorem", julianbrowne.com, Retrieved 02-Mar-2010
[3] "Brewers CAP theorem on distributed systems", royans.net
MongoDB announced that its 4.0 version will be ACID compliant for multi-document transactions.
Version 4.2. is supposed to support it under sharded setups.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB was mentioned and at the time it wasn't open source. It's been open sourced by Apple two days ago: https://www.foundationdb.org/blog/foundationdb-is-open-source/
I believe it is ACID compliant.
take a look at the CAP theorem
EDIT: RavenDB seems to be ACID compliant
To add to the list of alternatives, another fully ACID compliant NoSQL database is GT.M.
Hyperdex Warp http://hyperdex.org/warp/ Warp (ACID feature) is proprietary, but Hyperdex is free.
db4o
Unlike roll-your-own persistence or serialization, db4o is ACID transaction safe and allows for querying, replication and schema changes during runtime
http://www.db4o.com/about/productinformation/db4o/
Tarantool is a fully ACID NoSQL database. You can issue CRUD operations or stored procedures, everything will be run with strict accordance with an ACID property. You can also read about that here: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic is also ACID complient. I think is one of the biggest players now.
Wait is over.
ACID compliant NoSQL DB is out ----------- have a look at citrusleaf
BergDB is a light-weight, open-source, NoSQL database designed from the start to run ACID transactions. Actually, BergDB is "more" ACID than most SQL databases in the sense that the only way to change the state of the database is to run ACID transactions with the highest isolation level (SQL term: "serializable"). There will never be any issues with dirty reads, non-repeatable reads, or phantom reads.
In my opinion, the database is still highly performant; but don't trust me, I created the software. Try it yourself instead.
A lot of modern NoSQL solution don't support ACID transactions (atomic isolated multi-key updates), but most of them support primitives which allow you to implement transactions on the application level.
If a data store supports per key linearizability and compare-and-set (document level atomicity) then it's enough to implement client-side transactions, more over you have several options to choose from:
If you need Serializable isolation level then you can follow the same algorithm which Google use for the Percolator system or Cockroach Labs for CockroachDB. I've blogged about it and create a step-by-step visualization, I hope it will help you to understand the main idea behind the algorithm.
If you expect high contention but it's fine for you to have Read Committed isolation level then please take a look on the RAMP transactions by Peter Bailis.
The third approach is to use compensating transactions also known as the saga pattern. It was described in the late 80s in the Sagas paper but became more actual with the raise of distributed systems. Please see the Applying the Saga Pattern talk for inspiration.
The list of data stores suitable for client side transactions includes Cassandra with lightweight transactions, Riak with consistent buckets, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB and others.
YugaByte DB supports an ACID Compliant distributed txns as well as Redis and CQL API compatibility on the query layer.
VoltDB is an entrant which claims ACID compliance, and while it still uses SQL, its goals are the same in terms of scalability
Whilst it's only an embedded engine and not a server, leveldb has WriteBatch and the ability to turn on Synchronous writes to provide ACID behaviour.
Node levelUP is transactional and built on leveldb https://github.com/rvagg/node-levelup#batch
Google Cloud Datastore is a NoSQL database that supports ACID transactions
DynamoDB is a NoSQL database and has ACID transactions.
Not only NoSQL is not ACID compliant by design. NoSQL movement embrace the BASE (Basically Available, Soft state, Eventual consistency) claimed to be the opposite of ACID. NoSQL database are often called Eventually-Consisted database. To understand the differences you should drill down into the CAP theorem (aka Brewer's theorem)
Visit http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
참고URL : https://stackoverflow.com/questions/2608103/is-there-any-nosql-data-store-that-is-acid-compliant
'IT박스' 카테고리의 다른 글
| 부모 POM에 정의 된 Maven 플러그인 비활성화 (0) | 2020.06.18 |
|---|---|
| Executors.newCachedThreadPool () 및 Executors.newFixedThreadPool () (0) | 2020.06.18 |
| 소프트 키보드가 나타날 때 레이아웃을 조정하는 방법 (0) | 2020.06.18 |
| 장고 자기 참조 외래 키 (0) | 2020.06.18 |
| 여러 조건이있는 Bash if 문에서 오류가 발생 함 (0) | 2020.06.18 |