ACID

ACID(원자성, 일관성, 독립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다.
짐 그레이는 1970년대 말에 신뢰할 수 있는 트랜잭션 시스템의 이러한 특성들을 정의하였으며 자동으로 이들을 수행하는 기술을 개발해 냈다.Gray, Jim, and Reuter, Andreas, Distributed Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993. .

1983년 안드레아스 로이테르(Andreas Reuter)와 테오 해르데르(Theo Härder)는 ACID라는 용어를 만들면서 이를 기술했다. These four properties, atomicity, consistency, isolation, and durability (ACID), describe the major highlights of the transaction paradigm, which has influenced many aspects of development in database systems.

데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 한다. 예를 들어, 은행에서의 계좌이체를 트랜잭션이라고 할 수 있는데, 계좌이체 자체의 구현은 내부적으로 여러 단계로 이루어질 수 있지만 전체적으로는 '송신자 계좌의 금액 감소'와 '수신자 계좌의 금액 증가'가 한 동작으로 이루어져야 하는 것을 의미한다.

 원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장한다는 것을 의미한다. 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.
 일관성(Consistency)은 트랜잭션 처리 전과 처리 후 데이터 모순이 없는 상태를 유지하는 것을 의미한다. 예를 들어, 무결성 제약 때문에 모든 은행 계좌에 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단되어야 한다.
 독립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 예를 들어, 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 계좌이체가 일어나는 도중의 송신자 계좌와 수신자 계좌의 금액들의 중간 값들을 볼 수 없어야 한다. 공식적으로 독립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다.
 지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다. 예를 들어, 시스템 문제로 DB 일관성 체크를 하더라도 이미 수행된 트랜잭션은 유지되어야 한다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.

 구현 

ACID속성을 구현하는 건 간단한 문제가 아니다. 트랜잭션 처리는 인덱스 업데이트를 비롯한 수많은 변화가 필요하다.

연산 순서는 실패의 원인이 되기도 한다. 예를 들면 공간부족이나 CPU 자원 점유문제가 있다.

ACID는 DB의 모든 연산이 한번에 실행되는 것을 권장한다. 사실상 이것은 정렬하기 어려운 문제이다. 널리 사용하는 두 가지 방법이 있는데 로깅방식과 새도우 패이징이다. 두경우 모두 업데이트되는 데이터(구현방식에 따라 읽혀지는 데이터)에 락(lock)을 거는 것이 필요하다. 로깅방식에서 원자성은 DB에 데이터를 업데이트 하기 전에 로그에 모든 변경사항을 기록하는 것으로 보장된다. 이것은 충돌 현상이 발생하더라도 DB 무결성을 보장해준다. 새도 패이징 방식은 변경이 DB의 복사본에 저장된다. 그리고 새로운 복사본은 트랜잭션이 commit 되면 활성화 된다. 복사본은 변경 전 데이터 부분만을 의미한다.

최근까지 DB들은 대부분 ACID를 보장하기 위해 락(lock)에 의존했다. 이것은 데이터 처리전에 언제나 락이 필요함을 의미한다. 많은 수의 락을 관리하게 되면 동시작업 수행이 어렵고 성능저하를 초래하게 된다. A유저가 특정 테이블을 읽고 있다면 B유저는 A의 트랜잭션이 끝나기를 기다려야 한다.

락의 대안으로 수정되는 모든 데이터를 별도 복사본으로 관리하는 MVCC(다중 버전 동시성 제어)가 있다. 방금 전 언급한 A,B 유저의 예를 들면 A가 트랜잭션을 시작할 때 가지고 있던 복사본을 B에 제공하여 동시에 수행이 가능하다. 이 방식은 사용자들이 데이터 처리하는 데 있어 많은 유연성을 제공한다.

네트워크 환경에서 ACID특성을 보장하는 것은 어렵다. 연결이 끊길 수도 있고 두 사용자가 동시에 DB의 동일한 부분을 접근할 수도 있다

트랜잭션의 commit 여부를 각 사용자로부터 확인하기 위해 2단계 commit이 분산 트랜잭션에 적용된다. 트랜잭션이 병렬 수행되는 경우 많은 주의가 필요하다. 2단계 락은 완전한 독립성을 보장하기 위해 사용된다.

 같이 보기 
 궁극적 일관성
 CAP 정리
 동시성 제어
 개방형 시스템 간 상호 접속
 2단계 커밋 프로토콜
 CRUD
 참조 

분류:데이터베이스 관리 시스템
분류:트랜잭션 처리