For job interview, about DB 면접 공부하기-데이터베이스 2

1. Index 인덱스

• Definition 정의 : RDBMS에서 검색 속도를 높이기 위해 사용하는 자료 구조 (B-Tree 구조로 색인)
• Principle 원리 : 초기 테이블 생성시 만들어진 MYI 파일에 해당 컬럼을 색인하고, 검색 시 Tree로 정리해둔 MYI 파일의 내용을 검색한다. 만약 인덱스를 사용하지 않은 쿼리를 날리면, 해당 테이블을 full scan 한다.
• Structure 구조
  • 인덱스 탐색 : Root (Branch에 대한 정보) -> Branch (Leaf에 대한 정보) -> Leaf (데이터의 주소에 대한 정보) -> 디스크 저장소
  • 많은 인덱스로 인해 옵티마이저 Optimizer 가 잘못된 인덱스를 선택할 확률이 높아지므로 인덱스의 개수는 3~4개가 적당하다.
• 인덱스 키 값의 크기 : MySQL은 디스크에 데이터를 저장하는 가장 기본 단위를 페이지라고 하며 16KB로 크기가 고정된다.
• Disadvantages 단점
  • 인덱스의 키가 길 수록 성능 저하
  • 인덱스 된 필드 field 에서 데이터를 업데이트하거나 레코드를 추가/삭제시 성능 저하
  • DB의 10% 내외로 인덱스 공간 필요
• 인덱스 컬럼 기준
  • WHERE절에서 사용되는 / 외래키가 사용되는 / JOIN에 자주 사용되는 / 바뀌지 않을 / 단일보다는 다중 ‘컬럼’
  • 한 개의 컬럼만 인덱스를 걸어야 한다면, 카디널리티 cardinality 가 가장 높은 것을 잡는다. (예. 성별, 학년 x -> 주민등록번호, 계좌번호 o)
  • 여러 개의 컬럼으로 인덱스를 걸어야 한다면, 카디널리티가 높은 순에서 낮은 순으로 구성한다.
  • 단일 컬럼보다는 다중 컬럼
• 인덱스 조회시 주의 사항
  • AND 연산자는 각 조건이 읽어야할 행의 수를 줄이지만, OR 연산자는 비교해야 할 행의 수가 늘어나기 때문에 full table scan 발생 확률이 높아진다.
  • 인덱스로 사용된 컬럼 값을 그대로 사용해야 된다. (가공하거나 연산해서는 안 된다.)
  • NULL을 비교값으로 사용한 경우에는 인덱스를 타지 않는다.
• 해시가 아닌 인덱스 사용 이유 : SELECT 쿼리 조건에 부등호(<, >) 연산도 포함이 되는데, 해시 테이블을 사용하게 되면 등호(=) 연산이 아닐 경우 문제가 발생한다.

@ Optimizer 옵티마이저 :

SQL을 가장 빠르고 효율적으로 수행할 최적의 처리경로를 생성해 주는 DBMS 내부의 핵심 엔진이다. 사용자가 구조화된 질의언어(SQL)로 결과 집합을 요구하면, 이를 생성하는데 필요한 처리경로는 DBMS에 내장된 옵티마이저가 자동으로 생성해준다.

@ Cardinality 카디널리티 :

특정 액세스 단계를 거치고 난 후 출력될 것으로 예상되는 결과 건수를 말한다.

2. Transaction 트랜잭션

• Definition 정의 : 하나의 논리적 작업 단위를 구성하는 일련의 연산들의 집합으로 하나의 트랜잭션은 커밋 commit 되거나 롤백 rollback 된다. 트랜잭션은 일반적으로 회복 recovery (손상되기 이전의 정상 상태로 복구시키는 작업)의 단위가 된다.
• Example 예시 : 한 계좌에서 10만원을 인출하여 다른 계좌로 10만원 입금하는 이체 작업은 전체 작업이 정상적으로 완료되거나, 만약 정상적으로 처리될 수 없는 경우에는 아무 것도 실행되지 않은 처음 상태로 되돌려져야 한다. 이러한 트랜잭션은 다양한 데이터 항목들을 액세스하고 갱신하는 프로그램 수행의 단위가 된다.
• Features 특징
  • Atomicity 원자성 : DBMS는 모든 연산들이 정상적으로 수행 완료되거나 아니면 전혀 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. ‘All or Nothing’
  • Consistency 일관성 : 트랜잭션의 결과가 ‘동시에 모든’ 노드에서 보일 수 있도록 해야 한다. 즉, 트랜잭션이 진행되는 동안에 DB가 변경되더라도 변경된 DB로 트랜잭션을 진행하는 것이 아니라 변경 전 DB를 참조한다.
  • Isolation 독립성 : 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 이러한 독립성이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다. 독립성을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이다. 하지만 병렬적 수행의 장점을 얻기 위해서 DBMS는 병렬적으로 수행하면서도 일렬 수행과 같은 결과를 보장할 수 있는 방식을 제공한다.
  • Durability 지속성 : 트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 프랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다.

@ Commit 커밋 :

트랜잭션에 대한 작업이 성공적으로 끝났고, DB가 다시 일관된 상태에 있을 때 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산

@ Rollback 롤백 :

하나의 트랜잭션 처리가 비정상적으로 종료되어 DB의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(undo)시키는 연산으로, 해당 트랜잭션을 재시작하거나 폐기한다.

3. Transaction Isolation Level 트랜잭션 격리 수준

• Definition 정의 : 트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준
• 종류
  • Read Uncommitted (level 0) : 트랜잭션에 처리중인 혹은 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용한다. 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 아직 완료되지 않은 트랜잭션이지만 변경된 데이터인 B를 읽을 수 있다.
  • Read Committed (level 1) : 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근하지 못하고 대기하게 한다.
  • Repeatable Read (level 2) : 트랜잭션이 범위 내에서 조회한 데이터의 내용이 항상 동일함을 보장한다. 즉, 트랜잭션 내에서 한 번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회 된다.
  • Serializable (level 3) : 가장 엄격한 모드이다.

※ 참고 : https://lalwr.blogspot.com/2016/02/db-index.html, https://d2.naver.com/helloworld/407507, http://www.dbguide.net/db.db?cmd=view&boardUid=148218&boardConfigUid=9&boardIdx=139&boardStep=1, http://www.mybatis.org/mybatis-3/ko/index.html, https://3months.tistory.com/193, https://github.com/WeareSoft/tech-interview/blob/master/contents/db.md#%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B2%A9%EB%A6%AC-%EC%88%98%EC%A4%80