[도서 회고록] "DB 트랜잭션 동시성 제어" 를 읽고

나의 느낀점과 간단한 정리를 할 예정이다.

 

뭐... 개발자 나부랭이가 후기를 남겨보지만 긍정적이지는 않다. 이전에 읽었던 친절한 SQL 튜닝보다 분량은 적은데 상대적으로 깔끔하지 않아 힘들었다.

 

그래서 초기에는 1장에서 불만을 엄청 토로했지만 막상 또 2회독 해보니 내가 모르는게 많았고

사실 반정도 또 다시 읽고 보다가 멈췄다. (솔직히 재미없다)

 

 

1. DB 초보로서 이해하기 너무~ 어려웠던 설명들

 

결론만 말하자면 필자에게 정말 너무너무 어려웠다.

 

트랜잭션 격리 단계가 Read Uncommitted, Read Committed, Repeatable Read, Serializable 이렇게 4가지 트랜잭션 격리 수준이 존재하는데 책에서 SQL Server, MySQL, Oracle, PostgreSQL 총 4개에 대해서 이야기 한다.

 

크게 목차만으로 봐도 문장 수준 읽기 일관성, 문장 수준 쓰기 일관성, 트랜잭션 수준 일관성, 트랜잭션 동시성 제어에 대해서 설명한다.

의문점은 분명 다 다른 주제에 대해서 이야기하는데 2장, 3장, 4장, 5장 다 무언가 반복되는 느낌이다.

 

그래서 스스로 notion에도 조금씩 헷갈리는 부분을 정리하며 읽고 해도 ... 너무 너무 비슷한 예시가 계속 연출되니 이게 맞나 싶다.

 

 

그나마 다행인 점은 책에서 꼭 최소 2번 이상 읽으라고 했는데 

 

처음 읽을때는 다 고만고만한 상황에 대해서 이야기 하는데 도대체 뭘 말하는지 이해를 못했다.

 

 

또 중간에 갑자기 용어도 바뀌고 사용법도 모르는 쿼리가 나온다.

 

Current 모드라고 설명하다가 Locking Read(Current 모드 읽기)로,

 

Consistent Nonlocking Read(Consistent 모드 읽기)로 변경이 되는가 하면 

 

for update, for share 라든지 말이다. 뭐 말은 다 해줫으니 스스로 정신차리고 보는게 맞지만 냉정하게 말하면 초보자 친화적이진 않다.

 

마지막으로 설명도 설명이지만 결론이 그래서 뭔데? 를 찾으려면 저~~~~어기 뒤에 있으니 다 그 밥에 그 나물 같은 예시로 기억해내려면 결론을 보더라도 이해가 안됀다. 

 

결론은 그래서 어쩌자는건데? Serializable을 쓰면 다 막히는데 적절히 잘 알아서 써야 한다로 현재는 이해했다.

그런데 성능상 문제가 많으니 DB말고 다른 수단을 적절히 써야 한다! 로 이해했다.

(아직 저의 수준이 이정도입니다... 문제시 피드백 달게 받겠습니다 ㅠㅠ...)

 

 

 

개인적으로는 각각 섹션에 대해서 완벽한 분리를 하기 힘들더라도 

깔끔한 설명을 통해 혼란을 없애기 위해 이를 최대한 단절시키는게 낫지 않나 하는 아쉬움이 있다.

 

 

 

생각해보니 책을 쓴다는것이 참 어려울거 같다는 생각이 든다. 

 

이 책은 이미 어느정도 DB에 대해서 아는 사람들이 읽어야 하는 책인데, 초보에서 중급 혹은 중급에서 고급으로 발전하기 위해서는 

 

어려운 것에 대해서도 스스로 고민하고 이해할 수 있어야 하는데 과연... 필자같은 초급 수준에서는 어디서부터 몰라서 이 글들이 이해가 안되는지를 찾는것도 일이기 때문이다.

 

그렇기에 저자의 입장에서는 최선을 다해서 설명해도 필자처럼 예시가 헷갈린다고 하니 요즘 양산형 쇼츠의 말을 빌리자면 정말 환장할 노릇이겠다. (이때 누군가 멋진 아이디어를 생각해냈어요)

 

 

2. 그럼에도, 읽기를 강추하는 이유

 

회사에서 상사가 이런 말을 한 적 있다.

 

최대한 루프를 돌지 않게 해야해. 

 

 

사실 RDB에서 조인이 발생하지 않도록 하는것은 불가능하다. 그러나 다양한 동시성 문제에 대해 고려하기 싫어서 최대한 원테이블 쿼리를 지향하는 목적을 최근에 이해할 수 있었다. (이래서 개발은 철학을 이해하는 과정이라 했던가...)

 

조인을 하게 되면 루프가 발생한다는 말이었는데 이제는 그 말이 nested loop join이고 또한 이 과정에서 동시성 문제가 발생할 수 있음을 "친절한 SQL 튜닝" 과 이번에 읽은 책인 "DB 트랜잭션 동시성 제어" 책 을 읽고 나서 알게 되었다.

 

동시성 문제에 대해서 이렇게 DB관련해서의 문제에 대해서 필자는 사실 고민해본 적이 없다.

 

가장 먼저 떠오르는 방법은 Redis를 활용해서 동시성 제어를 하는 방식이다.

 

 

개발자가 가장 많이 접하는 기본적인 툴로서 RDMBS를 다루는건 정말 중요하다.

 

이러한 옵션이며 문제가 있다는 것을 알고 개발에 임해야 나중에 큰 문제가 생길 때 현상을 파악할 수 있을 거라 생각한다.

 

사실 이런 DB의 그지같은(?) 동시성 문제가 싫어서 Application Level로 코드를 최대한 올리는것이 맞다고 생각한다.

 

추적도 되지 않을 뿐더러 특히 프로시저의경우 transaction이 또 별도로 생겨버리는 문제도 있고 확장하기에도 엉망진창이다. 

 

 

그럼에도 이러한 지식을 알고 있으면 큰 무기가 되리라 확신할 수 있는 책이었다.

 

 

 

현재 필자의 입장에서는 너무 과한 수준의 지식이라고 생각했다.

 

가장 중요한 것은 이걸 다 외우는게 아니라

 

어느 DB를 사용함에 따라 동시성 문제가 생길 수 있다!

 

이를 토대로 동시성 발생 상황에 대해서 대비가 되어 있는지를 늘 머릿속에 기억하고 있어도 합격! 이라고 생각한다.

 

키워드를 기억하면 검색을 하던, AI를 사용하면 되기 때문이다.

 

 

개인적인 의견으로는 이렇게 DB에 의존해서 동시성을 관리하는 것은 좋지 않다고 생각한다. 

 

물론 해당 책이 DB중심적으로 설명하는 책이기 때문에 너무나 당연하지만 

 

트랜잭션과 동시성 제어를 DB로만 한다면 시스템을 확장 시 정합성 체크시 엄청난 문제가 생길 것이다. 

 

물론 속도도 크게 문제가 생길 것이니 최대한 application 쪽으로 transaction 관리라던지 그런 것을 이관하고

 

그 이후에 또 어쩔 수 없는 경우에는 이렇게 각 DB관련해서 동시성 이슈에 대해 이해하는 것이 맞는 수순이라고 생각한다.