ACID 속성

일관성이 나머지 셋과 성격이 다릅니다. 원자성, 격리성, 지속성은 DB 가 보장하는 기능이지만 일관성은 그 결과이자 애플리케이션과의 약속입니다. 잔액이 음수면 안 된다는 규칙은 DB 가 스스로 알지 못하고 제약이나 코드로 표현해야 합니다.

흔한 실수: 일관성을 "데이터가 항상 최신"으로 설명하는 것. 그것은 분산 시스템의 일관성이고 여기서는 정의된 규칙을 위반하지 않는다는 뜻입니다.

변경 전 값을 따로 기록해 두었다가 실패 시 되돌립니다.

이 구조는 롤백만이 아니라 다른 트랜잭션의 읽기에도 쓰입니다. 아직 커밋되지 않은 변경을 다른 트랜잭션이 보면 안 되므로, 언두 로그에 있는 옛 값을 보여줍니다. 이것이 MVCC 의 기반입니다.

장애로 서버가 죽었을 때도 같은 원리로 복구합니다. 재시작 시 커밋되지 않은 트랜잭션의 변경을 언두 로그로 되돌립니다.

흔한 실수: 롤백을 "변경을 안 했던 것으로 되돌린다"고만 답하는 것. 옛 값을 어디에 보관했는지가 질문의 요지입니다.

데이터 파일보다 로그를 먼저 디스크에 쓰는 방식으로 보장합니다.

1. 변경 내용을 로그에 적고 디스크에 반영한다
2. 커밋 응답을 보낸다
3. 실제 데이터 페이지는 나중에 모아서 디스크에 쓴다

데이터 파일을 매번 쓰면 무작위 위치에 흩어져 느립니다. 로그는 순차 쓰기라 훨씬 빠릅니다. 그래서 로그만 확실히 쓰고 데이터는 미뤄도 지속성이 성립합니다. 장애가 나면 로그를 다시 재생해 복구합니다.

성능과 안전의 조절점이 있습니다.

흔한 실수: 커밋하면 데이터 파일에 바로 쓴다고 답하는 것. 로그가 먼저이고 데이터는 나중이라는 순서가 핵심입니다.

많은 제품이 지원하지만 범위가 다릅니다.

초기 NoSQL 이 ACID 를 포기한 이유는 분산 확장을 위해서였습니다. 여러 노드에 걸친 트랜잭션은 노드 간 합의가 필요해 느리고, 네트워크가 끊기면 멈춥니다.

지금은 대부분 단일 파티션 안에서는 ACID 를 주고, 파티션을 넘으면 비용이 크다는 것을 명시하는 형태입니다. 그래서 파티션 키 설계가 곧 트랜잭션 경계 설계가 됩니다.

흔한 실수: NoSQL 은 ACID 를 지원하지 않는다고 단정하는 것. 지금은 정확하지 않고, 어느 범위까지인지가 실제 질문입니다.

중간에 실패하면 돈이 사라지거나 생깁니다.

트랜잭션이 있으면 2번 실패 시 1번도 함께 취소되어 원래 상태로 돌아갑니다.

동시성 문제도 있습니다. 잔액 10만원인 계좌에서 두 요청이 동시에 10만원을 출금하면, 둘 다 잔액을 확인한 뒤 각자 차감해 잔액이 마이너스가 될 수 있습니다. 이것은 원자성만으로는 부족하고 격리성이 필요한 문제입니다.

흔한 실수: 원자성만 말하고 격리성을 빼는 것. 실무 사고는 중간 실패보다 동시 실행에서 더 자주 납니다.

여러 노드가 함께 커밋할지 말지를 합의해야 하는데, 그 과정이 느리고 장애에 약하기 때문입니다.

그래서 실무에서는 강한 일관성을 포기하고 단계별로 처리하고 실패하면 보상하는 방식을 씁니다. 결제가 실패하면 이미 잡은 재고를 되돌리는 식입니다.

흔한 실수: 분산 트랜잭션이 불가능하다고 답하는 것. 가능하지만 비용이 커서 잘 안 쓴다는 것이 정확합니다.