database.md

💾 Database 면접 예상 질문

Database

데이터베이스를 사용하는 이유가 무엇이나요?

데이터베이스를 사용하기 전에는 파일 시스템을 이용하여 데이터 관리를 했습니다.

파일 시스템은 응용 프로그램마다 하나의 독립된 데이터 파일을 사용합니다. 그렇기 때문에 한 시스템 내에 데이터가 중복 저장되는 문제가 발생합니다. 또한 응용 프로그램과 데이터 파일의 상호 의존 관계를 갖기 때문에 데이터 파일의 구조가 변경되면 응용 프로그램의 구조 또한 변경해야합니다.

한 시스템에 데이터가 중복 저장되는 파일 시스템은 여러 문제를 야기하는데요. 먼저 하나의 사실만을 나타내도록 일관성을 유지하기 어렵습니다. 그리고 중복 데이터들에 같은 수준의 보안을 유지하기 힘듭니다. 또한 하나의 데이터 파일을 여러 응용 프로그램이 사용하는 상황에서 한 응용 프로그램이 해당 데이터 파일을 사용하고 있다면, 다른 프로그램은 접근하지 못합니다.

위와 같은 파일 시스템의 문제로 여러 응용 프로그램이 특정 데이터를 공유하고, 최소한의 중복으로 저장된 데이터의 집합인 “데이터베이스”가 등장했습니다.

데이터베이스 키의 종류와 기능에 대해 설명해주세요

데이터베이스에서 키란 검색이나 정렬시에 튜플을 구분할 수 있는 어트리뷰트입니다.

키의 종류에는 슈퍼키, 후보키, 기본키, 대체키, 복합키, 외래키가 있습니다.

1. 슈퍼키는 유일성을 만족하는 어트리뷰트입니다. 유일성을 가진 어트리뷰트는 모든 레코드에서 중복된 값이 없는 어트리뷰트입니다.
2. 후보키는 유일성과 최소성을 만족하는 어트리뷰트입니다. 최소한의 어트리뷰트들로 레코드를 유일하게 구별할 수 있는 속성을 최소성이라고 합니다.
3. 기본키는 유일성과 최소성을 가지며 NULL 값을 가지지 못하는 어트리뷰트입니다. 후보키 가운데 선택된 어트리뷰트라고 할 수 있습니다.
4. 대체키는 후보키 중에서 기본키로 선택된 것들을 제외한 모든 키를 말합니다.
5. 복합키는 한 개 이상의 속성을 포함하는 키를 말합니다.
6. 외래키는 한 테이블에서 다른 테이블의 레코드(튜플)을 참조하기 위해 사용되는 키입니다.

[정리]

• 슈퍼키 = 유일성 만족하는 키
  • 후보키 = 슈퍼키 + 최소성 만족하는 키
    • 기본키 = 후보키 중 선택된 키 = 유일성 + 최소성 + not null = 특정 레코드 구분가능
      • 대체키 = 후보키 - 기본키 = 나머지 키들
• 복합키 = 1 이상의 속성으로 이뤄진 키 = {속성1, .. }
• 외래키 = 다른 테이블의 레코드를 참조하는 키

순차 I/O와 랜덤 I/O에 대해 설명해주세요

순차 io 란 물리적으로 인접한 데이터를 차례대로 읽는 방식입니다. 따라서 랜덤 io에 비해 큰 처리량을 갖습니다. 순차 io 방식으로 원하는 데이터를 찾기 위해선 full scan을 해야합니다.

랜덤 io란 디스크의 여러 부분에 흩어져 있는 데이터를 읽는 방식입니다. 인접하지 않는 데이터를 읽기 때문에 디스크 헤드가 무작위로 움직입니다. 이는 결국 성능 저하를 야기합니다.

서버 기반의 환경에서는 모든 io를 순차 io로 수행하는것이 불가능합니다. 따라서 하나의 디스크에 여러 데이터를 저장하는 것 보다 여러 디스크에 적은 데이터를 매핑하여 랜덤 엑세스가 최소화 되도록 하는 대응 방식이 있습니다.

DB Clustering&replication

Clustering이 무엇인가요?

데이터베이스 서버에 문제가 발생할 경우에 대비하기 위해 데이터베이스 서버를 여러대로 나누는 기법입니다.

1. active - active 방식으로 여러 대로 나누는 서버를 동작 상태로 두는 방식이 있습니다.

   이 방식은 무중단 서비스를 제공할 수 있습니다. 또한 서버 2대가 운영되기 때문에 리소스를 많이 사용하지만 성능적인 측면에 이득이 있습니다.

   하지만 여러 서버가 하나의 저장소에 접근하기 때문에 병목현상이 발생한다는 문제가 있습니다.

2. active -standby 방식이 있습니다.

   하나의 서버만 운용하고 나머지는 standby로 두는 방식입니다.

   따라서 active-active 방식에서 나타나는 병목 현상이 없지만, standby에서 active로 전환하는데 시간이 오래 걸린다는 단점이 있습니다.

Replication이 무엇인가요?

저장된 데이터 손실문제를 해결하기 위해 여러 데이터베이스에 원본 데이터를 복제하는 기법입니다.

원본 데이터를 저장하는 데이터베이스를 primary db라 칭하고 복제 데이터를 백업할 용도의 데이터를 secondary db라고 합니다.

사용자가 crud 요청을 primary db로 보내면 변경된 데이터를 secondary db에 동기화하면서 데이터 일관성을 유지합니다.

또한 secondary db는 백업용도 외에 조회 용도로도 사용할 수 있기 때문에 부하를 분산시킬 수 있습니다.

replication 을 사용하는 이유는

1. 데이터 유실을 막기 위해 사용합니다
2. 또한 primary db가 문제가 생길 경우, secondary db가 그 역할을 대신할 수 있기 때문에 장애 대응을 할 수 있습니다.
3. 여러대의 데이터베이스를 사용하기 때문에 물리적인 거리 차이로 인한 응답 지연 시간을 줄일 수 있습니다.

replication은 primary db에서 secondary db로 데이터를 동기화하는 작업이 필요합니다. 이 때 걸리는 시간을 replication lag이라고 칭합니다.

replica가 많으면 replication lag 시간이 길어지기 때문에, 시간차로 primary db와 secondary db에 동일 데이터를 조회할 경우 결과가 상이할 수 있기 때문에 데이터 일관성을 100% 지키지 못합니다.

Partitioning이 무엇인가요?

하나의 큰 테이블을 파티션이라는 작은 단위로 나누는 기법입니다.

데이터의 규모가 커지면서 하나의 데이터베이스에 용량이 큰 테이블이 존재하면 성능 이슈가 발생합니다. 이에 대응하기 위해 큰 테이블을 작은 테이블로 작게 쪼개는 파티셔닝 기법이 등장했습니다.

파티셔닝을 하면, full scan 시 탐색 범위를 줄여 성능을 향상시킬 수있습니다.

또한 테이블을 물리적으로 쪼개기 때문에 전체 데이터의 훼손 가능성을 줄여줍니다.

다만 join연산에 대한 비용이 증가한다는 단점이 있습니다.

파티셔닝에는 vertical partitioning, horizontal partitioning 이 있습니다.

1. 수직 파티셔닝이란 용량이 큰 데이터나 민감한 데이터를 담는 attritbute를 독립적인 테이블로 나누는 작업입니다.
2. 수평 파티셔닝이란 스키마가 동일한 테이블을 나누어 저장하는 것을 말합니다. 즉, 스키마가 동일한 테이블이 두개 생기는 것입니다. 이는 sharding과 동일한 개념으로 여길 수 있습니다.

Sharding이 무엇인가요?

테이블을 행 단위로 나누어서 여러 샤드에 저장하는 방식입니다. 샤드란 샤딩을 통해 나누어진 블록 구간을 말합니다.

이후에 샤드 키를 통해 샤드를 선택하여 데이터를 저장합니다.

샤드를 선택하는 방식은 hash sharding, dynamic sharding, entity group이 있습니다.

해시 샤딩은 해시 함수를 이용하여 데이터를 저장할 샤드를 고르는 방식입니다. 구현이 쉽지만 샤드를 확장할 경우 바람직하지 않는 방법입니다. (해시 함수가 변하여 기존 방식과 다른 저장 방식을 갖게 됩니다)

해시 샤딩의 확장성 문제를 해결하기 위해 다이나믹 샤딩 방식이 등장했습니다. locator service라는 테이블 정보 기반으로 샤드 키를 결정하기 때문에 샤드 확장에 문제가 없습니다.

다만 locator service가 유실되면 샤드를 고르는데 문제가 발생합니다.

이 두 샤딩 방식은 key-value 쌍의 데이터를 저장하는 NoSQL 데이터베이스에 적합합니다.

데이터간에 관계를 맺는 관계형 데이터베이스에 적합한 샤딩 방식에는 엔티티 그룹이 있습니다. 하나의 샤드 속에 연관된 데이터만 모아두기 때문에 쿼리가 효율적이지만 다른 샤드 내의 엔티티와 연관된 데이터를 조회할 경우 비효율적입니다.

SQL

SQL injection 공격 방식에는 무엇이 있나요?

sql injection 공격 방식에는 두 가지가 존재합니다. 첫 번째는 인증 우회 두 번째는 데이터 노출이 있습니다.

인증 우회는 쿼리를 요청할 때 특정 조건문을 항상 true로 반환하게 쿼리문을 조작하여 보내서 비정상적인 동작을 하도록 조작하는 공격방식입니다.

데이터 노출은 시스템에서 발생하는 에러 메시지를 이용해 공격하는 방법이다. 보통 에러는 개발자가 버그를 수정하는 면에서 도움을 받을 수 있는 존재인데, 해커들은 이를 역이용해 악의적인 구문을 삽입하여 에러를 유발시킨다.

injection을 방어하기 위한 방법은 어떤게 있나요?

첫 번째로 input값을 받을 시에 특수문자 검사를 진행하는 것 입니다. 로그인 시에 검증 로직을 추가하여 특수문자가 포함되어 있을 시에 요청을 거부하는 방식입니다. 두 번째는 sql 서버 오류시 오류메시지를 감추는 방식입니다. view를 활용해서 사용자가 오류 발생시 메시지를 확인 할 수 없게하여 데이터 노출을 방지합니다. 마지막으로 prepare statement를 이용하는 방법이 있습니다. prepare statement는 서버 측에서 필터링 과정을 거쳐 특수문자를 escaping하는 방식입니다. 이를 통해서 인증 공격을 방지할 수 있습니다.

Join에서 left join과 right join의 차이점은 무엇인가요?

left join은 a, b 집합이 있을 때, 조인을 진행한후에 교집합을 포함하여 오른쪽테이블에서 null값을 포함하여 결과를 반환하지만, right join은 기준테이블의 오른쪽으로 join하여 데이터를 조회하기때문에 join의 결과 값중에서 왼쪽 데이터가 널인 결과 값도 함께 반환합니다.

SQL 문법 종류와 예시를 들어주세요

DDL은 (data definition Language) 데이터 정의 언어입니다. 각 릴레이션을 정의하기 위해 존재합니다. alter, drop create table로 릴레이션을 삭제, 생성 및 릴레이션 전환을 합니다. DML은 데이터 조작 언어로 insert, select update가 있고 데이터를 관리하며 각 테이블을 조회 삽입, 갱신합니다. 마지막으로 DCL은 데이터 제어 언어로 사용자별로 데이터의 권한을 다루기 위한 언어로 revoke grant가 있습니다.

RDBMSvs.NoSQL

NOSQL은 무엇이고 어떤 특징이 있나요?

NoSQL은 Not Only SQL의 약자로 관계형 데이터베이스와는 다르게 데이터, 테이블간의 관계를 정의하지 않습니다. 정해진 스키마가 없기때문에 보다 자유롭게 데이터를 저장할 수 있습니다. 그리고 여러대의 서버에 데이터를 분산하여 저장할 수 있어 대용량 데이터 처리가 가능하고 분산시 데이터를 상호복제하여 특정 서버에 장애가 생겼을 때에도 데이터 유실이나 무중단 서비스를 운영할 수 있습니다.

RDBMS와 NOSQL의 차이점은 무엇인가요?

NoSQL이 RDB와 다른 점은 스키마가 없다는 것입니다. 즉 데이터 관계와 정해진 규격(table-column의 정의)이 없습니다. 또한 NoSQL은 분산처리(수평적 확장)의 기능을 쉽게 제공합니다. 하지만 NoSQL은 관계 정의가 없어 Join이 불가능합니다. 또한 트랜잭션을 지원하지 않습니다.

--RDBMS vs NoSQL (장단점)-- RDBMS는 관계형 데이터베이스로 테이블간의 관계를 형성합니다. 그리고 정해진 스키마에 따라 테이블에 저장하여 데이터 무결성을 보장합니다. 하지만 스키마에 맞지않는 데이터는 추가할 수 없고 추가하려면 테이블을 변경하거나 새로운 테이블을 만들어야합니다. 관계를 맺고있기 때문에 join문이 많은 복잡한 쿼리문이 만들어질 수 있습니다. 대체로 scale out 방식보다는 scale up 만이 가능합니다.

NOSQL은 스키마가 없어 유연하게 데이터를 조정하고 추가할수 있습니다. 테이블 간의 관계를 정의하지 않아 join이 필요없고 쿼리 로직의 복잡도가 낮은 장점이 있습니다. 또한 RDBMS보다 복잡도가 떨어져 대용량의 데이터를 저장, 관리 할 수 있고, scale out이 가능합니다. 하지만 데이터의 일관성이 항상 보장되지 않고, 중복으로 저장된 데이터가 있을 수 있습니다. 따라서 UPDATE시 중복으로 저장된 데이터를 똑같이 업데이트 해주는데 시간이 소요됩니다. 그리고 유연성으로 인해 데이터 구조 결정을 미루게 될 수도 있습니다.

NOSQL의 데이터 저장 방식에는 무엇이 있나요?

비관계형 모델을 이용한 데이터 저장 방식에는 key-value 방식, document 방식, column model 방식, graph 방식이 있습니다.

• Key-Value 방식 가장 기본적인 형태의 NoSQL로 키를 고유한 식별자로 키-값 쌍으로 데이터를 저장합니다. Redis, Riak에서 사용합니다.

• Document 방식 key-value 모델을 확장한 구조로 하나의 키에 하나의 구조화된 문서를 저장하고 조회합니다. 저장된 문서를 컬렉션으로 관리하며 문서 저장과 동시에 문서 ID에 대한 인덕스를 생성합니다. 문서 ID에 대한 인덱스를 사용하여 O(1) 시간 안에 문서를 조회할 수 있습니다. XML, JSON, YAML 같은 데이터 타입(document)을 이용해서 레코드를 저장합니다. 대부분의 문서 모델은 b트리 인덱스를 사용하여 2차 인덱스를 생성합니다. b트리는 크기가 커질 수록 새로운 데이터를 입력하거나 삭제할 때 성능이 떨어지므로 읽기와 쓰기 비율이 7:3 정도일때 좋은 성능을 보입니다. mongoDB, couchDB에서 사용합니다.

• Column Model 방식 하나의 키에 여러 개의 칼럼 이름과 칼럼 값의 쌍으로 이루어진 데이터를 저장하고 조회합니다. 저장의 기본 단위는 칼럼으로 칼럼은 '칼럼 이름', '칼럼 값', 타임스탬프'로 구성됩니다. 보통의 NoSQL은 order by 같은 정렬 기능을 제공하지 않지만, 이 모델은 내부적으로 Row Key또는 Column Key로 자동정렬이 가능합니다. 구글의 Big Table이 대표적인 예입니다.

• Graph 방식 그래프 데이터베이스는 노드를 사용하여 데이터 엔터티를 저장하고 엣지로는 엔터티 간의 관계를 저장합니다. 데이터뿐만 아니라 데이터 간 관계도 데이터 취급합니다. 데이터들의 관계를 중요시해서 저장된 데이터들이 엣지로 직접 연결될 수 있어 데이터 질의 시 특정 노드와 관련된 데이터를 한번의 OP로 획득가능합니다. 고도로 연결된 데이터 세트를 사용하는 애플리케이션을 쉽게 구축하고 실행하는데 유리합니다. Neo4j, Giraph, IBM DB2에서 사용합니다.

ElasticSearch

Elasticsearch란?

Elasticsearch는 Apache Lucene(아파치 루씬) 기반의 Java 오픈 소스 분산 검색 엔진입니다. Elasticsearch를 통해 방대한 양의 데이터를 신속하게(거의 실시간) 저장, 검색, 분석을 수행할 수 있습니다.

Elasticsearch는 언제 사용하는가?

Elasticsearch는 검색을 위해 단독으로 사용되기도 하며, ELK(Elasticsearch / Logstash / Kibana) 스택/ Elastic 스택 으로 사용되기도 합니다.

ELK/Elastic Stack를 왜 사용하는가?

주로 ELK/Elastic Stack는 로드밸런싱되어 있는 WAS의 흩어져 있는 로그를 한 곳으로 모으고, 원하는 데이터를 빠르게 검색한 뒤 시각화하여 모니터링하기 위해 사용합니다.

Elasticsearch의 구조를 설명하라.

Elasticsearch는 클러스터로 구성되며, 클러스터 안에 노드, 노드 안에 인덱스, 인덱스 안에 샤드, 샤드 안에 세그먼트로 구성되어있습니다.

Elasticsearch는 왜 검색 속도가 빠른가?

Inverted-index 자료 구조로 인해 빠릅니다. 단어 기반으로 데이터를 저장하는 ElasticSearch는 특정 단어가 어디에 저장되어있는지 이미 알고 있어 모든 도큐먼트를 검색할 필요가 없습니다.

Elasticsearch의 장/단점은?

ElasticSearch의 장점은 * Scale out (분산/확장성) * 엘라스틱서치에서는 인덱스를 여러 샤드로 나누어 저장하기 때문에 콘텐츠 볼륨의 수평 분할/확장이 가능하고, 작업을 여러 샤드에서 수행하기 때문에(병렬화) 성능/처리량을 늘릴 수 있습니다. * 노드(Elasticsearch 서버)를 수평적으로 늘릴 수 있게 설계되어 있기 때문에 더 많은 용량이 필요한 경우 노드를 클러스터에 추가할 수 있습니다. * 고가용성 * Replica를 통해 데이터의 안전성을 보장합니다. * Schema Free * Json 문서를 통해 데이터 검색을 수행하므로 스키마 개념이 없습니다. 따라서 정형화 되지 않은 문서도 색인하고 검색할 수 있습니다. * Restful * 데이터 CRUD 작업은 HTTP Restful API를 통해 수행한다. * SELECT = GET * INSERT = PUT * UPDATE = POST * DELETE = DELETE * Restful API를 사용한다는 것은 다양한 플랫폼에서 응용이 가능하다는 장점이 있습니다. * Inverted Index * 역색인 인덱스를 사용하여 빠른 검색이 가능합니다.

단점

• 실시간 처리가 불가능하다.
  • elasticsearch는 인메모리 버퍼를 사용하므로 쓰기와 동시에 읽기 작업을 할 경우, 세그먼트가 생성되기 전까지는 해당 데이터를 검색할 수 없습니다.
• 트랜잭션을 지원하지 않는다.
  • 분산 시스템 구성의 특징 때문에 시스템적으로 비용 소모가 큰 트랜잭션 및 롤백을 지원하지 않습니다.
• 진정한 의미의 업데이트를 지원하지 않는다.
  • 세그먼트는 불면의 성질을 가지고 있기 때문에
  • 세그먼트에서 데이터가 삭제될 경우 Soft-Delete를 한다. (삭제 flag = true)
  • 세그먼트에서 데이터가 수정될 경우 Soft-Delete를 하고, 수정된 데이터를 새로운 세그먼트로 생성한다.
  • 따라서 필요없어진 데이터를 정리하고 새로운 세그먼트로 병합 한 후 세그먼트를 삭제하며 디스크에서 완전히 삭제되는 '세그먼트 병합 과정'이 필요합니다.
• Document간의 join을 수행할 수 없다.
  • 두 번의 쿼리로 해결은 가능

DB 교착상태 & 동시성 제어

잠금기법(Locking)에 대해 설명하시오.

잠금기법은 대표적인 동시성 제어 기법입니다. 잠금은 하나의 트랜잭션이 실행하는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 Mutual Excusive 기능을 제공하는 기법입니다. 하나의 트랜잭션이 데이터 항목에 대하여 잠금을 설정하면, 잠금을 설정한 트랜잭션이 해제할 때까지 데이터를 독점적으로 사용할 수 있습니다. 잠금 연산은 데이터에 대한 연산의 성격에 따라 공유잠금(Shared lock)과 배타잠금(Exclusive lock)으로 나눌 수 있습니다. 두 잠금 모두 해제할 경우에는 unlock 연산을 이용합니다. 먼저 공유잠금을 설정한 트랜잭션은 데이터 항목에 대해 읽기 연산(read)만 가능합니다. 또 다른 트랜잭션도 읽기 연산만을 실행할 수 있습니다. 그리고 하나의 데이터 항목에 대해 여러 개의 공유잠금이 가능합니다. 그에 반해 배타잠금을 설정한 트랜잭션은 데이터 항목에 대해서 읽기 연산과 쓰기 연산(write) 모두 가능하고 동시에 여러 개의 배타잠금은 불가능합니다. 그리고 하나의 데이터 항목에 대해서는 하나의 배타잠금만 가능합니다.

잠금기법의 문제점이 뭔가요?

말씀드린 잠금으로는 직렬 가능한 스케줄이 항상 보장되지 않습니다. 그래서 2단계 잠금 규약(2-Phase Locking protocol)으로 이 부분을 해결할 수 있지만 해당 방법으로도 교착상태(Deadlock)는 발생할 수 있습니다.

교착상태(DeadLock)란 무엇인가요?

데이터베이스에서 교착 상태란 여러 개의 트랜잭션들이 실행을 하지 못하고 서로 무한정 기다리는 상태를 의미합니다. 데드락이 발생하기 위한 조건은 크게 4가지로 말할 수 있습니다.

상호 배제: 한 번에 프로세스 하나만 해당 자원을 사용할 수 있다. 사용 중인 자원을 다른 프로세스가 사용하려면 요청한 자원이 해제될 때까지 기다려야 한다.

점유 대기: 자원을 최소한 하나 보유하고, 다른 프로세스에 할당된 자원을 점유하기 위해 대기하는 프로세스가 존재해야 한다.

비선점: 이미 할당된 자원을 강제로 빼앗을 수 없다.

순환 대기: 대기 프로세스의 집합이 순환 형태로 자원을 대기하고 있어야 한다.

예를 들어 트랜잭션 A는 1번 데이터에 대한 UPDATE를 하고 트랜잭션 B는 2번 데이터에 대한 UPDATE 작업을 하고 있다고 가정하겠습니다. 그럼 1번 데이터는 트랜잭션 A가, 2번 데이터는 트랜잭션 B가 LOCK을 하고 있는 상태입니다. 두 트랜잭션 모두 끝나지 않은 상태에서 A가 2번 데이터에 UPDATE를 시도하고 트랜잭션 B가 1번 데이터를 UPDATE 하려고 하면 두 개의 트랜잭션 모두 실행시키지 못하고 교착상태에 빠지게 됩니다.

교착상태의 빈도를 낮추는 방법에는 무엇이 있나요?

교착 상태를 해결하는 방법은 먼저 각 트랜잭션이 실행되기 전에 필요한 데이터를 모두 Locking 해주는 것입니다. 하지만 이 방법에서는 데이터가 많이 필요하면 사실상 모든 데이터를 전부 Locking 해줘야 하므로 트랜잭션의 병행성을 보장하지 못합니다. 뿐만 아니라 몇몇 트랜잭션은 계속해서 처리를 못하게 되는 starvation 문제가 발생할 수 있습니다. 그래서 이러한 단점들 때문에 실제로 자원을 할당할 때 시간 스탬프를 사용하여 교착상태가 일어나지 않도록 회피하는 방법이 많이 사용됩니다.

Transaction

트랜잭션 격리 수준은 무엇인가요? 격리 수준의 종류를 설명해주세요

격리수준은 데이터의 동시성과 일관성이 tradeoff 관계를 가지기 때문에 각각의 레벨마다의 특징적으로 구분하여 필요에 맞게 사용할 수 있도록 합니다.

레벨은 0부터 3까지 있고, read uncommitted, read committed, repeatable read, serializable 이렇게 4가지 레벨이 있습니다.

read uncommitted 레벨은 commit되지 않은 읽기를 허용하는 방식으로 데이터의 read lock이 걸리지 않습니다. 따라서 데이터베이스의 일관성을 유지할 수 없습니다. dirty read가 발생합니다.

read committed는 select 문장이 수행되는 동안 해당 데이터에 shared lock(read lock)이 걸리는 계츠응로 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기합니다. 커밋된 정보만을 읽지만 non-repeatable read가 발생합니다.

repeatable read는 트랜잭션이 완료될 때까지 select 문장이 사용되는 모든 데이터에 shared lock이 걸리는 계층으로 데이터의 일관성이 보장됩니다. Non repeatble read 부정합이 발생하지 않지만 phantom read가 발생합니다.

격리 수준의 종류에 따른 오류를 말하고 오류를 설명하시오

dirty read, unrepeatble read, phantom read

dirty read는 commit되지 않은 트랜잭션의 결과를 읽어오는 것이다. - uncommitted read

unrepeatable read는 트랜잭션이 커밋된 읽기를 하여 데이터가 수정되기 전과 수정 된 후에 쿼리 결과가 달라지는 것을 의미한다. - commited read

phantom read는 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 나타나는 현상으로 트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 일어난다. non-repeatable read 부장합이 발생하지 않습니다.

마지막으로 serializable은 트랜잭션이 완료 될 때까지 select 문장이 상용되는 모든 데이터에 shared lock이 걸리는 계층으로 완벽한 읽기 일관성 모드를 제공하지만, 동시성은 제공되지 안씁니다. 트랜잭션 영역에 해당되는 데이터에 대한 수정과 입력 모두 불가능합니다.

Transaction이란 무엇인가요?

트랜잭션이란 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업의 단위라고 할 수 있고 트랜잭션에는 여러개의 연산이 수행될 수 있다.

→ 사용하는 이유 ⇒ 데이터의 부정합이 일어났을 경우 롤백을 통하여 데이터의 부정합을 방지하기 위해서이다.

Transaction에 특성이 있는데 각각을 설명해주세요

Atomicity - 트랜잭션이 데이터베이스에 모두 반영되거나 전혀 반영되지 않아야 한다.

Consistency - 트랜잭션의 작업 처리 결과는 항상 일관성 있다

Isolation- 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 떄, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.

Durability - 트랜잭션이 성공적으로 완료되었다면 결과는 영구적으로 반영되어야한다.

Redis

Redis는 어떤 경우에 사용할까요?

운영 중인 서버에서 키-값 형태의 데이터 타입을 처리해야하고, I/O가 빈번히 발생해 다른 저장 방식을 사용하면 효율이 떨어지는 경우에 사용합니다. 유튜브 조회수와 같은 카운트 형태의 데이터를 예로 들 수 있습니다. 인기 영상일 경우 RDS 형태의 데이터에 저장해 I/O를 반복한다면 엄청난 자원을 사용할 것입니다. 이를 Redis를 사용해 데이터를 캐싱 처리하고 일정한 주기에 따라 RDS에 업데이트를 한다면 RDS에 가해지는 부담을 크게 줄이고 성능은 크게 향상시킬 수 있을 것입니다. 또 사용자의 세션 관리에도 사용될 수 있는데 사용자의 세션을 유지하고, 불러오고, 여러 활동들을 추적하는데 매우 효과적으로 사용할 수 있습니다.

Redis의 장점은 무엇이 있을까요?

먼저 레디스는 In-Memory 데이터베이스로 데이터를 메모리에 저장하고 조회하기 때문에 기존 관계형 데이터베이스보다 빠릅니다. 그리고 다양한 자료구조를 제공해 개발의 편의성을 증가시켜줍니다. 또 트랜잭션 문제도 해결해 줄 수 있습니다. Redis 자료구조는 Atomic하다는 특징 때문에 race condition을 피할 수 있습니다.

Regularization(정규화)

Index & Hint