3.1 ACID의 출현
약어 ACID는 1983년 Theo Haerder와 Andreas Reuter의 기사에서 처음 등장했습니다. 텍스트를 단순화하고 더 설득력 있게 만들기 위해 이 기사의 일부를 번역하여 제공합니다(약간 줄임). 이 스니펫은 돈이 한 계좌에서 다른 계좌로 이체되는 은행 거래의 예를 사용합니다.
$BEGIN_TRANSACTION예제에서 및 사이의 데이터베이스와의 모든 상호 작용을 포함하는 트랜잭션의 개념은 $COMMIT_TRANSACTION모든 작업이 불가분하게 수행되어야 합니다. 즉, 모든 작업이 데이터베이스 상태에 적절하게 반영되거나 아무 일도 일어나지 않습니다. 사용자에게 도달하기 전 어느 시점에 가 포함된 $COMMIT_TRANSACTION명령문을 입력하면 변경 사항이 데이터베이스에 반영되지 않습니다.ERROR$RESTORE_TRANSACTION
이러한 불가분성을 달성하려면 트랜잭션에 다음 네 가지 속성이 있어야 합니다.
원자성 (원자성). 트랜잭션은 위에서 설명한 all-or-nothing 유형이어야 하며 어떤 일이 발생하더라도 사용자는 트랜잭션이 어떤 상태에 있는지 알아야 합니다.
일관성 (일관성). 정상적인 트랜잭션 종료(EOT)에 도달하여 결과를 커밋하는 트랜잭션은 데이터베이스 일관성을 유지합니다. 즉, 모든 성공적인 트랜잭션은 정의에 따라 유효한 결과만 커밋합니다. 이 조건은 네 번째 속성인 내구성을 지원하는 데 필요합니다.
격리 (격리). 트랜잭션 내에서 발생하는 이벤트는 동시에 실행되는 다른 트랜잭션에서 숨겨야 합니다. 이 조건이 충족되지 않으면 위에서 언급한 이유로 트랜잭션을 처음으로 되돌릴 수 없습니다. 격리를 달성하기 위해 동기화라는 방법이 사용됩니다 ...
내구성 (내구성). 트랜잭션이 완료되고 그 결과를 데이터베이스에 커밋하면 시스템은 이러한 결과가 이후의 실패에도 지속되도록 해야 합니다. 트랜잭션 집합을 포괄하는 제어 범위가 없기 때문에 데이터베이스 관리 시스템(DBMS)은 트랜잭션의 경계를 넘어 제어할 수 없습니다.
따라서 사용자는 시스템이 그에게 어떤 일이 일어났다고 알려주면 이 "무언가"가 실제로 일어난 것임을 보장해야 합니다. 정의상 모든 (성공적으로 완료된 - S.K.) 트랜잭션은 정확하므로 필연적으로 나타나는 잘못된 트랜잭션(즉, 잘못된 데이터를 포함하는 트랜잭션)의 결과는 해당 "카운터" 트랜잭션(countertransaction)에 의해서만 제거될 수 있습니다.
3.2 거래의 출현
ACID(Atomicity, Consistency, Isolation, and Durability)의 네 가지 속성은 데이터베이스 시스템 설계의 여러 측면에 영향을 미치는 트랜잭션 패러다임의 핵심 기능을 설명합니다. 따라서 거래를 지원하는 시스템의 능력이 이 시스템 품질의 시금석(ACID 테스트)이라고 믿습니다.
한 계정에서 다른 계정으로 자금을 이체하는 간단한 PL/1-SQL 프로그램입니다.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */실제로 ACID 속성은 한편으로는 트랜잭션을 지원한다고 주장하는 모든 DBMS의 요구 사항으로 간주될 수 있고 다른 한편으로는 데이터베이스 시스템 . 이 정의는 세속적 관행과 완전히 일치합니다. 예를 들어 은행 거래를 수행하는 고객(실시간 창구 직원의 도움을 받든 인터넷 뱅킹을 사용하든)이 은행이 ACID의 모든 속성을 충족할 것이라고 기대하지 않는다는 것은 상상하기 어렵습니다. 거래에 대해 ACID 속성을 지원하지 않는 은행은 기껏해야 고객을 잃고 최악의 경우 파산합니다.
3.3 ACID 연결
ACID 속성은 분리할 수 없다는 것이 매우 중요하며, 그 중 하나를 버리면 나머지 조합이 무의미해집니다. 특히 일관성 속성을 버리면(위 인용문에서 사용된 의미에서) 트랜잭션의 정확성에 대한 기준을 잃게 됩니다. 데이터베이스 시스템은 트랜잭션이 커밋되는지 여부를 의미 있는 방식으로 결정할 수 없으며 데이터베이스의 현재 상태에서 수행되는 작업의 정확성에 대한 모든 검사는 애플리케이션 코드에서 수행되어야 합니다.
이 경우 논리적 일관성에 대해 이야기하고 있음을 이해해야 합니다. 은행의 고객은 자신이 설정하고 고객에게 알려진 규칙에 따라 은행이 작동해야 하므로 이러한 규칙을 위반하는 거래를 수행하는 것이 불가능하므로 동일한 고객의 다음 거래가 한 번에 실행됩니다. 이 규칙에 따라 합의된 환경.
온라인 상점의 고객은 자신이 주문하고 지불한 상품이 적시에 고객에게 전달되어야 합니다(고객이 설정하고 알고 있는 규칙에 따라). 그렇지 않으면 그는 이 상점을 신뢰하지 않을 것입니다. 동시에 은행 고객이나 인터넷 상점 고객은 기업의 내부 부엌, 거래를 완료하기 위해 어떤 내부 조치를 취하는 지 신경 쓰지 않습니다. 클라이언트는 이 엔터프라이즈의 물리적 일관성이 유지되는 방식, 물리적 계층에서 작업이 수행되는 방식에 관심이 없습니다.
DBMS가 트랜잭션(및 데이터베이스)의 논리적 일관성을 유지 관리하면 응용 프로그램이 더 단순해지고 이해하기 쉬우며 신뢰할 수 있게 됩니다. 거래 및 데이터의 유효한 상태에 관한 응용 영역(은행, 상점, 창고 등)의 모든 논리는 데이터베이스 시스템으로 들어갑니다. 그리고 이 시스템에 대한 요구 사항은 매우 간단합니다. 애플리케이션이 데이터베이스에 제공하는 일관성 규칙을 고려하여 ACID 트랜잭션을 지원합니다. 내 관점에서 볼 때 ACID 트랜잭션의 거부는 고객의 자연스러운 요구를 충족시키기 위해 자신이 비슷한 것을 구현해야 하는 애플리케이션 개발자에게 과도한 어려움을 야기합니다.
그리고 다시 한 번 ACID 속성이 실제로 트랜잭션의 개념을 정의한다는 점에 주목합니다. 제 생각에는 트랜잭션 일관성 속성이 지원되지 않는 트랜잭션 데이터 관리 시스템에 대해 이야기할 가능성을 조금이라도 갖기 위해서는 이 경우 트랜잭션이라는 용어가 의미하는 바를 정의하는 것이 절대적으로 필요합니다.
불행하게도 오늘날 많은 경우(특히 이것은 NoSQL 방향의 특징입니다) 사람들은 어떤 종류의 트랜잭션을 의미하는지 전혀 지정하지 않고 OLTP 애플리케이션 지원에 대해 이야기합니다. 따라서 이 글에서는 실제 트랜잭션을 지칭하기 위해 조합 ACID 트랜잭션을 사용하고 비정규 용어 트랜잭션은 다른 맥락에서 다른 비공식적 의미로 사용됩니다.
이제 CAP의 "정리"를 다루고 Brewer의 의미에서 일관성이 무엇을 의미하는지 알아내도록 합시다.