개발놀이터
Phantom Read 부정합문제 해결방안 In PostgreSQL, MSSQL Server 본문
이번 포스팅에서는 Repeatable Read 격리수준에서 발생하는 부정합 문제인 Phantom Read 를 PostgreSQL과 MSSQL에서는 어떻게 해결했는지에 대해서 포스팅해보겠습니다.
우선 PostgreSQL과 MSSQL을 묶은 이유는 두개의 데이터베이스가 Phantom Read 부정합문제를 같은 방식으로 해결했기 때문입니다.
우선 저는 이번에 PostgreSQL에 대해서 자세히 알게 되었습니다. 얼마전까진 있었는지도 몰랐구요. 그래서 간단하게 PostgreSQL에 대해서 정리하고 본격적으로 해결방안에 대해서 말씀드리겠습니다.
PostgreSQL이란?
PostgreSQL은 RDBMS 중 하나입니다. 기존 Postgres에서 SQL을 지원하게 된 것이 지금의 PostgreSQL이라고 합니다. 초기 Postgres가 지금의 전신인것이죠.
PostgreSQL의 가장 두드러지는 특징은 바로 오픈소스 데이터베이스라는 것입니다. 따라서 데이터베이스를 사용하는데에 필요한 저작권료가 들지 않습니다.
또한 JSON을 핸들링하는데 탁월한 성능을 보인다고합니다. PostgreSQL은 JSON을 만드는 함수를 추상화해놔서 좀 더 효율적으로 사용할 수 있다고 하는군요. 다른 데이터베이스는 JSON을 만드는 함수가 복잡해서 그렇지 못하다고 합니다.
오픈소스라서 그런지 오픈소스의 특징 중 하나인 커스터마이징을 쉽게 할 수 있다는 점과, 트러블 슈팅을 관리하는 것도 유연하게 처리할 수 있다고 합니다.
위의 장점은 PostgreSQL을 실제로 쓰고 있는 분께서 나열한 장점이기 때문에 사실과 다를 수 있습니다.
제 개인적인 생각으로는 장점은 개발자 맘대로 모든 것을 할 수 있다는 점이고 단점은 그만큼 러닝커브가 있다는 것이겠죠.
PostgreSQL의 인지도
제가 PostgreSQL을 들어보지 못한 이유가 있습니다. 이유야 단순하죠 그렇게까지 많이 사용하지 않습니다. 제가 데이터베이스 기본 상식이 조금 부족하긴 했지만 Oracle, Mysql, MongoDB, MariaDB, MSSQL, NOSQL 이정도는 들어봤는데 PostgreSQL을 들어보지 못했습니다.
위의 장점들은 그렇다 치고 저렇게 대단하다면 많은 사람들이 썼을거라는 것이 저의 생각입니다.
사람들이 많이 선택하고 그것이 보편화 되는 이유는 그럴만한 이유가 있다고 생각합니다.
PostgreSQL의 인지도를 알기 위해서 조사를 좀 해보니 StackOverFlow의 실무에서 일하는 개발자를 대상으로 설문조사를 한 적이 있는데 거기서 PostgreSQL이 2등을 했다고 합니다.
하지만 이건 절대 신뢰할 수 없겠더군요. 왜냐면 Oracle이 8등이었기 때문입니다. 제가 아무리 몰라도 Oracle이 8등할 네임벨류는 아닌데말이죠.
도저히 신뢰할 수 없어서 좀 더 믿을만하고 현실적인 자료를 조사했습니다.
거의 대부분의 산업에 대하여 통계를 전문적으로 조사하는 statista라는 사이트를 발견해서 거기서 통계자료를 좀 가져와봤습니다.
이제 좀 현실적인 느낌이 드네요.
기존에 보편적으로 사용하는 3대 데이터베이스인 Oracle, Mysql, MSSQL과는 좀 차이가 있지만 오픈소스 데이터베이스치고는 많이 사용하는 것으로 확인됐습니다.
PostgreSQL을 사용하는 대표적인 회사는 초기 애플, 인스타그램, 레딧, 스카이프 정도가 있습니다. 여기서 초기 애플이라고 한 이유는 애플은 2010년까지 PostgreSQL을 사용하다 Mysql로 바꿨습니다. 왜냐하면 애플은 오라클의 데이터베이스 솔루션에 좀 더 집중을 했기 때문이죠.
자 이제 본격적으로 Phantom Read 에 대해서 알아보죠
PostgreSQL의 PhantomRead 해결방안
처음엔 구글에 Phantom Read solution In PostgreSQL official documentation 라고 쳤는데 안나오더군요 (Mysql은 나왔는데...) 우선적으로 영어로 작성된 블로그들을 살펴보고 크게 얻을만한게 없어서 결국 공식문서를 찾게 되었습니다.
아무래도 Phantom Read가 격리수준에 의한 side effect이기 때문에 isolation level이라는 키워드로 검색해봤더니 나왔습니다.
하지만 공식문서가 좀 부실하더군요... 오픈소스는 다 이런가? 이전에 Mysql 공식문서를 읽고 와서 그런지 확실히 알려주지 않더군요.
격리수준에 대한 내용에서도 Phantom Read에 대한 내용은 코빼기도 보이지 않더군요. 심지어 Repeatable Read는 학술적인 데이터베이스 문헌과 다른 데이터베이스에서 사용한 Snapshot Isolation을 이용해 구현했다. 라고 하더군요...
처음에 academic database literature에서 순간 architecture하고 헷갈려서 구글링해봤더니 무슨 논문이 쏟아져나오길래 다시 눈비벼서 확인해보니 학술적인 데이터베이스 문헌이었습니다.
그래도 하나 건진건 있었습니다. 바로 Snapshot Isolation이죠.
우선 Snapshot(이하 스냅샷)에 대해서 알아보죠.
위키피디아에서 나온 스냅샷은 다음과 같습니다.
In computer systems, a snapshot is the state of a system at a particular point in time.
컴퓨터 사이언스에서 스냅샷은 특정 시간에 특정 지점에대한 시스템의 상태이다. 즉, 특정한 지점에서의 그 상태 바로 그것이죠.
Snapshot Isolation
스냅샷 격리수준은 트랜잭션의 모든 쿼리가 트랜잭션이 시작되는 시점의 데이터베이스의 상태를 기반으로 작동하는 방식입니다. 앞서 봤던 스냅샷의 정의와 일치하네요.
스냅샷 트랜잭션의 기본 데이터 행이나 데이터 페이지에서는 잠금이 인식되지 않습니다. 따라서 이전에 완료되지 않은 트랜잭션에 의해 차단되지 않고 다른 트랜잭션을 실행할 수 있습니다.
데이터를 수정하는 트랜잭션은 데이터를 읽는 트랜잭션을 차단하지 않으며, 데이터를 읽는 트랜잭션은 일반적으로 데이터를 쓰는 트랜잭션을 차단하지 않습니다.
이러한 비차단 동작 덕분에 복잡한 트랜잭션에 대한 교착 상태의 가능성이 크게 줄어듭니다.
즉, 우리가 Mysql에서 Phantom Read를 해결할 때 Shared Lock과 Exclusive Lock에 대해서 확인한 내용과 비슷한 내용입니다. 하지만 Mysql의 (s)Lock과 (x)Lock과는 완전히 다릅니다.
Mysql에서의 (s)Lock은 같은 읽기 트랜잭션인 경우만 공유가 가능하고 (s)Lock과 (x)Lock이 만나면 (x)Lock은 락이 풀릴때까지 기다려야합니다.
스냅샷 격리수준은 낙관적 락을 채택하고 있습니다.
낙관적 락, 비관적 락
이 두개는 간단한 내용이니 빠르게 짚고 넘어가겠습니다.
낙관적 락은 트랜잭션의 동시성문제가 발생하지 않는다고 생각하고 두 트랜잭션의 충돌에 의해 동시성 문제가 일어나면 시스템적으로 오류가 발생했다고 판단하고 에러를 뱉으며 데이터베이스 서버가 죽어버립니다.
비관적 락은 반대로 트랜잭션의 동시성문제가 반드시 발생한다고 생각하고 작동하는 락입니다. 두 트랜잭션의 충돌에 의해 동시성 문제가 일어나면 무조건 해결해야하는 방식입니다. 흔히 Mysql의 방식이 있죠. 복습하자면 Mysql에서는 Record Lock과 Gap Lock을 합친 Next-Key Lock을 이용해 이러한 동시성문제에 대해 해결했습니다.
스냅샷 격리가 낙관적 락을 채택하고 있기 때문에 만약 두 트랜잭션에 의해 동시성문제가 발생하려고 하면 에러를 뱉습니다.
즉, PostgreSQL과 MSSQL은 스냅샷 격리를 이용해 Repeatable Read 격리수준에서 Phantom Read 부정합 문제를 해결했다는 결론이 나옵니다.
여기까지 PostgreSQL에 대해 알아봤고, 스냅샷 격리수준에 대해서 알아봤습니다. 흠... 뭔가 시원하게 문제가 해결되지 않은 느낌이 들긴 합니다. 하지만 스냅샷 격리라는 새로운 내용에 대해서 알게되었고, PostgreSQL의 전반적인 내용에 대해서 알게된 것은 나쁘지않은 성과라고 생각합니다.
다음은 데이터베이스들의 왕 Oracle입니다. 아마 가장 대중적으로 사용하는 데이터베이스가 아닐까 싶습니다. 다음 포스팅에서는 Oracle에서 Phantom Read를 어떻게 해결했는지에 대해서 알아보도록 하겠습니다.
긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~
출처
https://www.postgresql.org/docs/current/transaction-iso.html
13.2. Transaction Isolation
13.2. Transaction Isolation 13.2.1. Read Committed Isolation Level 13.2.2. Repeatable Read Isolation Level 13.2.3. Serializable Isolation Level The SQL standard defines …
www.postgresql.org
=> PostgreSQL 공식문서
https://learn.microsoft.com/ko-kr/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
SQL Server의 스냅샷 격리 - ADO.NET
SQL Server의 스냅샷 격리 및 행 버전 관리에 대한 개요를 읽고 격리 수준으로 동시성을 관리하는 방법을 알아봅니다.
learn.microsoft.com
=> 스냅샷 격리수준 MS 공식문서
https://en.wikipedia.org/wiki/Snapshot_(computer_storage)
Snapshot (computer storage) - Wikipedia
From Wikipedia, the free encyclopedia Example of snapshots of a Btrfs filesystem, managed with snapper In computer systems, a snapshot is the state of a system at a particular point in time. The term was coined as an analogy to that in photography. It can
en.wikipedia.org
=> 스냅샷 In 위키피디아
Most popular relational DBMS 2022 | Statista
As of January 2022, the most popular relational database management system (RDBMS) in the world was Oracle, with a ranking score of 1266.89.
www.statista.com
=> RDBMS 통계
https://learnsql.com/blog/companies-that-use-postgresql-in-business/
Which Major Companies Use PostgreSQL? What Do They Use It for?
Want to know which companies use PostgreSQL? Learn why they choose this solution.
learnsql.com
=> PostgreSQL을 사용하는 대표적인 회사
https://www.quora.com/What-differentiates-PostgreSQL-from-other-RDBMS-systems
What differentiates PostgreSQL from other RDBMS systems?
Answer (1 of 3): Since this question is very subjective I will answer accordingly. Postgres is awesome and free. It is the most mature open source RDBMS platform by far. It has an optimizer that can handle a wider variety of models and far Superior to any
www.quora.com
=> PostgreSQL과 다른 데이터베이스의 차이점
'CS 지식 > 데이터베이스' 카테고리의 다른 글
| NoSQL 이란? (0) | 2023.03.09 |
|---|---|
| Phantom Read 부정합문제 해결방안 In Oracle (0) | 2023.03.06 |
| Phantom Read 부정합문제 해결방안 In Mysql (0) | 2023.03.04 |
| MVCC (Multiversion Concurrency Control) (2) | 2023.03.04 |
| 트랜잭션과 ACID (자바에서 트랜잭션을 다루는 방법에 대한 관점으로) (0) | 2023.02.27 |
