2
실제로 산을 준수하는 FoundationDB가있었습니다. 이제 애플은 그것을 잡았다
—
모자가없는 사용자
답변:
- 나는 대화를 지원하기 위해 순수하게 대답으로이 게재됩니다 팀 Mahy을 , nawroth 및 CraigTP이 가능한 데이터베이스를 제안했다. Erlang 사용으로 인해 CouchDB 가 선호 되지만 다른 곳도 있습니다.
ACID 가 NoSQL 의 개념을 모순하거나 부정하지 않는다고 말하고 싶습니다 ... dove가 표현한 의견에 따라 추세가있는 것처럼 보이지만 개념은 분명합니다.
NoSQL 은 기본적으로 단순 RDBMS의 명시 적 스키마에 대한 직접적인 대안으로서 간단한 키-값 (예 : Redis) 또는 문서 스타일 스키마 (예 : "문서"모델에서 수집 된 키-값 쌍 (예 : MongoDB))에 관한 것입니다. 기존 엔진은 데이터 모델 전체에서 엄격한 동일성 을 유지 하면서 개발자는 사물을 비대칭 적 으로 처리 할 수 있습니다 . 이것이 흥미로운 이유는 변경을 처리하는 다른 방법을 제공 하기 때문이며 더 큰 데이터 세트의 경우 볼륨과 성능을 처리 할 흥미로운 기회를 제공하기 때문입니다.
ACID 는 변경 사항이 데이터베이스에 적용되는 방식을 관리하는 원칙을 제공합니다. 매우 단순화 된 방식으로 (내 자신의 버전)은 다음과 같습니다.
대화는 전파와 제약 에 대한 생각에서 조금 더 흥분됩니다 . 일부 RDBMS 엔진은 전파 요소 (la cascade )를 가질 수있는 제한 조건 (예 : 외래 키)을 적용하는 기능을 제공합니다 . 간단히 말해서, 하나의 "thing"은 데이터베이스의 다른 "thing"과 관계가있을 수 있으며 하나의 속성을 변경하는 경우 다른 속성을 변경 (업데이트, 삭제, ... 많은 옵션)해야 할 수도 있습니다. 많은 양의 데이터와 많은 트래픽에 주로 초점을 둔 NoSQL 데이터베이스는 (소비자 관점에서) 임의의 시간 범위 내에서 발생하는 분산 업데이트에 대한 아이디어를 다루는 것 같습니다. 이것은 기본적으로 다음을 통해 관리되는 특수한 형태의 복제입니다.트랜잭션 -따라서 기존 분산 데이터베이스가 ACID를 지원할 수 있으면 NoSQL 데이터베이스도 지원됩니다.
추가로 읽을 수있는 자료 :
업데이트 (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"사고 방식을 유지하는 데 가장 근접한 것으로 보입니다 .
확인하십시오 당신이되는 NoSQL 데이터베이스에 대한 마틴 파울러 소개를 읽어 . 그리고 해당 비디오.
우선 두 가지 유형의 NoSQL 데이터베이스를 구분할 수 있습니다.
설계 상 대부분의 그래프 중심 데이터베이스는 ACID입니다 !
그렇다면 다른 유형은 어떻습니까?
집계 지향 데이터베이스에는 세 가지 하위 유형을 넣을 수 있습니다.
여기서 우리는 집합체 라고 부르며, Eric Evans는 도메인 기반 설계 에서 주어진 경계 컨텍스트에서 엔티티 및 가치 객체의 자급 자족으로 정의한 것입니다 .
결과적으로 집합은 우리가 단위로 상호 작용하는 데이터의 모음입니다. 집계는 데이터베이스와 ACID 작업의 경계를 형성합니다. (마틴 파울러)
따라서 집계 수준에서 대부분의 NoSQL 데이터베이스는 적절한 설정 으로 ACID RDBMS만큼 안전 할 수 있습니다 . 소스 중에서 가장 빠른 속도로 서버를 조정하면 ACID가 아닌 것으로 나타날 수 있습니다. 그러나 복제가 도움이 될 것입니다.
나의 주요 요점은 NoDB 데이터베이스를 RDBMS에 대한 (싼) 대안이 아닌 그대로 사용해야한다는 것입니다. 문서 간 관계를 남용하는 프로젝트가 너무 많습니다. ACID가 될 수 없습니다. 문서 레벨, 즉 집계 경계에 머무르면 거래가 필요하지 않습니다. ACID 데이터베이스가 아닌 경우에도 트랜잭션이 필요하지 않기 때문에 데이터는 ACID 데이터베이스와 마찬가지로 안전합니다! 트랜잭션이 필요하고 한 번에 여러 "문서"를 업데이트하는 경우 더 이상 NoSQL 세계에 있지 않으므로 RDBMS 엔진을 대신 사용하십시오!
2019 년 업데이트 : 버전 4.0부터 여러 문서에 대한 업데이트 또는 여러 문서에 대한 읽기 간 일관성에 원 자성이 필요한 상황에서 MongoDB는 복제 세트에 대한 다중 문서 트랜잭션을 제공 합니다 .
FoundationDB는 ACID를 준수합니다.
적절한 트랜잭션이 있으므로 여러 개별 데이터 항목을 ACID 방식으로 업데이트 할 수 있습니다. 이는 상위 계층에서 인덱스를 유지하기위한 기초로 사용됩니다.
이 질문에서 누군가는 OrientDB 를 언급해야합니다 . OrientDB는 완전 ACID 트랜잭션을 지원하는 NoSQL 데이터베이스입니다. ACID는 관계 대수의 일부가 아니기 때문에 RDBMS 전용이 아닙니다. 따라서 ACID를 지원하는 NoSQL 데이터베이스를 보유 할 수 있습니다.
이 기능은 내가 몽고 DB에서 가장 그리워하는 기능입니다
ACID와 NoSQL은 완전히 직교합니다. 하나는 다른 것을 의미하지 않습니다.
책상에 공책이 있는데, 여전히해야 할 일에 대한 메모를하기 위해 공책을 사용합니다. 이 노트북은 NoSQL 데이터베이스입니다. "페이지 캐시"로 선형 검색을 사용하여 쿼리하므로 항상 모든 페이지를 검색 할 필요는 없습니다. 한 번에 한 가지만 쓰고 읽지 않는 동안 ACID를 준수합니다.
NoSQL은 단순히 SQL이 아님을 의미합니다. 많은 사람들이 혼란스러워서 확장 성이 뛰어나고 거친 서부 초고속 저장을 의미한다고 생각합니다. 그렇지 않습니다. 키-값 저장 또는 최종 일관성을 의미하지는 않습니다. 의미하는 것은 "SQL이 아님",이 행성에는 많은 데이터베이스가 있으며 대부분은 SQL이 아닙니다 [인용 필요] .
다른 답변에서 많은 예제를 찾을 수 있으므로 여기에 나열 할 필요는 없지만 다양한 작업에 대해 ACID를 준수하는 비 SQL 데이터베이스가 있으며 일부는 단일 객체 쓰기에 대한 ACID이지만 일부는 훨씬 더 보장합니다. 각 데이터베이스는 다릅니다.
"NoSQL"은 잘 정의 된 용어가 아닙니다. 매우 모호한 개념입니다. 따라서 "NoSQL"제품이 무엇인지 아닌지 말할 수조차 없습니다. 레이블이있는 상표가 붙은 거의 모든 제품이 키-밸류 스토어가 아닙니다.
예, MarkLogic Server는 ACID 트랜잭션과 함께 작동하는 NoSQL 솔루션 (서명하고 싶은 문서 데이터베이스)입니다
NoSQL의 할아버지 : ZODB는 ACID를 준수합니다. http://www.zodb.org/
그러나 그것은 파이썬입니다.
NoSQL의 창시자 중 한 사람으로서 (Apache CouchDB의 초기 기고자 였으며 2009 년 CBS Interactive / CNET에서 열린 첫 NoSQL 이벤트 의 연사였습니다 ) 새로운 알고리즘이 이전에는 없었던 가능성을 만들어내는 것을 보게되어 기쁩니다 . Calvin 프로토콜 은 CAP 및 PACELC 와 같은 물리적 제약 조건을 생각할 수있는 새로운 방법을 제공합니다 .
Calvin은 액티브 / 패시브 비동기 복제 또는 액티브 / 액티브 동기 복제 대신 RAFT와 유사한 프로토콜 을 사용하여 트랜잭션 로그를 유지 함으로써 복제 중단 동안 정확성과 가용성 을 유지합니다. 또한 트랜잭션은 각 복제본에서 결정적으로 처리 되어 교착 상태의 가능성을 제거하므로 한 번의 합의만으로 합의가 이루어집니다. 이를 통해 전 세계의 다중 클라우드 배포에서도 빠르게 수행 할 수 있습니다.
FaunaDB 는 Calvin 프로토콜을 사용하는 유일한 데이터베이스 구현으로 NoSQL 규모와 유연성으로 메인 프레임과 같은 데이터 무결성이 필요한 워크로드에 적합합니다.
ACID 호환 키 / 값 저장소를 찾고 있다면 Berkeley DB가 있습니다. 가운데 그래프 데이터베이스 적어도 Neo4j 및 HyperGraphDB는 ACID 트랜잭션 (HyperGraphDB 실제로 순간에 낮은 수준의 스토리지 버클리 DB를 사용)를 제공합니다.
이 개념 Wikipedia 기고자는 다음과 같이 정의합니다.
[…] 기존 데이터베이스 시스템의 ACID 보장을 유지하면서 OLTP (Online Transaction Processing) 읽기 / 쓰기 워크로드에 동일한 NoSQL 시스템 성능을 제공하고자하는 최신 관계형 데이터베이스 관리 시스템 클래스입니다.
[1][2][3]
[1]낸시 린치 (Nancy Lynch)와 세스 길버트 (Seth Gilbert), “Brewer의 추측과 일관성 있고 사용 가능한 파티션 허용 웹 서비스의 실현 가능성” , ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.
[2] "맥주 CAP 정리" , julianbrowne.com, 2010 년 3 월 2 일에 확인 함
[3] "분산 시스템의 양조자 CAP 정리" , royans.net
MongoDB는 4.0 버전이 다중 문서 트랜잭션에 대해 ACID를 준수 할 것이라고 발표했습니다.
버전 4.2. 샤드 설정에서 지원해야합니다.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB가 언급되었으며 당시에는 오픈 소스가 아니 었습니다. 이틀 전에 애플이 오픈 소스로 공개했다 : https://www.foundationdb.org/blog/foundationdb-is-open-source/
ACID를 준수한다고 생각합니다.
Hyperdex Warp http://hyperdex.org/warp/ Warp (ACID 기능)는 독점적이지만 Hyperdex는 무료입니다.
db4o
롤업 지속성 또는 직렬화와 달리 db4o는 ACID 트랜잭션에 안전하며 런타임 동안 쿼리, 복제 및 스키마 변경을 허용합니다.
Tarantool은 완전 ACID NoSQL 데이터베이스입니다. CRUD 조작 또는 스토어드 프로 시저를 발행 할 수 있으며 모든 것은 ACID 특성에 따라 엄격하게 실행됩니다. http://stable.tarantool.org/doc/mpage/data-and-persistence.html에서 이에 대해 읽을 수도 있습니다.
잠깐만
ACID 호환 NoSQL DB가 출시 되었습니다 ----------- citrusleaf 살펴보기
BergDB 는 처음부터 ACID 트랜잭션을 실행하도록 설계된 경량의 오픈 소스 NoSQL 데이터베이스입니다. 실제로 BergDB는 대부분의 SQL 데이터베이스보다 "더 많은"ACID 입니다. 데이터베이스의 상태를 변경하는 유일한 방법 은 가장 높은 격리 수준 (SQL 용어 : "직렬화 가능")으로 ACID 트랜잭션을 실행하는 것입니다. 더티 읽기, 반복 불가능한 읽기 또는 팬텀 읽기에는 아무런 문제가 없습니다.
제 생각에는 데이터베이스는 여전히 성능이 뛰어납니다. 하지만 믿지 마세요. 소프트웨어를 만들었습니다. 대신 직접 시도하십시오.
많은 최신 NoSQL 솔루션은 ACID 트랜잭션 (원자 격리 된 다중 키 업데이트)을 지원하지 않지만 대부분은 애플리케이션 수준에서 트랜잭션을 구현할 수있는 프리미티브를 지원합니다.
데이터 저장소가 키 단위 별 선형성 및 비교 및 설정 (문서 수준 원 자성)을 지원하는 경우 클라이언트 측 트랜잭션을 구현하기에 충분합니다.
Serializable 격리 수준이 필요한 경우 Google이 Percolator 시스템 또는 Cockroach Labs for CockroachDB에 사용하는 것과 동일한 알고리즘을 따를 수 있습니다 . 나는 그것에 대해 블로그하고 단계별 시각화를 만들었습니다 . 알고리즘의 주요 아이디어를 이해하는 데 도움이되기를 바랍니다.
경합이 높을 것으로 예상되지만 읽기 커밋 격리 수준을 갖는 것이 좋다면 Peter Bailis 의 RAMP 트랜잭션 을 살펴 보십시오.
세 번째 방법은 사가 패턴이라고도하는 보상 트랜잭션을 사용하는 것입니다. 그것은 80 년대 후반 Sagas 논문 에서 설명 되었지만 분산 시스템 의 등장으로 더욱 현실화 되었습니다. 영감을 얻으 려면 사가 패턴 적용 대화를 참조하십시오 .
클라이언트 측 트랜잭션에 적합한 데이터 저장소 목록에는 경량 트랜잭션이있는 Cassandra, 일관된 버킷이있는 Riak, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB 등이 포함됩니다.
YugaByte DB 는 쿼리 계층 에서 ACID 준수 분산 전송 뿐만 아니라 Redis 및 CQL API 호환성을 지원합니다.
노드 레벨 UP은 트랜잭션이며 leveldb https://github.com/rvagg/node-levelup#batch를 기반으로합니다.
DynamoDB는 NoSQL 데이터베이스이며 ACID 트랜잭션이 있습니다.
NoSQL은 설계 상 ACID를 준수하지 않습니다. NoSQL 운동은 ACID와 반대되는 BASE (기본적으로 사용 가능, 소프트 상태, 최종 일관성)를 수용합니다. NoSQL 데이터베이스는 종종 Event-Consisted 데이터베이스라고합니다. 차이점을 이해하려면 CAP 정리 (일명 Brewer 's 정리)로 드릴 다운해야합니다.
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 방문