[독서노트] 데이터 중심 애플리케이션 설계 - 7장 트랜잭션

이전에 독서노트 작성 방법을 포스팅 한 적이 있습니다.

https://jongwho.tistory.com/17

[Youtube 영상 요약] - 독서 메모법

 

위 메모법을 바탕으로 '데이터 중심 애플리케이션 설계' 7장 트랜잭션을 요약해보겠습니다.

키워드 요약

약 2페이지마다 읽은 내용을 요약해서 키워드로 정리해보겠습니다. 페이지의 구분은 '/'로 하겠습니다.
트랜잭션, 안전성 보장 / 원자성, 어보트 보장 / 일관성 모호, 격리성 보장X/ 완벽한 보장 X, 단일 보장-> 다중 어플리케이션/갱신손실보장, 오류 중간저장 가능/트랜잭션 격리, 커밋 후 읽기/1트랜잭션 1커밋, 쓴 것을 기억 쓸 것을 기억/일관성 버그, 스냅숏 격리로 해결/ MVCC, 스냅숏 규칙/ 페이지 내 회피갱신, 반복읽기 용어 불명확/ 원자적 쓰기 연산, 명시적 잠금 -> 갱신 손실 방지/ Compare-and-set, LWW(최종 쓰기 승리)/ 쓰기 스큐, 약한 경쟁 But 문제!/ 팬텀 문제(검색 질의 시 변경), 트랜잭션 분리로 해결 불가/ 충돌 구체화(최후의 수단), 직렬성 격리/ 직렬성 구현 간접적 -> 레디스, 스토어드 프로시져 / 2단계 잠금, 교착 상태 방지를 위한 어보트 하지만 성능 떨어짐/Index-range Locking, 범위 조건을 붙여 잠금/직렬성 스냅숏 격리, 낙관적 동시성 제어

두꺼운 책 인만큼 키워드도 많습니다. 이를 연결해서 노트로 만들어보겠습니다.

트랜잭션은 안전성을 보장하기 위함 ACID 입장에서 본다면 원자성이란 결국 어보트 기능을 보장. 일관성은 모호하며 격리성은 보장된다고 할 수 없음
결국 완벽한 보장이란 없으며 단일 보장은 다중 어플리케이션에 적용. 갱신 시 손실에 대한 보장이 있어야 하며 이를 위해 오류 중간 저장 기능이 있어야 한다. 트랜잭션 격리로 격리성을 보장, 그 방법 중 하나로 '커밋 후 읽기'가 있음 1트랜잭션은 1커밋이라고 보면 됨. 쓸 것과 쓴 것을 기억하여 격리성을 보장한다. 일관성 보장에서 발생하는 버그는 스냅숏 격리로 해결 할 수 있음. MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어) 및 스냅숏 가시성 제어 규칙으로 스냅숏을 제공함
Postgresql에서는 페이지 내 회피 갱신으로 스냅숏 격리를 제공함. 스냅숏 격리의 또다른 이름은 반복 읽기(Postgresql
갱신 손실 방지를 위해 원자적 쓰기 연산과 명시적 잠금을 사용함. Compare-and-set 방식 사용하여 갱신 손실 방지 및 원자적 쓰기를 구현. 하지만 결국 LWW(최종 쓰기 승리) 원칙으로 돌아감
쓰기 스큐는 약한 경쟁이지만 문제가 발생할 수 있다. 팬텀 문제도 발생이 가능한데 이는 트랜잭션을 분리한다고 해결되는 것은 아니다. 충돌 구체화를 최후의 수단으로 사용할 수 있다. 또 다른 방법으로 직렬성을 격리하여 쓰기 스큐를 방지할 수 있다. 간접적으로 구현한 것은 Redis(CPU를 단일 사용하여 격리성 확보). 직렬성의 구현은 스토어드 프로시져를 사용하여 구현이 가능하며 또한 2단계 잠금 알고리즘으로도 구현이 가능하다. 하지만 2단계 잠금 알고리즘은 성능이 떨어진다(교착 상태가 발생하면 이를 방지하기 위해 1개 트랜잭션을 어보트함). 다른 방법으로 색인 범위 잠금(Index-range Locking)을 사용하여 잠금 할 수 있다.
이와 반대로 '직렬설 스냅숏 격리' 방법을 사용하여 성능까지 보장하는 직렬성을 구현할 수 있다. 낙관적 동시성 제어라고도 한다.

 

 

정리한 노트를 읽어보면 뭔가 빠진 부분이 많고 연결이 부드럽게 되지 않습니다.

제가 키워드를 적고 정리하면서 느낀 점은 단순 키워드 보다는 설명이 추가된 짧은 문장이나 부제목 또는 제목을 적어 어떤 내용에 대해 적었는지 추가적인 설명이 필요할 것 같습니다.

 

다음 8장을 읽으면서 키워드가 아닌 짧은 문장 및 제목이나 부제목(분류)을 적어 조금 더 매끄럽게 정리 해보겠습니다.