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를 기준으로 파티셔닝에 대해 찾아보다가 복제와 수평/수직 파티셔닝 개념과 함께 샤딩 개념도 알게 되었다. 결론적으로 샤딩은 수평 파티셔닝이다.