데이터 집약적 애플리케이션 설계

7장. 거래

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

일부 작성자는 일반적인 2단계 커밋은 성능 또는 가용성 문제로 인해 지원하기에는 너무 비싸다고 주장했습니다. 저희는 애플리케이션 프로그래머가 항상 트랜잭션 부족을 염두에 두고 코딩하는 것보다 병목 현상이 발생할 때 트랜잭션 남용으로 인한 성능 문제를 처리하는 것이 더 낫다고 생각합니다.

제임스 코벳 외., 스패너: 구글의 전 세계 분산 데이터베이스 (2012)

데이터 시스템의 가혹한 현실에서는 많은 일이 잘못될 수 있습니다:

• 데이터베이스 소프트웨어 또는 하드웨어는 언제든지(쓰기 작업 중에도 포함) 오류가 발생할 수 있습니다.

• 애플리케이션은 언제든지(일련의 작업 도중에 포함) 충돌할 수 있습니다.

• 네트워크가 중단되면 예기치 않게 애플리케이션이 데이터베이스에서 차단되거나 한 데이터베이스 노드가 다른 데이터베이스 노드에서 차단될 수 있습니다.

• 여러 클라이언트가 동시에 데이터베이스에 글을 쓰면서 서로의 변경 내용을 덮어쓸 수 있습니다.

• 클라이언트는 부분적으로만 업데이트되어 의미가 없는 데이터를 읽을 수 있습니다.

• 클라이언트 간 경쟁 조건으로 인해 예상치 못한 버그가 발생할 수 있습니다.

시스템이 안정적이려면 이러한 결함을 처리하고 전체 시스템에 치명적인 장애를 일으키지 않도록 해야 합니다. 그러나 내결함성 메커니즘을 구현하는 것은 많은 작업이 필요합니다. 잘못될 수 있는 모든 것에 대해 신중하게 생각하고 솔루션이 실제로 작동하는지 확인하기 위해 많은 테스트가 필요합니다.

수십 년 동안 트랜잭션은 이러한 문제를 단순화하기 위해 선택된 메커니즘이었습니다. 트랜잭션은 애플리케이션이 여러 읽기 및 쓰기를 하나의 논리적 단위로 그룹화하는 방법입니다. 개념적으로 트랜잭션의 모든 읽기와 쓰기는 하나의 작업으로 실행되며, 전체 트랜잭션이 성공(커밋)하거나 실패(중단, 롤백)합니다. 실패하면 애플리케이션은 안전하게 재시도할 수 있습니다. 트랜잭션을 사용하면 부분적인 실패, 즉 어떤 이유로든 일부 작업이 성공하고 일부 작업이 실패하는 경우를 걱정할 필요가 없으므로 애플리케이션의 오류 처리가 훨씬 더 간단해집니다.

수년간 트랜잭션 작업을 해왔다면 트랜잭션이 당연한 것처럼 보일 수 있지만, 당연하게 생각해서는 안 됩니다. 트랜잭션은 자연의 법칙이 아니라 데이터베이스에 액세스하는 애플리케이션의프로그래밍 모델을 단순화하기 위한 목적으로 만들어졌습니다. 트랜잭션을 사용하면 데이터베이스가 대신 처리하기 때문에 애플리케이션은 특정 잠재적 오류 시나리오와 동시성 문제를 무시할 수 있습니다(이를 안전 보장이라고 부릅니다).

모든 애플리케이션에 트랜잭션이 필요한 것은 아니며, 때로는 트랜잭션 보장을 약화하거나 ...