DB구조 & 설계

primary key가 무엇인지 설명해 주세요

후보키 중 null을 허용하지 않고 튜플을 가장 잘 구분할 수 있는 대표키

[꼬꼬무1] primary key와 foreign key에 대해 설명해 주세요

테이블의 연관관계를 나타내기 위해 다른 테이블의 기본키를 참조하는 키

[꼬꼬무2] candidate key에 대해 설명하시오

튜플을 구분할 수 있는 최소한의 attribute 조합

[꼬꼬무3] alternate key에 대해 설명하시오

후보키 중 기본키에 해당하지 않는 키

[꼬꼬무4] composite key에 대해 설명하시오

두개 이상의 컬럼을 묶어서 기본키로 사용하는 것

 

관계형 데이터베이스의 N:M 관계에 대해서 설명해 주세요

N:M 관계는 관계를 가진 양쪽 엔티티 모두에서 1:N 관계를 가지는 것을 말한다. 즉, 서로가 서로를 1:N 관계로 보고 있는 것이다.

예를들어, 학원과 학생의 관계를 생각해보면, 한 학원에는 여러명의 학생이 수강할 수 있으므로 1:N 관계를 가진다. 반대로 학생도 여러개의 학원을 수강할 수 있으므로, 이 사이에서도 1:M 관계를 가진다. 그러므로 학원과 학생은 N:M 관계를 가진다고 할 수 있다.

 

N:M 관계는 서로가 서로를 1:N 관계, 1:M 관계로 갖고 있기 때문에, 서로의 PK를 자신의 외래키 컬럼으로 갖고 있으면 된다. 일반적으로 N:M 관계는 두 테이블의 대표키를 컬럼으로 갖는 또 다른 테이블을 생성해서 관리한다.

 

[꼬꼬무1] 1:N 관계에 대해서 설명해 주세요

1:N 관계는 한 쪽 엔티티가 관계를 맺은 엔티티 쪽의 여러 객체를 가질 수 있는 것을 의미한다.

예를 들어, 게시글과 댓글 관계를 생각해보면, 게시글을 댓글을 1개, 2개, 3개 그 이상도 가질 수 있다. 이를 부모가 자식을 소유한다고 표현한다.

이러한 관계를 1:N 관계라고 하며, 여러 명의 자식(N)의 입장에서 한 쌍의 부모(1)중 어떤 부모에 속해 있는지 표현해야하므로 부모 테이블의 PK를 자식 테이블에 FK로 집어 넣어 관계를 표현한다.

즉 부모 테이블(1)에서는 내 자식들이 누구인지 정보를 넣을 필요가 없고, 자식 테이블(N)에서만 각각의 자식들이 자신의 부모 정보(FK)를 넣음 으로써 관계를 표현할 수 있다.

left outer join, inner join 차이를 설명해 주세요

1. INNER JOIN : 교집합, 공통적인 부분만 SEELCT됨

​

ID	ENAME	KNAME
1	AAA	가
2	BBB	나

2. LEFT JOIN(LEFT OUTER JOIN) : 조인기준 왼쪽에 있는거 '다' SELECT 됨 
(공통적인 부분 + LEFT에 있는거만 )

ID	ENAME	KNAME
1	AAA	가
2	BBB	나
3	CCC	NULL

 

3.RIGHT JOIN(RIGHT OUTER JOIN) : 조인기준 오른쪽에 있는거 '다' SELECT됨
(공통적인 부분 + RIGHT에 있는거만)

ID	ENAME	KNAME
1	AAA	가
2	BBB	나
4	NULL	라
5	NULL	마

RDB - NoSQL를 비교 설명해 주세요 ⭐

RDB

RDB는 관계형 데이터베이스를 뜻하는 말입니다. 테이블 형태로 이루어져 있으며, SQL을 통해 데이터를 삽입, 삭제, 수정을 합니다. 그리고 테이블에 제약조건을 설정하여 데이터의 무결성, 일관성을 보장합니다.

NoSQL

NoSQL(Not Only SQL)은 관계형 데이터베이스가 갖는 테이블 형태의 스키마에 얽매이지 않고 자유롭게 데이터를 저장하고 조회할 수 있는 비관계형 데이터베이스입니다. NoSQL은 스키마를 엄격하게 정의하지 않기 때문에 필요에 따라 구조를 동적으로 변경할 수 있어 데이터 모델의 유연성을 제공합니다.

[꼬꼬무1] Nosql은 언제 사용하면 좋을까요?

NoSQL의 강점은 스키마를 엄격하게 정의하지 않기 때문에 필요에 따라 구조를 동적으로 변경해야할 경우 유리합니다

[꼬꼬무2] RDB는 언제 사용하면 좋을까요?

RDB는 트랜잭션 기능을 지원하므로 데이터의 일관성, 안전성이 중요한 경우 적합니다.

 

• RDB가 수평적 확장이 어려운 이유

먼저 수평적 확장, 수직적 확장에 대해 간략하게 설명하면 수직적 확장은 단일 서버의 성능을 올리는 것이고 수평적 확장은 여러개의 서버를 추가하는 것을 의미합니다

 

RDB가 수평적 확장이 어려운 이유는 데이터 검색이 어려워지기 떄문입니다. 예를 들어 order_id가 2인 주문을 조회하려면 여러 서버중 특정 서버로 부터 검색을 해야하는데 서버가 많아질 수록 접근 복잡성이 높아집니다. 또한 주문 테이블에서 order_id가 2인 고객 정보를 조회하려고 할때 고객 정보가 다른 서버에 있는 경우 복잡성이 더욱 증가하여 성능을 저하시킬 수 있습니다.

 

RDBMS, NoSQL에서의 클러스터링/레플리케이션 방식에 대해 설명해 주세요.

클러스터링(Clustering)이란?

 

 

클러스터링은 동일한 데이터베이스를 여러 대의 서버가 관리하도록 클러스터를 구축하는 것을 뜻한다. 이러한 클러스터링은 Active-Active 방식과 Active-StandBy 방식이 있다.

 

클러스터링을 하는 이유

[그림 1]과 같이 모든 DB 서버가 Active 상태면 하나의 서버에 이상이 생기더라도 바로 다른 서버를 이용해 정상적인 서비스 운영이 가능하다.

 

또한 클러스터링을 이용하게 되면 기존에 하나의 서버에 몰리던 부하를 여러 곳으로 분산시킬 수 있다. 즉, 로드밸런싱(Load Balancing)이 가능해진다. 

 

클러스터링의 단점

하지만 클러스터링은 여러 대의 서버가 데이터베이스를 공유하므로 병목현상이 발생해 더 많은 비용이 발생할 수 있다. 특히, Active-Active 방식은 모든 서버가 활성화된 상태이므로 병목 현상이 더 심하게 발생할 수 있다. 이러한 단점을 완화시킬 수 있는 방식이 바로 Active-StandBy 방식이다.

 

 

Active-StandBy 방식은 Active 상태인 서버와 Stand-By 상태인 서버를 나누어 운영한다. 즉, Stand-By 상태의 서버는 말 그대로 준비 상태로 대기하다 Active 서버에 문제가 발생했을 경우 Active 상태로 전환되어 사용된다. 이러한 Active-Stand-By 방식은 병목현상을 해결할 수 있다.

 

하지만, 장애가 발생했을 경우 Stand-By 상태에서 Active 상태로 전환하는 시간동안 서비스를 사용할 수 없다는 단점도 존재한다. 또한, Active-Active는 여러 대의 서버를 온전히 사용하여 부하를 줄일 수 있는 장점이 있지만, Active-StandBy 방식은 부하 분산 기능의 효율이 줄어드는 단점이 있다.

 

이러한 클러스터링 방식은 DB 서버의 장애를 Fail-Over하는 방식이라고 할 수 있다. 하지만 만약 데이터베이스에서 장애가 발생한다면 어떻게 극복할 수 있을까? 이때 사용할 수 있는 방식 중 하나가 리플리케이션(Replication)이다.

 

 

리플리케이션(Replication)이란?

 

데이터베이스 리플리케이션(Replication)이란 말 그대로 복제본 데이터베이스를 운용하는 것이다. 원본 데이터베이스를 Master, 복제된 데이터베이스를 Slave라고 부른다. Slave 데이터베이스는 Master 데이터베이스를 복제(Replication)하여 동일한 데이터를 가지게 된다.

 

리플리케이션을 하는 이유

이러한 리플리케이션을 사용하면 얻을 수 있는 이점이 있다. [그림 1]에서 볼 수 있듯이 Master 데이터베이스와 Slave 데이터베이스에 각기 다른 명령을 수행하도록 할 수 있다. Insert, Update, Delete 등의 작업은 Master 데이터베이스에서 처리하고, Select 등의 조회 작업은 Slave 데이터베이스에서 처리하도록 하면, 기존에 너무 많던 부하를 분산시킬 수 있다. 

 

또한 리플리케이션을 이용하면 데이터 안정성을 획득 할 수 있다. Master 데이터베이스의 데이터가 손상되었을지라도 Slave 데이터베이스에 복제된 데이터를 통하여 복구할 수 있다. 

 

 

리플리케이션의 단점

하지만 리플리케이션이 마냥 좋기만 한 것은 아니다. 리플리케이션이 이루어진 Slave 데이터베이스는 비동기(Asynchronous) 방식으로 Master 데이터베이스와 동기화 한다. 따라서 두 데이터베이스 간의 데이터 동기화가 보장되지 않아 일관성에 문제가 생길 수 있다. 또한, Master 데이터베이스가 정상 작동하지 않는다면 복구 및 대처가 까다롭다.

 

• 이러한 분산 환경에선, 트랜잭션을 어떻게 관리할 수 있을까요?
• 마스터, 슬레이브 데이터 동기화 전 까지의 데이터 정합성을 지키는 방법은 무엇이 있을까요?
• 다중 트랜잭션 상황에서의 Deadlock 상황과, 이를 해결하기 위한 방법에 대해 설명해 주세요.
• 샤딩 방식은 무엇인가요? 만약 본인이 DB를 분산해서 관리해야 한다면, 레플리케이션 방식과 샤딩 방식 중 어떤 것을 사용할 것 같나요?