본문 바로가기
Programing/DB

[DB] Concurrency Problem (동시성 이슈)

by 꾸압 2022. 10. 20.

 

<전제>

  - 여러 user에 의해 변경 사항이 발생해도, data managerdataintegrity(완전성, 영향받지 않은 온전한 상태)를 보장해야 함.

  - Concurrency 는 application이 선언 혹은 만들어질 때만 가능하므로 global temporary table의 문제는 아님.

 


 

<DB Transaction Isolation level 에 따른 동시성 이슈>

  - 가장 낮은 isolation level 0 에선 lock이 걸리지 않아 속도가 매우 빠름. && 동시 접근을 허용하기에 data 정합성에 문제 발생 가능.

  - 가장 높은 isolation level 3 에선 완전히 lock을 걸어 동시 접근 차단 및 순차 처리(Serializable).

    ==> 정합성은 완벽하지만 동시처리 양이 적어 속도가 매우 느림. 

출처 : letmecompile.com

 


 

<설명>

  - (사전 의미) 1개의 CPU Core에서 Time Sharing을 통해 여러 일을 처리하는 것처럼 보이게 함.

  - (개발자 의미) 상호작용하는 다수의 user 또는 application 이 동시에 resource를 공유하는 것.

  - Database Manager는 발생가능한 문제를 예방하기 위해 이런 접근을 제어함.

 


 

<발생가능 문제>

(1) Lost Updates :

  - A,B 라는 두 application이 동시에 같은 row를 읽고, column data에 기반하여 읽고 있는 column에 새로운 값을 계산 작업을 한다.

  - 만약 Adata update를 한 뒤 Bupdate하면, A update한 값은 lost .

출처 : Geeksforgeeks

 

 


 

(2) Access to Uncommitted Data :

  - Temporary Update Problem 이라고도 불림. 

  - application A가 값을 update할 때 BA datacommit하기 전에 읽을지도 모른다.

  - 이후에 만약 A update에서 벗어나면, Binvaliddata (update 이전 data) calculation을 할 수도 있음.

출처 : Geeksforgeeks

 


 

(3) Non-Repeatable Reads :

  - [상황] 2개 이상의 읽기 작업이 동일한 read transaction에서 일어날 때 같은 변수를 각기 다른 value로 read하여 문제 발생.

  - application A가 다른 요청을 처리(processing)하기 전에 row를 읽을 지도 모름.

  - 그동안 application B row를 변경 또는 삭제하고, 그 변경 사항을 commit .

  - 나중에 application A가 원본 row를 다시 읽으려 한다면, A는 변경된 row를 읽거나 원본 row가 삭제된 걸 발견할 것이다.

출처 : Geeksforgeeks

 

 


 

(4) Phantom Reads :

  - [상황] 동일한 transaction에서 한쪽이 읽으려 하는데 다른 쪽에서 삭제해버려 장애 발생.

  - application A어떤 검색 기준을 기반한, row 집단이 읽는 query’를 처리할지도 모른다.

  - 그 와중에 application B가 새로운 data를 삽입하거나, application Aquery에 만족할 만한 이미 존재하는 dataupdate 한다.

  - A는 동일한 작업 단위(unit) 안에서 query를 다시 처리하며 몇몇 추가된 value (phantom)을 반환함.

출처 : Geeksforgeeks

 

(5) Incorrct Summary Problem :

  - 어떤 transaction(A) 에서 기록된 정보에 대해 function을 적용하는 동안, 다른 transaction(B)이 update를 함. 

  - transaction A는 transaction B 가 update하기 전&후 로 각기 다른 값을 연산함.

출처 : Geeksforgeeks

 


 

[고려 사항]

  - 동시성 이슈와 transaction 격리 수준은 trade-off 관계.

출처 : DATA ON-AIR

  - 동시성 이슈가 발생하지 않는다는게 해당 transaction isolation level을 만족시키는건 아님.

  ex) Repeatable Read level 에서 Phantom Read가 발생하지 않는다하여 무조건 Serializable 레벨이 되는건 아님

  ex) Phantom Read가 발생하면, 해당 transaction isolation level은 Serializable level 이 될 수 없음.

 


 

<출처>

<출처 1> https://www.ibm.com/docs/en/db2/11.1?topic=design-concurrency-issues

<출처 2> https://dataonair.or.kr/db-tech-reference/d-guide/sql/?mod=document&uid=363

<출처 3> https://www.geeksforgeeks.org/concurrency-problems-in-dbms-transactions/

<출처 4> https://www.letmecompile.com/database-transaction-isolation-level/

<출처 5> https://chrisjune-13837.medium.com/db-%EB%8F%99%EC%8B%9C%EC%84%B1-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95-f5e52e2e3

 

 

 

'Programing > DB' 카테고리의 다른 글

[DB] MySQL Table 구조 및 데이터 복사  (0) 2022.11.16
[DB] MySQL Table 수정&교체  (0) 2022.11.03
[MySQL] innoDB_file_per_table 옵션 설정  (0) 2022.07.01
[MySQL] Data Directory 위치 찾기  (0) 2022.06.29

댓글