[DB] 기초부터다시, ACID, CAP

ACID

트랜잭션은 이러한 성질을 만족해야 안전하게 수행됬다고 볼수 있다는 특징들의 약자

 

A : Atomicity, 원자성, 트랜잭션 내에 작업은 모든 상태가 반영되거나, 모든 상태가 되지 않아야 한다.

C : Consistency, 일관성, PK 규정이라거나, 타입 상태의 규정, 및 규정들은 언제나 일관성있도록 깨지지 않아야한다.

I : Isolation, 독립성, 트랜잭션 수행내용은 다른 트랜잭션이 끼어들지 못하도록 해야한다

               (성능상에 이유로 유연성 있는 제약조건이라고 함, 커밋되지 않은 항목에 대한 읽기 라거나 여러 조건들이..)

               (DB는 보통 낙관적으로 커밋될것이라 처리하기 때문에 일단 반영하고 트랜잭션 밖에서 select 요청이 들어오면 redo로그..? 를 통해 해당 트랜잭션 버전에 맞게 변경 후 보여준다고 한것 같은데.. 이러한 성능 저하를 겪지 않으려는 목적인듯함.. 내용이 틀리다면 피드백 부탁드립니다.)

D : Durability, 지속성, 트랜잭션이 성공하면 해당 내용은 언제나 반영되어있어야 한다, 커밋 후 장애가 발생하더라도 로그를 통해서라도 복구가 가능해야 한다.

 

CAP

어떤한 분산 시스템도 CAP(Consistency, Availability, Partition tolerrance) 3가지를 동시에 만족시킬수 없다는 이론

 

C(Consistency, 일관성) : 모든 서버들은 같은 시간에 같은 내용의 데이터를 보여주는것을 보장해야 한다.

A(Availability, 가용성) : 언제나 모든 사용자들이 읽기 및 쓰기가 가능해야 하며, 다른 서버의 장애시에 영향을 받아서는 안된다.

P(Partition tolerrance, 분할내성) : 시스템 일부가 장애에 빠져도 시스템을 서비스 할 수 있어야 한다.

 

출처 :  rndblog.github.io/nosql/architecture/2015/09/13/notes-on-nosql-basics.html

전통적인 RDB는 C와 A를 만족하여 트랜잭션을 통해 데이터 일관성과 단일 서버를 통한 가용성을 제공하낟.

 

또한 NoSQL의 경우 C와 P를 만족하기 위하여, 분산 환경을 제공하고, 분산환경에서 일관성을 제공하기 위해 분산 서버간의 sync 작업이 진행되며, 일관성을 맞추는 sync작업이 진행되는동안 클라이언트가 read/write가 불가능 할수 있기 때문에 A가 포기된다..

 

AP를 선택한 CouchDB, Cassandra의 경우 C를 만족하지 않기 때문에 여러 클라이언트가 일관성 없는 데이터를 바라볼수 있지만, 언제나 읽고 쓸수 있도록 A 를 제공하고 분산 환경인 P를 제공하기 때문에

데이터 일관성이 꼭 중요하지 않는 경우에 선택된다.