1. 데이터베이스(DataBase)

데이터베이스(DataBase)

 

• 데이터베이스 사용하는 이유와 특징
  • 데이터베이스를 사용하는 이유: 데이터베이스가 사용되기 이전에는 파일 시스템을 이용했으나 데이터 종속성, 중복성, 데이터 무결성 문제가 있었다.
  • 데이터베이스의 특징
    • 1. 독립성
         • 물리적 독립성: 데이터베이스 사이즈를 늘리거나 데이터 파일 늘리거나.. 해도 관련된 응용 프로그램을 수정할 필요 없다.
         • 논리적 독립성: DB는 논리적 구조로 다양한 응용 프로그램의 논리적 요구를 만족시킬 수 있다.
      2. 무결성(integrity): 여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능, 데이터의 유효성 검사를 통해 무결성 유지
         • 무결성은 정확성, 일관성, 유효성이 유지되는 것을 의미한다.
      3. 보안성: 인가된 사용자들만 데이터베이스에 접근 가능하도록 유지한다.
      4. 일관성: 연관된 정보를 논리 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우발생할 수 있는 데이터의 불일치성을 배체할 수 있다.
      5. 중복 최소화: 데이터베이스는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 해결 가능하다

 

• 데이터베이스 성능 이슈
  • 데이터베이스 성능 이슈는 디스크 I/O를 어떻게 줄이느냐에서 시작된다. 디스크 I/O란 디스크 드라이브의 플래터(원판)을 돌려서 읽어야할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음에 데이터를 읽는 것을 의미한다. 디스크 헤더를 움직여서 읽고 쓸 위치로 이동하는 단계에서 시간이 결정된다.
  • 즉, 디스크 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 따라 결정된다.
  • 순차 I/O(시작 위치에서 연속적으로 데이터 탐색)가 랜덤 I/O(여러 위치에서 데이터 탐색)보다 빠를 수 밖에 없다. 하지만, 현실에서는 대부분의 I/O 작업은 랜덤 I/O 로 수행된다.

 

•  인덱스(Index)
  • 인덱스란?
    • 인덱스는 데이터베이스에서 테이블에 대한 검색 성능을 높이는 자료 구조이다.
    • 그래서 칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스로 만들어두는 것이다.
    • DBMS의 인덱스는 항상 정렬된 상태를 유지하므로 데이터 탐색은 빠르지만 데이터 저장(추가, 수정, 삭제)하는 경우에는 쿼리 문 실행 속도가 느려진다.
    • 즉, 인덱스는 데이터 “저장” 성능을 희생하고 데이터의 “읽기” 속도를 높이는 기능이다.
    • 인덱스는 말 그대로 책의 맨 처음 또는 맨 마지막에 있는 색인이라고 할 수 있다. 이를 그대로 가져와서 인덱스를 살펴본다면 데이터는 책의 내용이고 데이터가 저장된 레코드 주소는 인덱스 목록에 있는 페이지 번호가 될 것이다. DBMS도 데이터베이스 테이블의 모든 데이터를 검색해서 원하는 결과를 가져오려면 시간이 오래 걸린다.
    • 인덱스를 이용할지 이용하지 않을지 결정하는 방법은?
      • 손익 분기점: 인덱스를 이용했을 경우 결과 레코드가 전체 레코드의 20~25% 이상인 경우, 인덱스를 쓰지 않는 것이 효율적이다. 풀 테이블 스캔이 차라리 낫다.
      • 인덱스를 통해 읽어야 할 레코드의 건수(옵티마이저가 판단한 예상 건수) > (전체 테이블 레코드의 20 ~ 25%)인 경우 테이블을 모두 직접 읽어서 필요한 레코드만 가려내는 것이 효율적이다.
      • Def) 옵티마이저: MySQL은 쿼리를 최적으로 실행하기 위해 데이터가 어떤 분포로 저장되기 위해 통계 정보를 참조하고 데이터를 기반으로 최적의 실행 계획을 수립해준다.
      • 인덱스를 통해 데이터를 읽는 것은 인덱스를 거치지 않는 것보다 높은 비용이 드는 작업이다.
  • 인덱스를 데이터 저장 방식 별로 구분한다면?
    • B-Tree 인덱스 (알고리즘)
      • 일반적으로 사용되는 인덱스 알고리즘이다. 칼럼의 값을 변형하지 않고(사실상 값의 앞 부분만 잘라서 관리) 원래의 값을 이용해서 인덱싱하는 알고리즘이다.
      • B: balanced 를 의미
      • https://oranthy.tistory.com/443
    • Hash 인덱스 (알고리즘)
      • 칼럼의 값으로 해시 값을 계산해서 인덱싱하는 알고리즘으로 매우 빠른 검색을 지원한다. 하지만 칼럼의 값을 변형해서 인덱싱하는 알고리즘이다.
      • 따라서, 특정 문자로 시작하는 값으로 검색하는 전방 일치처럼 “값의 일부”만으로 검색, 범위 검색하고자 하는 경우는 해시 인덱스를 사용할 수 없다.
      • 주로, 메모리 기반의 데이터베이스에서 사용한다.
    • 왜 인덱스를 생성하는데 B-Tree를 사용하는가?
      • hash table은 시간 복잡도가 O(1)이라 더 효율적인게 아닌가?
      • select 질의의 조건에는 부등호 연산도 포함된다.
      • hash table 을 사용하면 “부등호 연산” 경우에 문제가 생긴다, hash table은 동등 연산(=)에 특화됐다. 따라서 데이터베이스의 자료구조로 적합하지 않다.
  • 인덱스 역할별로 구분 (Primary Index vs Secondary Index)
    • primary index(= 식별자) : 레코드를 대표하는 칼럼의 값으로 만들어진 인덱스를 의미한다. not null, 중복 불가능
    • secondary index(세컨더리 key): 프라이머리 키를 제외한 나머지 모든 인덱스를 말한다. 유니크 인덱스는 프라이머리 키와 성격이 비슷하고 프라이머리 키를 대체 가능해서 대체 키 (보조 키)라고도 한다.
    • 후보키는 PK와 대체키(보조키)를 모두 포함하는 말이다. 
  • 클러스터 인덱스
    • 클러스터는 여러 개를 하나로 묶는 다는 의미
    • https://junghn.tistory.com/entry/DB-클러스터-인덱스와-넌클러스터-인덱스-개념-총정리
    • Def)  클러스터링 인덱스는 PK가 비슷한 레코들끼리 묶어서 저장하는 것을 말한다.

 

• composite index

 

• index의 성능과 고려 사항
  • index는 항상 좋을까? 그렇지 않다
  • 인덱스를 생성하면 데이터를 저장(INSERT, UPDATE, DELETE 쿼리문 실행)할 때 별도의 과정이 추가적으로 발생한다.
  • DELETE: INDEX에 존재하는 값을 삭제하지 않고 사용하지 않는다는 표시로 남는다, 즉 row는 그대로
  • INSERT: 데이터 추가한 만큼 인덱스도 추가된다.
  • 예를 들어, 실제 데이터가 10만 건이데 100만 건의 데이터가 결과로 나올 수도 있다.
  • (update 문제점) = (delete 문제점) + (insert 문제점)
  • 즉, 변경 전 데이터가 삭제 되지 않고 insert로 인한 split 발생한다.
  • Ex) 여러 가지 칼럼 이름, 나이, 성별 중 어느 칼럼에 인덱스를 적용하는 게 효율적일까?
    • 이름에 대해서만 인덱스를 사용하면 효율적이다.
    • 10000개의 레코드가 있는 테이블에 대해 2000 단위로 성별에 인덱스를 생성했다고 가정하면 값의 범위가 적은 성별(남, 여)은 인덱스를 읽고 다시 한번 디스크 I/O가 발생하기 때문에 그 만큼 비효율적이다.

 

• 다중 칼럼 인덱스(복합 칼럼 인덱스, Multi conlumn index, Concatenated index)
  • Def) 다중 칼럼 인덱스: 여러 개의 칼럼을 인덱스로 설정하는 것을 말하며 실무에서 보통 2, 3개 칼럼을 인덱스로 많이 설정한다. 
  • 다중 칼럼 인덱스를 설정할 때, 순서가 매우 중요하며 신중하게 결정해야한다. 
  • 첫 번째 인덱스 기준 정렬한 다음, 두 번째 인덱스 기준 정렬, ... 로 처리되기 때문이다.
  • 인덱스 순서 결정 방법: WHERE 절의 '=' 조건과 같이 결과 레코드가 적은 데이터를 조회하는 컬럼을 다중 컬럼 인덱스 앞 쪽에 설정하고, 범위 검색과 같이 개수가 많은 데이터를 조회하는 컬럼을 다중 컬럼 인덱스 뒤 쪽에 설정해야 한다.

 

• 데이터베이스 정규화와 비정규화
  • 정규화 탄생 배경
    • 한 릴레이션에 여러 엔티티의 에트리부트를 혼합하게 되면 정보가 중복 저장되며 저장 공간을 낭비하게 된다. 또한 중복으로 인한 갱신 이상이 발생한다. 동일한 정보를 어떤 릴레이션에서는 변경하고 나머지 릴레이션에서는 변경하지 않은 경우 어느 것이 정확한지 알 수 없는 것이다. ⇒ 정규화로 해결
  • 정규화(Normalization)란?
    • Def) 정규화: RDBMS에서 중복을 최소화하기 위해 데이터를 구조화하는 작업이다.
    • 중복을 허용하지 않아서 무결성이 유지되면 DB의 저장 용량을 줄일 수 있다.
      • 무결성: 일관성과 정확성 모두 만족
    • 나쁜 릴레이션의 애트리뷰트들을 나눠서 좋은 작은 릴레이션으로 분해하는 작업을 말한다. 정규화 과정을 거치면 정규형을 만족한다.
    • 정규형: 특정 조건을 만족하는 릴레이션의 스키마의 형태를 말한다.
      • 1 정규화: 테이블의 컬럼이 더 이상 쪼갤 수 없는 하나의 값(원자값)을 갖도록 테이블을 분해하는 것이다.
        • 이상 현상
          • 삽입 이상: 학생이 수강 신청할 때 반드시 지고 교수, 학과를 알아야한다. 불필요
          • 삭제 이상: 300번 학생이 수강 취소하면 해당 과목에 대한 지도 교수, 과목 정보가 사라진다.
          • 갱신 이상: 100번 학생이 지도 교수를 변경할 때, P1인 행을 모두 찾아서 변경해야한다.
          • 발생 이유: 기본키가 아닌 속성들이 기본키에 완전 함수 종속되지 못하고 부분 함수 종속되어 있기 때문이다.
      • 2 정규화: 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해한다.
        • 완전 함수 종속: PK의 부분 집합이 결정자가 되어서는 안된다는 뜻이다.
        • 기본키에 속하지 않은 속성 모두가 기본키에 완전 함수 종속인 정규형을 말한다.
        • 이상 현상
          • 삽입 이상: 교수가 학과에 소속되어 있음을 추가할 때 반드시 지도
          • 삭제 이상” 300번 학생이 자퇴하면 P3 교수가 사라진다.
          • 갱신 이상
      • 3 정규화: 2 정규화를 진행한 테이블에 대해 이행적 함수 종속성을 제거한 정규형을 말한다.
        • 이행적 함수 종속성: X →Y AND Y → Z 이면 X → Z 이 성립하는 경우, 이행적 함수 종속성이 있다.
        • 즉, X가 Y의 결정자 and Y가 Z의 결정자일 때 X가 Z의 결정자인 경우, 이행점 함수 종속성이 있다고 말한다.
        • 다시 말해, PK 이외의 속성이 다른 속성을 결정할 수 없다는 뜻이다.
      • BCNF(Boyce-Codd Normal Form) 정규화: 3정규형을 더 강화시킨 개념이다.
        • 강한 제3정규형이라고 한다.
        • 모든 결정자가 후보키가 되도록 테이블을 분해하는 것입니다.
          • 후보키 = 기본키 + 대체키(보조키)
    • https://mangkyu.tistory.com/110 https://rebro.kr/160
    • 나쁜 릴레이션이란?
      • 엔티티를 구성하고 있는 애트리뷰트 간에 함수적 종속성을 판단한다. 판단된 함수적 종속성은 좋은 릴레이션 설계의 전형적 기준으로 사용된다. 즉 각각의 정규형마다 어떠한 함수적 종속성을 만족하는지에 따라 정규형이 정의되고 그 정규형을 만족하지 못하는 정규형을 나쁜 릴레이션으로 파악한다.
    • 함수적 종속성이란?
      • 애트리뷰트 데이터들의 의미와 애트리뷰트들간의 상호 관계로부터 유도되는 제약 조건의 일종이다. x, y를 임의의 애트리뷰트 집합이라고 할 때, x값이 y값을 유일하게 결정하는 경우 x는 y를 함수적으로 결정한다고 한다.

 

•  정규화의 장단점
  • https://ko.wikipedia.org/wiki/데이터베이스_정규화
  • 장점
    • DB 이상 현상 제거
    • DB 구조 확장 시, 재 디자인 최소화
    • 사용자에게 데이터 모델을 더욱 의미 있게 제공한다. 정규화된 테이블간의 관계는 현실 세계에서의 개념과 그들간의 관계를 반영한다.
  • 단점
    • 릴레이션 분해로 인해 릴레이션 간의 연산 (JOIN 연산)이 많아진다. 이로 인해 응답 시간이 느려질 수 있다. 덧붙이자면, 정규화 수행은 데이터를 결정하는 결정자에 의해 함수적 종속을 가지고 있는 일반 속성을 의존자로 하여 입력, 수정, 삭제 이상을 제거하는 것이다. 데이터의 중복 속성을 제거하고 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화되는 효과 있다. 따라서 정규화된 테이블은 데이터를 처리할 때, 속도가 빨라질 수도 있고 느려질 수도 있다는 것이다.
  • 비정규화(De-Normalization)
    • 읽는 시간을 최적화하도록 설계된 데이터베이스, 하나 이상의 테이블에 데이터를 중복되도록 배치하는 최적화 기법을 말한다.
    • 정규화된 엔티티, 속성, 관계를 시스템의 성능 향상, 개발과 운영의 단순화를 위해 중복 통합, 분리 등을 수행하는 데이터 모델링 기법 중 하나이다.
    • 비정규화하는 이유
      • 조회 시 성능이 떨어질 때, 비정규화를 고려한다.
    • 비정규화의 효과, 장점
      • JOIN 연산 비용을 줄일 수 있다.
      • 높은 규모 확장성을 실현하기 위해 자주 사용
    • 비정규화 단점
      • 데이터 저장, 수정 비용이 높다.
      • 일관성이 깨질 수 있다. 두 테이블에서 칼럼의 값이 다를 때, 어느 쪽이 올바른지 대한 문제가 생긴다.

 

•  트랜잭션(transaction)
  • 트랜잭션이란?
    • 작업의 완전성을 보장하는 것이다.
    • 데이터의 정합성을 보장하기 위한 기능이다.
    • “논리적인 작업 셋”을 모두 완벽하게 처리하거나 또는 처리하지 못하는 경우에는 원상태로 복구해서 작업의 일부만 적용되는 현상이 발생하지 않도록 만드는 기능이다. 사용자 입장에는 작업의 논리적 단위라고 이해할 수 있고 시스템 입장에서는 데이터들을 접근 또는 변경하는 프로그램의 단위라고 볼 수 있다.
    • 트랜잭션: 데이터의 정합성을 보장하기 위한 기능이다. 하나의 논리적인 작업 셋 자체가 100% 적용되거나 아무것도 적용되지 않아야 함을 보장하는 것이다.

 

• 트랜잭션의 특성(ACID)
  • A(Atomicity) 원자성
    • 만약 트랜잭션 중간에 어떤 문제가 발생한다면 트랜잭션에 해당하는 어떠한 작업 내용도 수행되어서는 안되며 아무런 문제가 발생되지 않았을 경우에만 모든 작업이 수행되어야한다.
  • C(Consistency) 일관성
    • 트랜잭션이 완료된 다음 상태에서도 트랜잭션이 일어나기 전의 상황과 동일하게 데이터의 일관성을 보장해야한다.
  • I(Isolation) 독립성: 각각의 트랜잭션은 서로 간섭 없이 수행된다.
    • 생각해볼 문제점
      • 트랜잭션의 독립성은 Spring Framework의 @transactional 속성 propagation과 상충되는 면이 있다.
  • D(durability) 지속성
    • 트랜잭션이 정상 종료된 다음에는 영구적으로 DB에 작업의 결과가 저장되어야 한다.
  • 트랜잭션 사용할 때 주의점
    • 트랜잭션의 범위를 최소화해야한다. 일반적으로 데이터베이스의 커넥션의 개수가 제한적이다. 그런데 각 단위 프로그램이 커넥션을 소유하는 기간이 길어진다면 사용 가능한 여유 커넥션의 개수는 줄어들게 된다. 그러다 어느 순간에는 각 단위 프로그램에서 커넥션을 가져가기 위해 기다려야하는 상황이 발생할 수도 있는 것이다.
      • 데이터베이스에서 커넥션(Connection)이란?
        • 커넥션: 애플리케이션과 데이터베이스의 연결을 말한다.
        • https://o-jing.tistory.com/29

 

• 트랜잭션의 격리 수준(isolation)
  • https://oranthy.tistory.com/434
  • 데이터 정합성이란? 하나의 트랜잭션에서 SELECT 쿼리를 실행했을 때, 항상 같은 결과를 가져와야한다.
1. read uncommitted: 어떤 트랜잭션의 변경 내용이 커밋이나 롤백되지 않아도 다른 트랜잭션에서 보인다. (Dirty read 발생)
   1. RDBMS에서는 격리 수준으로 인정하지 않는다.
1. read committed: 어떤 트랜잭션의 내용이 변경되서 커밋이 완료된 데이터만 다른 트랜잭션에서 조회 가능하다. (Dirty read 발생하지 않지만 부정합의 문제 ‘NON-REPEATABLE READ’)
   1. 정합성에 어긋난다.
   2. Def) 정합성: 하나의 트랜잭션에서 똑같은 SELECT 쿼리를 실행했을 때, 똑같은 결과를 가져와야한다.
   3. Oracle에서 기본으로 쓰인다.
1. repeatable read: 해당 트랜잭션이 ****시작되기 전에 이전에 커밋된 내용만 조회할 수 있다.
   1. 다시 말해 언두 영역에 백업된 이전 데이터를 이용해서 동일 트랜잭션 내에서 같은 결과를 보여주도록 보장한다.
   2. MVCC(Multi Version Concurrency Control)를 위해 언두 영역에 백업된 이전 데이터를 이용해서 동일 트랜잭션, 동일 결과를 보여주도록 보장한다.
   3. PHANTOM READ 라는 부정합 문제가 발생 가능
   4. PHANTOM READ: 다른 트랜잭션의 변경 작업에 의해 레코드가 보였다 안 보였다 하는 현상
   5. MySQL InnoDB엔진에서 기본적으로 쓰인다.
1. serializable: 한 트랜잭션이 읽고 있는 레코드를 다른 트랜잭션에서 접근 불가능
   1. 공유 잠금(읽기 잠금)을 획득해야 읽기 작업이 가능하다.
2. uncommitted
3. (아래로 갈수록 격리 수준이 높고 동시 처리 성능도 낮아진다.)
4. cf) Spring에서 트랜잭션의 격리 수준의 기본값은?
   • 애플리케이션에 연결된 데이터베이스의 기본 격리 수준을 따른다.
   • 참고) https://velog.io/@jurlring/MySQL의-트랜잭션-격리-수준과-스프링의-Transactional-기본-격리-수준
•  

 

• 잠금(Lock, 락)
  • Def) lock(락): 동시성을 제어하기 위한 기능, 여러 커넥션에서 동시에 같은 자원(레코드 or 테이블)을 수정을 요청할 경우 순서대로 한 시점에는 하나의 커넥션만 변경하도록 해주는 역할을 말한다.
  • https://oranthy.tistory.com/434
  • MySQL 엔진 레벨의 잠금
    1. 모든 스토리지 엔진에 영향을 준다.
    2. 글로벌 락: 잠금 범위가 가장 크다. MySQL에 존재하는 모든 테이블을 닫고 영향 준다. 여러 데이터베이스에 존재하는 테이블에 대해 mysqldump로 일관된 백업을 받아야 할 때 이용한다.
    3. 테이블 락: 개별 테이블 단위로 잠금
    4. 네임드 락: 임의의 문자열(String)에 대해 잠금을 설정한다.
    5. 메타 데이터 락: 데이터베이스 객체(테이블이나 뷰 등)의 이름이나 구조를 변경하는 경우에 획득하는 잠금이다.
  • InnoDB 스토리지 엔진의 잠금
    1. 스토리지 엔진 레벨의 잠금은 스토리지 엔진 간에 상호 영향을 주지 않는다.
    2. 레코드 기반의 잠금 기능을 제공한다.
    3. 레코드 락(record lock): 다른 DBMS의 레코드 락과 다르게 레코드 자체가 아니라 인덱스의 레코드를 잠근다는 점이 다르다.
    4. 갭 락(gap lock): 레코드와 인접 레코드 사이의 간격만을 잠그는 것을 의미한다. 레코드와 레코드 사이에 새로운 레코드가 INSERT 되는 것을 제어한다.
    5. 넥스트 키 락(next key lock): 레코드 락 + 갭 락
    6. 자동 증가 락(auto increment lock): AUTO_INCREMENT 가 설정된 칼럼에 대해 적용하는 테이블 수준의 잠금이다.

 

• 교착 상태
  • 교착 상태란 무엇인가?
    • 두 개 이상의 트랜잭션이 특정 자원의 잠금(lock)을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구하면 아무리 기다려도 상황이 바뀌지 않는 상태를 말한다.
    • 다시 말해, 두 개 이상의 작업이 서로 상대방의 작업이 끝나기만을 기다리고 있기 때문에 다음 단계로 진행하지 못하는 무한 대기 상태를 말한다. ****
  • 교착 상태의 예
  • 교착 상태의 빈도를 낮추는 방법
    • 트랜잭션을 자주 커밋한다.
    • 정해진 순서로 테이블에 접근한다.
    • 읽기 잠금 획득의 사용을 피한다.
    • 한 테이블의 복수 행을 복수의 연결에서 순서 없이 갱신하면 교착 상태가 발생하기 쉽다. 이 경우에는 테이블 단위의 잠금을 획득해서 갱신을 직렬화하면 동시성은 떨어지지만 교착 상태를 회피할 수 있다.

 

• statement vs preparedStatement

 

• NoSQL(Not Only SQL)
  • 관계형 데이터 모델을 지양하며 대량의 분산된 데이터를 저장하고 조회하는데 특화되어 있으며 스키마(자료 간 관계를 형식 언어로 정의한 구조) 없이 사용 가능하거나 느슨한 스키마를 제공하는 저장소를 말한다.
  • CAP 이론
    • NoSQL 데이터베이스 시스템은 세 가지 중 두 가지만 충족 가능하며 모두 충족할 수 없다.
      1. 일관성(Consistency, 동시성, 동일성): 다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것을 의미한다.
      1. 가용성(Availibility, 내고장성): 모든 클라이언트의 읽기와 쓰기 요청에 대해서 항상 응답이 가능해야 함을 보증하는 것이며 내고장성이라고도 한다. 가용성 있는 NoSQL은 클러스터 내에서 몇 개의 노드가 망가지더라도 정상 서비스가 가능하다.
      1. 분할 내구성(Partial tolerance, 네크워크 분할 허용성): 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네크워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템을 정상으로 작동해야한다.
      2. https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=windfalcon1&logNo=220402574806
  • 저장 방식에 따른 NoSQL 분류
    • 1. key-value 모델
         1. 가장 기본적 형태 ex) redis
         2. 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키 값 구조이다.
         3. 복잡한 조회 연산을 지원하지 않는다.
         4. 고속 읽기, 쓰기에 최적화
         5. 하나의 서비스 요청에 다수의 데이터 조회 및 수정 연산이 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성을 보장할 수 없다.
      1. document 모델
         1. key-value 모델을 개념적으로 확장한 구조로 하나의 키에 하나의 구조화된 문서를 저장, 조회
         2. ex) MongoDB
         3. 데이터 조장, 조회 방법이 RDBMS와 유사하다.
      1. column 모델
         1. ex) 구글의 클라우드 빅테이블, 카산드라
         2. 하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이뤄진 데이터를 저장하고 저장한다. 모든 칼럼은 타임 스탬프 값과 함께 저장된다.
         3. 대부분의 칼럼 모델은 읽기보다 쓰기에 특화되어 있다. 데이터를 먼저 커밋 로그와 메모리에 저장한 후, 응답하기 때문에 빠른 응답 속도를 제공한다.
         4. 채팅 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합

 

• 인메모리 데이터베이스 <=> 하드 디스크 기반 데이터베이스
  • ex) Redis
  • 디스크가 아닌 주 메모리(RAM)에 모든 데이터를 보유하고 있는 데이터베이스이다.
  • 데이터 스토리지의 메인 메모리에 설치되어 운영되는 방식의 데이터베이스 관리 시스템이다.
  • 디스크에 최적화된 데이터베이스보다 더 빠른데 디스크 접근이 메모리 접근보다 느리기 때문이다.
  • 장점: 디스크 접근보다 자료 접근이 훨씬 빠르다.
  • 단점: 휘발성, DB 서버 전원이 꺼지면 안에 있는 자료가 즉시 삭제되어 버린다. 따라서, 로그인 세션 같은 임시 데이터에 주로 쓰인다.
  • MySQL과 MariaDB의 MEMORY 엔진은 인 메모리 데이터베이스를 사용할 수 있는 옵션이다.

 

• RDBMS vs NoSQL
  • RDBMS는 스키마 변경 시, 복잡해진다.
    • 스키마(Schema): 데이터베이스를 구성하는 Entity, Attibute, Relationship 및 제약 조건 등에 관해 전반적으로 정의한 메타데이터 집합
    • 데이터 구조가 명확한 경우에 RDBMS를 사용한다.
    • 장점: 데이터 구조가 명확하다. 정해진 스키마에 따라 데이터를 저장하므로 중복이 발생하지 않는다.
    • 단점: 빅데이터의 경우에 성능이 떨어지고 비용이 올라간다. 성능을 올리려면 비용이 기하급수적으로 증가한다.RDBMS: 테이블 간의 관계가 있다. 외래 키를 사용한 테이블간 JOIN이 가능하다. 명확한 데이터 구조를 보장한다. 시스템이 커질 경우, JOIN문이 많은 복잡한 쿼리가 만들어질 수 있다. 
  • NoSQL는 테이블 간에 어떤 관계가 없다.
    • 명확한 데이터 구조를 알 수 없고 데이터가 변경, 확장 될 수 있는 경우에 사용한다.
    • 스키마가 정해져있지 않아 데이터에 대한 규격화가 되어 있지 않다. 자유로운 필드 추가
    • 스키마가 없거나 느슨한 스키마를 제공한다.
    • 빅데이터의 등장으로 일관성 포기한 NoSQL 등장
    • 장점: 대용량의 데이터 저장 가능하다. 
    • 단점: 스키마가 존재하지 않아 데이터의 일관성이 없다. 중복 발생 가능

 

• 트랜잭션의 전파 단계(Propagation)
  • Def) Propagation: 트랜잭션이 동작하고 있을 때, 다른 트랜잭션을 호출(실행)하는 상황에서 선택 가능한 옵션을 말한다.
    • @Transactional 의 propagation 속성을 통해 피호출 트랜잭션의 입장에서는 호출한 쪽의 트랜잭션을 그대로 사용할 수도 있고 새롭게 트랜잭션을 생성할 수도 있다.
    • https://mangkyu.tistory.com/269
  1. required(디폴트): 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없으면 새로운 트랜잭션을 생성한다.
  2. requires_new: 부모 트랜잭션을 무시하고 무조건 새로운 트랜잭션을 생성한다.
  3. support: 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우, nontransactionally로 실행된다.
  4. mandatory: 부모 트랜잭션 내에서 실행되며 부모 트랜잰션이 없을 경우 예외 발생
  5. not_support: nontransactionally로 실행되며 부모 트랜잭션이 내에서 실행될 경우 일시 정지
  6. never: nontransactionally로 실행되며 부모 트랜잭션이 존재하면 예외 발생
  7. nested: 해당 메서드가 부모 트랜잭션 내에서 진행될 경우, 별개로 커밋되거나 롤백될 수 있다. 둘러싼 트랜잭션이 없을 경우 required와 동일하게 작동한다.
  8. https://oranthy.tistory.com/315
  9. https://taetaetae.github.io/2016/10/08/20161008/

 

•  JOIN
  • INNER JOIN
  • OUTER JOIN
    • 외부 조인 (Outer join, ⟗ 또는 ⋈+ ) Def) 조인 시, 한 릴레이션에 있는 투플에 대해 대응하는 릴레이션에서 조인 속성 값이 같은 투플에 없을 경우, 대응하는 투플의 속성을 모두 NULL값으로 만들어 결과 릴레이션에 포함한다.
    • Left (Outer) join(⋈+L 또는 왼쪽으로 벌어진 나비모양 ): 왼쪽 릴레이션의 모든 투플이 결과에 포함된다.
    • Right (Outer) join(⋈+R ): 오른쪽 릴레이션의 모든 투플이 결과에 포함된다.
    • Full (Outer) join( ⟗ 또는 ⋈+ ): 두 릴레이션의 모든 투플들이 결과에 포함된다.

 

 

 

앞으로 공부할 부분

• 트랜잭션의 독립성 ↔ 트랜잭션의 전파 단계
  • 독립성: 각 트랜잭션은 독립적으로 실행된다.
    • 데이터베이스의 트랜잭션에 관한 개념이다.
  • 트랜잭션의 전파 단계
    • Spring Framework 밑에 있는 기능
    • 어떤 트랜잭션을 실행하는 도중에 다른 트랜잭션을 호출하는 상황에서의 선택 가능한 옵션을 말한다.

 

 

 

회고록

• 면접을 보기 위해 공부하거나 면접에서 들었던 질문을 공부하면서 내용을 정리했다.
• 어떤 면접에서 인덱스 질문에 제대로 대답 못 했던 경험 때문에 자극 받아서 더 꼼꼼하게 공부했다. 
• 백엔드 개발하려면 데이터베이스도 스프링만큼 중요하므로 기초부터 깊은 내용까지 세세하게 알아야한다.
• 빈출 질문: 인덱스 개념 및 장단점, RDBMS vs NoSQL, JOIN 종류별 설명, 레디스, 정규화, 다중 칼럼 인덱스, 트랜잭션의 격리 수준, 인메모리 데이터베이스란?

 

 

 

참고) 본 게시글은「 Real MySQL 8.0  - 위키북스」와 아래 깃허브의 질문을 참고하여 내용을 보충해서 작성했습니다.

틀린 부분있다면 댓글 부탁드립니다 🧡💛💖

백엔드 면접 질문 1

백엔드 면접 질문 2