catpark's something new

isolation level이란 트랜잭션에서 일관성이 없는 데이터를 어디까지 허용하는 수준

트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준을 Isolation Level이라고 합니다. 예를 들어, 한 사용자가 어떠한 데이터를 수정하고 있는 경우 다른 사용자들이 그 데이터에 접근하는 것을 차단함으로써 완전한 데이터만을 사용자들에게 제공하게 됩니다. 또한, 많은 사용자들의 수정 작업으로 인하여 통계 자료를 작성할 수 없는 사용자를 위하여 읽기 작업을 수행할 수 있도록 Isolation Level을 변경할 수 있습니다. 
Isolation Level을 조정하는 경우 동시성이 증가되는데 반해 데이터의 무결성에 문제가 발생할 수 있거나, 데이터의 무결성을 완벽하게 유지하는 데 반하여 동시성이 떨어질 수 있으므로 그 기능을 완벽하게 이해한 후에 사용해야 합니다.

@Transactional (isolation = Isolation.DEFAULT | READ_COMMITTED | READ_UNCOMMITTED | REPEATABLE_READ | SERIALIZABLE)

다음은 MySQL에서 지원하는 네 종류의 Transaction Isolation Level입니다.

READ UNCOMMITTED

• COMMIT 되지 않은 데이터에 다른 트랜잭션에서 접근할수 있다.
• INSERT, UPDATE, DELETE 후 COMMIT 이나 ROLLBACK에 상관없이 현재의 데이터를 읽어온다.
• ROLLBACK이 될 데이터도 읽어올 수 있으므로 주의가 필요하다.
• LOCK이 발생하지 않는다.

READ COMMIITED

• Oracle DBMS의 경우 Default LEVEL이다.
• COMMIT 된 데이터에 다른 트랜잭션에서 접근할 수 있다.
• 구현 방식이 차이 때문에 Query를 수행한 시점의 데이터와 정확하게 일치하지 않을 수 있다.
• LOCK이 발생하지 않는다.
• MySQL에서 많은 양의 데이터를 복제하거나 이동할 때 이 LEVEL을 추천한다.

REPEATABLE READ

• MySQL InnoDB의 경우 Default LEVEL이다.
• SELECT시 현재 시점의 스냅샷을 만들고 스냅샷을 조회한다.
• 동일 트랜잭션 내에서 일관성을 보장한다.
• record lock과 gap lock이 발생한다.
• CREATE SELECT, INSERT SELECT시 lock이 발생한다.

SERIALIZE

• 가장 강력한 LEVEL이다.

• SELECT 문에 사용하는 모든 테이블에 shared lock이 발생한다.

위의 Transaction Isolation Level 은 Read Uncommited 에서 Serializable  순으로 Concurrency 는 높아지고 속도는 느려진다. 따라서 이 둘의 균형을 잘 맞추는 것이 중요합니다.

Isolation Level  에 따라 나타나는 현상이 세가지가 있습니다.

• Dirty Read
  • 어떤 트랜잭션에서 아직 실행이 끝난지 않은 다른 트랜잭션에 의한 변경 사항을 보게 되는 되는 경우를 dirty read 라고 합니다. 만약 원래 트랜잭션에서 그 변경 사항을 롤백하면 그 데이터를 읽은 트랜잭션은 dirty 데이터를 가지고 있다고 말합니다.
• Repeatable Read
  • 어떤 트랜잭션에서 같은 질의를 사용했을 때 질의를 아무리 여러번 해도 그리고 다른 트랜잭션에서 아무리 여러 번 그 행을 변경해도 항상 같은 데이터만 읽어드리는 경우를 repeatable read 라고 합니다. 즉 repeatable read 가 요구되는 트랜잭션에서는 다른 트랜잭션에 의한 변경 사항을 볼 수가 없습니다. 그러한 변경 사항을 보고 싶으면 어플리케이션에서 트랜잭션을 새로 시작해야 합니다.
• Phantom read
  • phantom read 는 다른 트랜잭션에 의한 변경 사항으로 인해 현재 사용 중인 트랜잭션의 WHERE 절의 조건에 맞는 새로운 행이 생길 수 있는 경우에 관한 것입니다. 예를 들어, 잔고가 $100 미만인 계좌를 모두 찾아내는 트랜잭션이 있고, 이 트랜잭션에서 그 데이터를 두 번 읽는다고 가정합시다. 처음 데이터를 읽어들이고 난 후에 다른 트랜잭션에서 잔고가 $0인 계좌를 새로 만들면 이 계좌도 잔고가 $100 이하라는 조건에 맞게 됩니다. 트랜잭션 격리 수준(Transaction Isolation Level)에서 phantom read 를 지원하면 새로운 “유령(phantom)”행이 나오지만 지원하지 않으면 새로 생긴 행을 볼 수 없습니다.

Tabel1. Ansi Isolation Levels

Mysql 의 InnoDB 스토리지 엔진의 기본 Isolation Level이 REPEATABLE-READ 이고 Oracle 은 READ-COMMITED 입니다. 각 DBMS별 isolation level 에 자세한 내용은 다음 링크에서 참조할 수 있습니다.

• mysql : http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html
• oracle : http://www.oracle.com/technetwork/issue-archive/2005/05-nov/o65asktom-082389.html

Oracle 은 READ-COMMITED 와 SERIALIZABLE 만 지원하며 나머지 두가지 isolation level  은 지원하지 않습니다.

isolation level 확인

mysql docker의 isolation level은 아래와 같습니다.

MySQL InnoDB의 Isolation LEVEL 문서

https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html

이글은 Quora에 올라온 “What’s the difference between sharding and partition?“글의 질문과 모자이크 CTO가 답변한 내용을 번역한 글입니다.

샤딩(sharding)과 파티셔닝(partitioning)의 차이가 무엇인가? 분산 데이터베이스 시스템에서 샤딩과 파티셔닝이라는 단어를 종종 듣는다. 하지만 그들의 차이점을 잘 모르겠다. 그래서 이것들을 위키에서 검색해보았지만 여전히 혼란스럽다. 약간의 예제를 줄 수 있을까?

Tony Bako, Mosaic의 CTO의 답변 파티셔닝이란 퍼포먼스(performance), 가용성(availability) 또는 정비용이성(maintainability)를 목적으로 당신의 논리적인 데이터 엘리먼트들을 다수의 엔티티(table)로 쪼개는 행위를 뜻하는 일반적인 용어이다.

샤딩은 수평 파티셔닝(horizontal partitioning)과 동일하다. 데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리한다. 예를 들면, 나는 고객의 데이터베이스를 CustomerId를 샤드키로 사용하여 샤딩하기로 하였다. 0 ~ 10000 번 고객의 정보는 하나의 샤드에 저장하고 10001 ~ 20000 번 고객의 정보는 다른 샤드에 저장하기로 하였다. DBA는 데이터 엑세스 패턴과 저장 공간 이슈(로드의 적절한 분산 , 데이터의 균등한 저장)를 고려하여 적절한 샤드키를 결정하게 된다.

Horizontal Partitioning

수직 파티셔닝(vertical partitioning)은 하나의 엔티티에 저장된 데이터들을 다수의 엔티티들로 분리하는것을 말한다. (마찬가지로 공간이나 퍼포먼스의 이유로) 예를 들면, 한 고객은 하나의 청구 주소를 가지고 있을 수 있다. 그러나 나는 데이터의 유연성을 위해 다른 데이터베이스로 정보를 이동하거나 보안의 이슈등을 이유로 CustomerId를 참조하도록 하고 청구 주소 정보를 다른 테이블로 분리할 수 있다.

Vertical Partitioning

요약하면 파티셔닝은 퍼포먼스, 가용성, 정비용이성등의 목적을 위해 논리적인 엔티티들을 다른 물리적인 엔티티들로 나누는것을 의미하는 일반적인 용어이다. 수평 파티셔닝 또는 샤딩은 스키마 복제 후 샤드키를 기준으로 데이터를 나누는것을 말한다. 수직 파티셔닝은 스키마를 나누고 데이터가 따라 옮겨가는것을 말한다.

• 출처 : http://theeye.pe.kr/archives/1917

AWS kinesis를 보다가 partitioning에 대해서 이해가 부족했다. data용량이 커지면서 성능 문제가 생기게 되는데 이 문제를 해결하는 방법 중 하나로 파티셔닝이라는 용어가 나왔고 이는 database관련 용어였다. 그래서 MongoDB를 기준으로 파티셔닝에 대해 찾아보다가 복제와 수평/수직 파티셔닝 개념과 함께 샤딩 개념도 알게 되었다. 결론적으로 샤딩은 수평 파티셔닝이다.

• 정규화란?
• 함수적 종속성 등의 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한 스키마로 만들어 가는 과정
• 제 1, 2, 3, BCNF, 4, 5 정규형이 있으며, 차수가 높아질수록 만족시켜야 할 제약조건이 늘어남.
• 데이터베이스의 논리적 설계 단계에서 수행
• 논리적 처리 및 품질에 큰 영향을 미침
• 목적
• 데이터 구조의 안정성을 최대화.
• 어떠한 릴레이션이라도 데이터 베이스 내에서 표현 가능하게 만듬.
• 효과적인 검색 알고리즘을 생성 할 수 있음.
• 중복을 배제하여 삽입, 삭제, 갱신 이상의 발생을 방지
• 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄임
• Anomaly(이상)의 개념 및 종류
• 개념 : 정규화를 거치지 않으면 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조직 시 예기치 못한 곤란한 현상이 발생
• 종류 : 
1. 삽입 이상(Insertion Anomaly) : 데이터를 삽입할 때 의도와는 상관없이 원하지 않는 값들로 인해 삽입할 수 없게 되는 현상
2. 삭제 이상(Deletion Anomaly) : 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는, 즉 연쇄 삭제가 발생하는 현상
3. 갱신 이상(Update Anomaly) : 튜플에 있는 속성값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 불일치성(Inconsistency)이 생기는 현상
• 정규화 과정
• 제 1정규형 (1NF) : 릴레이션에 속한 모든 도메인이 원자값만으로 되어 있는 릴레이션
• 제 2정규형 (2NF) : 릴레이션 R이 1NF이고, 키가 아닌 모든 속성이 키본키에 대하여 완전 합수적 종속 관계를 만족함
• 제 3정규형 (3NF) : 릴레이션 R이 2NF이고, 키가 아닌 모든 애트리뷰트가 기본키에 대해 이행적 종속 관계를 이루지 않도록 제한한 관계형
• Boyce-Codd 정규형 (BCNF) : 
• 릴레이션 R에서 결정자가 모두 후보키인 관계형
• 3NF에서 후보키가 많고 서로 중첩되는 경우에 적용하는, 강한 제 3규형이라고도 함
• 키가 아닌 모든 속성은 각 키에 대하여 완전 종속해야 하고, 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대하여 완전 종속해야 함
• 어떤 속성도 키가 아닌 속성에 대해서는 완전 종속할 수 없음
• 제 4정규형 (4NF) : 릴레이션 A -> B가 성립하는 경우 R의 모든 속성이 A에 함수적 종속이면 이 릴레이션 R은 제 4정규형에 속함
• 제 5정규현(5NF / PJ / NF) : 릴레이션 ㄲ의 모든 조인 종속성(JD)의 만속이 R의 후보키를 통해서만 만족 될 때 그 릴레이션은 R은 제 5정규형 또는 PJ / NF에 속함

※ 완전 함수적 종속성  (완전 종속) : 복합키 모두가 함수적 종속성을 가지는 것

   부분 함수적 중속성  (부분 종속) : 복합키 중 하나가 함수적 종속성을 가지는 것

   이행적 함수적 종속성 : A->B 이고 B->C 이면 A->C

※ 정규형 과정 정리

- 출처 : http://blog.naver.com/seong1731/220166773381