ACID(transactional의 기본 성질)란?

최근 눈비가 엄청나게 내렸다. 필자는 그 소식도 모르고 빨래를 열심히 널어두고 출근을 했지만 말이다. 하하 인생.. 맘먹은대로 되는게 하나도 없구나. 아무튼 이 산성비에서 산성은 영어로 ACID이다. 이거 어디서 많이 보지 않았나? JAVA로 개발하는 사람들. 특히 백엔드에서 먹고사는 사람들이라면 당연히 봤을 transactional의 기본 성질에 대한 내용이다. 오늘은 여기에 대해 알아보도록 하겠다.

 

사실 springboot를 하면서 팔자에도 ㅇ벗는 Java를 공부하고 있는데 살려줘 아니 죽여줘. 

 

영어쓰는 사람들이 으례 그렇듯 앞글자를 따서 단어를 만들기 좋아하는데 atomic(사무라이 아님) consistency, lsolation, durability 이 4가지 단어의 앞글자를 따서 acid라는 용어를 만들었다. 하여튼 약자좋아하는건 정말...

 

 

 

Atomic

  => 아톰아니고 아토믹사무라이 아니고 원자성이다!

 

눈을 감고 상상해보자. 오늘은 즐거운 월급날. 신난다 유후~ 자 큰맘먹고 맥북m1을 구매할려고 한다. 애플 스토어에서 결제를 딱! 했는데 갑자기! EMP가 빵! 정전이 딱!!

정신을 겨후 차리고 구매 완료를 할려고 했는데 직원이 내 손을 딱 잡고 말하길

 

'손님 결제 안됬어요 어 딜도 망가 세요?'

 

그렇다 내 통장에서는 돈이 빠져나갔지만 에플스토어에서는 돈이 입금되지 않았다!!!

 

라고 한다면....

 

 

 

아무튼 일반적으로는 이런 일이 일어날 수 가 없는데 여기서 원자성을 발휘하게 되는 것이다. 

 

계좌이체 혹은 결제 등의 경우의 프로세스는 다음과 같은데 

 

1. 돈을 보내는 사람이 계좌에서 돈을 이체를 한다.

2. 이 후 은행을 통해 수신자에게 입금이 된다.

 

하지만 이때 이체 직후 와 입금 그 사이에 금방 상상했던 것과 같은 일이나 특별한 이벤트(정전, 전쟁, 자연재해 기타등등)가 발생해 입금 이라는 액션이 발생되지 않는다면? 그럼 내 돈은 나가기만하고 상대방에게 들어간게 아니니까 어디로 붕 뜬건데 은행을 족처야하나? 아니 일단 고소를 아니 일단 전쟁이 난거같으니 군복을..등등 별의별 생각을 하게될것이다. 

 

하지만 현실에서는 어지간하면 일어날 일이 없는데. 그 이유는 두가지의 업무(이체,입금)을 하나의 트렌젝션으로 묶어서 두가지 모두가 성공할 시 작업을 진행하는 것이다.

만약에 이체는 됬지만 입금이 되지 않는다면 이 상황 자체를 lolback(드립치고싶었어요 죄송해요 잘못했어요)시켜서 이체를 하지 않은 상태로 되돌리는것.이다.

 

 

Consistency  => 일관성

 

다음의 짤로 설명이 가능하다.

 

다음의 짤은 홍명보 선수의 표정의 일관성에 대한 짤이다. '4강'파트를 제외하고 전부 일관성이 있다. 하지만 이렇게 되서는 acid에서 말하는 일관성에 참여할 수 없다. 아쉽게도 그에게 쥐어지는 탈락목걸이

기본적으로 모든 데이터베이스 테이블의 자료는 정해진 규칙에 맞춰서 저장되야하고 트렌젝션이 종료되는 그 지점에서는 일관성이 반드시 맞춰저 있어야한다. 트렌젝션이 처리되는 중간에는 약간 어긋날 수 도 있지만 반드시 커밋되는 시점에는 일관성이 형성되 있어야 한다.

ex) -통장이 아닌계좌에 1,000원이 있는데 출금이 10,000원이 된다. ==> 일관성이 어긋난다.

Isolation  => 고립성

마치 우리팀 정글처럼 가장 까다롭다. 성능과 트레이드 오프 관계라고 할 수 있다.

DB를 갱 한 번 안가는 우리팀 탑마냥 고립을 잘 시킨다면 데이터의 정확성이 엄청나게 올라가게 되지만 이와 반대로 맨날 바텀에사는 적 정글마냥 아무나 사용할 수 있도록 고립성을 낮추게 될 경우 데이터의 정확성이 낮아지게 된다. 

 

즉 데이터의 대량처리시 낮은 단계의 고립성, 중요정보일수록 고립성이 높아져야한다.

Durability  => 지속성

이 짤 하나면 99% 이해할 수 있다.

 

커밋이 되었다. 라고 할때 이 이력은 무조건 남아있어야 하며 데이터를 지울때도 지우는것 까지도 이력이 남아야 한다.

마치 조선왕조실록처럼 왕이 이 기록을 지우라고 했다고 하셨다. 라는것 까지 쓰는것과 같다.
이것을 DB에 적용해 본다면, db에서도 오류가 발생할 수 있다. 그렇기에 바로 저장하는것이 아니라 먼저 로그를 기록한 후 이 데이터를 기반으로 db디스크에 쓰는 작업을 한다. 이때 디스크가 문제가 생길경우 로그는 남았지만 디스크에는 반영이 안된다. 즉 로그가 다 저장되야만 데이터가 저장된다.

 

요즘은 기술이 좋아서 오토로 자주 사용한다고 한다.