이호석 7주차 서블릿 카페(3) 학습일지

✅ 서블릿 카페 3회차 커버링 인덱스에 따른 성능 차이 비교

인덱스에 따른 페이징 성능 측정

• 환경

  • Question 200만건, Reply 질문 당 0 ~ 10개 총 1025만건

• 비교 할 쿼리

  # 실험 할 쿼리는 아니고 댓글 쿼리
  EXPLAIN
  SELECT r.id, writer, contents, created_time, users_primary_id, question_primary_id
  FROM reply r
           JOIN (SELECT id
                 FROM reply r
                 WHERE deleted_at IS NULL
                   AND question_primary_id = 2000000
                   AND id > 1000000
                 LIMIT 5) temp ON r.id = temp.id;
  
  # 실험 할 쿼리
  SELECT q.id, writer, title, contents, created_time, users_primary_id, deleted_at
  FROM question q
           JOIN (SELECT id
                 FROM question
                 WHERE deleted_at IS NULL
                 ORDER BY id DESC
                 LIMIT 15 OFFSET 1999985) as temp on temp.id = q.id;
  
  # 인덱스 생성 및 드랍
  CREATE INDEX idx_deleted_at ON question (deleted_at);
  DROP INDEX idx_deleted_at ON question;
  
  # 복합 인덱스 생성 및 드랍
  CREATE INDEX idx_deleted_at_id ON question(deleted_at, id DESC);
  DROP INDEX idx_deleted_at_id ON question;

• 성능 측정

  • 인덱스가 없었을때, 실행 계획 및 실제 시간

    

    

  • deleted_at 컬럼 인덱스가 있을떄 실행 계획 및 응답 시간

    

    

• 결과

  인덱스가 없을때: 2.28second

  인덱스가 있을때: 0.95second

✅ 수업노트!

• (20240805 7주차 월요일 수업) - ERD

  • ERD를 처음 만든 사람은 피터첸? → 피터첸 표기법
  • ERD를 왜 만들까?
    • ERD는 완전 개념적인 설계
    • 테이블 위주로 설계하게 되면 데이터베이스에 더 가까운 단계임
    • 따라서 가장 기획서의 의도를 충실하게 담아내는게 ERD가 해야하는 일이다.

• (20240807 7주차 수요일 수업) - DB 정규화

  • 조영호님은 데이터를 중복으로 저장해 API 호출을 최소화함 (MSA와 비슷하게)
    • 카프카 같은데 밀어넣고 브로드캐스팅해서 한번에 변경하도록 함
  • 잘 설계된 테이블
    • 다른 테이블의 애트리뷰트 값을 읽어오는 것은, 외래키의 참조를 통해서만 가능하다.
  • 잘못된 설계의 문제점
    • 데이터의 중복 발생 → 이상현상(anormaly) 발생 (과거엔 이게 진짜 문제 → 1~20MB 하드디스크가 2천만원씩 함 그래서 중복이 있으면 안됨)
    • 이상현상 (삽입 이상, 삭제이상, 갱신이상)
  • 정규형
    • 1, 2, 3, 4(드물게), BCNF 정규화가 존재함
  • 함수적 종속성
    • 두 애트리뷰트 X, Y에서 X가 Y를 함수적으로 결정 X → Y
      • Y가 바뀌면 X가 무조건 바뀐다면 X가 Y를 함수적으로 결정한다.
      • X의 값이 유일한 Y의 값을 결정한다.
      • Y는 X에 함수적으로 종속
  • 후보키
    • 유일성
  • 기본키
    • 여러 후보키 중 대표적인 키 하나가 테이블의 기본 키가 된다.
    • 함수적 종속정을 이용해 정의할 수 있다. 모든 다른 애트리뷰트를 함수적으로 결정하는 애트리뷰트
  • 1정규형
    • 테이블은 반드시 하나 이상의 키를 가지고 있어야 한다.
    • 애트리뷰트의 도메인이 오직 원자값만을 포함한다.
  • 2정규형
    • 완전 함수적 종속
      • ABC → X라고 할 때
      • ABC중 하나라도 제거하면 위 조건이 성립하지 않음 (완전 함수적 종속)
    • 부분 함수적 종속
      • ABC → X라고 할때
      • AB → X도 되는 경우 부분 함수적 종속이 발생한다.
  • 이행 종속과 제 3 정규형
    • 후보키가 아닌 애트리뷰트에 이행 종속이 발생하면 안된다.
    • A → B, B → C면 이행 종속이다.
  • BCNF
    • 3 정규형을 만족하는 친구를 찾아서 BCNF를 만족하지 못하면 BCNF를 해야 함
    • ABCDEF가 있을떄
    • ABC → D
    • ABC → E
    • ABC → F
    • 만약 D → B가 되면 키에 대해서 사이클이 생기면 이를 BCNF가 된다.

  → 요즘은 정규화의 개념을 그렇게 빡세게 하지 않음 → 성능이 나빠짐 (반정규화 많이함)

  → 과거야 데이터 바이트 하나하나가 소중했기 때문에 많이 각광받았다.