CS 정리 - 13

유호준·2023년 6월 21일
0

CS 정리

목록 보기
12/12

Key (기본키, 후보키, 슈퍼키 등등...) 에 대해 설명해 주세요.

키란 데이터의 식별자의 역할을 하는 것을 의미한다.

기본키

  • 후보키들 중에 하나를 선택한 키로 최소성과 유일성을 만족
  • NULL을 가질 수 없다
  • 오직 한개
  • 중복되어서도 안된다.

슈퍼키

  • 각 행을 유일하게 식별할 수 있는 하나 혹은 그 이상의 속성들의 집합
  • 유일성을 만족한다.

후보키

  • 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합

대체키

  • 후보키가 두개 이상일 경우 그 중에서 기본키로 지정하고 남은 후보키

외래키

  • 다른 테이블의 데이터를 참조할 때 사용하는 키
  • 참조될 테이블에서 기본키로 설정되어 있어야 한다.

기본키는 수정이 가능한가요?

수정은 가능하나 unique한 값이여야 한다.

사실 MySQL의 경우, 기본키를 설정하지 않아도 테이블이 만들어집니다. 어떻게 이게 가능한 걸까요?

사용자에게는 보이지 않아도 그 값을 생성한다.

외래키 값은 NULL이 들어올 수 있나요?

NULL을 허용할 수 있으며 이 경우에는 NULL이 입력될 수 있다

어떤 칼럼의 정의에 UNIQUE 키워드가 붙는다고 가정해 봅시다. 이 칼럼을 활용한 쿼리의 성능은 그렇지 않은 것과 비교해서 어떻게 다를까요?

  • Unique index : 중복을 허용하지 않기 때문에 하나의 index를 찾았을 때 더 이상 찾지 않아도 된다는 의미를 제공하게 되어 이를 통해 최적화를 수행하게 된다.

RDB와 NoSQL의 차이에 대해 설명해 주세요.

RDB

  • 엄격한 데이터 구조
  • 데이터 중복 없이 한번만 저장(무결성)
  • 데이터의 분류, 정렬, 탐색 속도가 비교적 빠름
  • 데이터의 업데이트가 빠름
  • 시스템이 커지면 쿼리가 복잡해짐
  • 수평적 확장이 까다로움

NoSQL

  • 유연한 데이터 구조
  • 새로운 필드 추가 자유로움
  • 데이터 중복 발생 가능
  • 데이터 변경 시 모든 컬렉션에서 수정 필요

NoSQL의 강점과, 약점이 무엇인가요?

강점

  • 유연한 데이터 구조로 인해 새로운 필드 추가가 자유롭다
  • 데이터 분산이 용이하며 성능향상을 위한 Scale-up,Scale-out 또한 가능하다

    Scale-up, Scale-out

단점

  • 데이터 중복이 발생할 수 있으며 수정이 발생할 경우 모든 컬렉션에서 수행해야함
  • 데이터 구조 결정이 어려울 수 있다.
  • ACID(원자성, 일관성, 격리성, 내구성)을 지원하지 않는다.

RDB의 어떠한 특징 때문에 NoSQL에 비해 부하가 많이 걸릴 수 있을까요?

RDB는 테이블 간의 관계를 맺고 있어 이로인해 JOIN문을 필요로 한다. 이때 JOIN문이 많아지게 되면 여럿 테이블을 조회해야해 많은 부하가 걸릴 수 있다.

트랜잭션이 무엇이고, ACID 원칙에 대해 설명해 주세요.

트랜잭션

  • 한 단위의 작업으로 취급되는 모든 작업

ACID 원칙

  • 원자성 : 트랜잭션에 속한 각각의 문을 하나의 단위로 취급한다. 전체를 실행하거나 어떤 부분도 실행하지 않거나 둘중 하나이다.
  • 일관성 : 트랜잭션을 통해 데이터베이스의 일관성이 유지되어야 한다.
  • 격리 : 여러 사용자가 같은 테이블에서 모두 동시에 일고 쓰기 작업을 할 때, 각각의 트랜잭션을 격리하면 동시 트랜잭션이 서로 방해하거나 영향을 미치지 않는다.
  • 영속성 : 트랜잭션 실행으로 인해 데이터에 적용된 변경 사항이 저장되도록 보장한다.시스템 오류가 발생해도 마찬가지이다.

ACID 원칙 중, Durability를 DBMS는 어떻게 보장하나요?

Level 2

  • 메모리 로그버퍼에 기록하고 로그버퍼에 있는 로그파일에 직접 flush
  • 정전이나 비정상 종료시에는 디스크에 반영하는 것을 보장하지 않음

Level 3

  • 운영체제 로그버퍼를 활용
  • 프로세스 비정상 종료를 하더라도 운영체제에 반영하므로 정전이 아닌 경우는 완벽히 지원
  • 운영체제를 거쳐야 하므로 트랜잭션 처리 성능이 떨어질 수 있다.

Level 4

  • 메모리 로그 버퍼에 기록하고 해당 로그를 커널에 있는 로그버퍼에 직접 반영
  • 커밋 시 커밋된 로그가 로그파일까지 반영됨을 보장하지 않아 2,3 레벨 중간정도의 안정성을 지원하면서 2레벨의 성능을 낼 수 있다.

Level 5

  • 로그를 메모리에 기록하고 로그버퍼에 있는 로그를 로그파일에 직접 내려주거나 각 트랜잭션이 직접 커밋 로그를 로그파일까지 반영하는 방식으로 모든 로그가 로그 파일에 반영됨을 보장하기 때문에 어떠한 시스템 장애 상황에서도 완벽하게 보장
  • 커밋된 로그가 바로 로그파일에 반영되기까지 기다려야되기 때문에 성능이 가장 좋지 않음

트랜잭션을 사용해 본 경험이 있나요? 어떤 경우에 사용할 수 있나요?

  • 작업이 한번에 반영되야되는 것을 보장해야 할 때
  • 예 : 은행 이체
    - 이체 시 내 통장에서 돈이 빠져나가고 상대 통장에 돈이 입금됨을 보장해야 함

읽기에는 트랜잭션을 걸지 않아도 될까요?

트랜잭션을 걸지 않을 떄

  1. Dirty Read
  • 수정 중이고 커밋되지 않은 데이터를 다른 트랜잭션에서 읽게 되어 일관성에 어긋난낟.
  1. Non-Repeatable Read
  • 한 트랜잭션 내에서 같은 쿼리를 두번 수행할 때 그 사이에서 다른 트랜잭션이 수정 또는 삭제해서 둘의 결과가 다르게 나타나는 현상이 발생할 수 있음
  1. Phantom Read
  • 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽을 때 첫 번째 쿼리에서 없던 유령 레코드가 두 번째 쿼리에서 나타나는 현상

트랜잭션 격리 레벨에 대해 설명해 주세요

  1. Read Uncommitted
    아예 격리가 되지 않는 레벨
  2. Read committed
    커밋된 데이터만 읽는 것을 허용
  3. Repeatable Read
    선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때 까지 후행 트랜잭션이 갱신하거나 삭제하는 것을 불허
  4. Serializable
    선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때 까지 후행 트랜잭션이 갱신하거나 삭제하는 것을 불허하는 것 뿐만 아니라 새로운 레코드를 삽입하는 것을 막아 완변한 읽기 일관성을 보장한다.

모든 DBMS가 4개의 레벨을 모두 구현하고 있나요? 그렇지 않다면 그 이유는 무엇일까요?

아니요, Read Uncommited 레벨과 같은 경우 거의 필요 없음, Repeatable Read은 오라클의 경우 다중 버전 기반의 읽기 일관성 매커니즘에 의해 Serializable이 효과적으로 지원되어 포함되지 않았다.

다중 버전 읽기 일관성

  • 데이터를 읽을 때 록에 의해 록이 풀리기를 기다리는 것이 아니라 이전 버전의 정보를 읽음으로서 쓰기 트랜잭션이 읽기 작업을 막지 않는다.

Undo 영역과 Redo 영역에 대해 설명해 주세요.

Redo Log

  • DB 장애시 복구에 사용되는 로그
  • Buffer Pool에 저장되어있던 데이터의 유실을 방지하기 위해 사용된다.
  • 데이터 변경시에 대한 모든것을 기록한다.

Undo Log

  • 실행 취소 로그 레코드의 집합으로 롤백시 이전데이터로 복구할 수 있도록 해놓은 영역
  • 변경되기 전의 데이터와 PK값을 저장

스토리지 엔진이 정확히 무엇을 하는 건가요?

  • 데이터베이스에 대해 삽입, 추출, 업데이트 및 삭제하는 데 사용하는 기본 소프트웨어 컴포넌트

인덱스가 무엇이고, 언제 사용하는지 설명해 주세요.

  • RDB에서 검색 속도를 높이기 위해 사용하는 기술
  • 컬럼에 대해 색인을 부여해 빠르게 검색이 가능하다
  • 컬럼의 데이터를 정렬한 후 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장
  • 규모가 큰 테이블, 수정이 적은 컬럼, 조회가 잦은 컬럼이 효율적이다.

일반적으로 인덱스는 수정이 잦은 테이블에선 사용하지 않기를 권합니다. 왜 그럴까요?

인덱스를 항상 정렬된 상태로 유지해야 하기 때문에 수정을 할경우 인덱스를 추가하거나 인덱스를 사용하지 않는다는 처리 등의 추가적인 작업이 필요하기 떄문에 성능이 낮아진다.

앞 꼬리질문에 대해, 그렇다면 인덱스에서 사용하지 않겠다고 선택한 값은 위 정책을 그대로 따라가나요?

ORDER BY/GROUP BY 연산의 동작 과정을 인덱스의 존재여부와 연관지어서 설명해 주세요.

Order BY

  • 인덱스 존재: 처리가 필요 없음
  • 인덱스 존재 X:레코드를 읽어온 후 메모리 공간을 이용해 정렬

Group BU

  • 인덱스 존재: 인덱스를 이용해 스캔

기본키는 인덱스라고 할 수 있을까요? 그렇지 않다면, 인덱스와 기본키는 어떤 차이가 있나요?

  • 기본키는 자동으로 인덱스가 적용된다.
  • 기본키는 물리적으로 저장되지 않는다.
  • index는 데이터의 일관성을 보장하지 않는다.

외래키는?

  • DB에 따라 다름, innoDB인경우 생성

참고자료

profile
유호준
포트폴리오 - https://drive.google.com/file/d/152OM9p7JQorjUfvR4BaxqGuP5xtQ8-fM/view?usp=sharing
이전 포스트

CS 정리-1

0개의 댓글