콘텐츠로 이동

2023 08 11

2023-08-11

window location

참고: https://developer.mozilla.org/en-US/docs/Web/API/Window/location

  • 개요
    • Window.location은 read-only Location 객체이다.
    • 개발자 도구 열어서 location = "https://naver.com" 치면 쓱 이동함
    • 이는 location.href = "https://naver.com과 같은 동작임
  • 이동 
    location.assign("https://naver.com")
location = "https://naver.com"
  • 현재 페이지 리로드 
    location.reload()
  • Search

    • location.search = data 

      location.search = "hello"

      • 이러면 현재 페이지에서 ?hello가 붙은 url로 이동

서브쿼리가 좋지 않은 이유

참고: https://schatz37.tistory.com/3 참고: https://project-notwork.tistory.com/38

  • 개요
    • 서브쿼리: SQL 내부에서 작성되는 일시적인 테이블
      • 일시적인 테이블 => 성능 차이를 야기함
    • SQL 데이터 저장 테이블
      • 테이블 | DB에 물리적으로 저장된 데이터 | 영속적, 물리적 저장 O
      • 뷰 | 가상의 테이블, 접근할 때 마다 SELECT 구문의 실행 | 영속적, 물리적 저장 X
      • 서브쿼리 | 가상의 테이블, SQL 구문 실행 중에만 존재 | 일시적, 물리적 저장 X
    • 이는 성능 관점에서 차이를 발생시킨다.
  • 테이블
    • DB에 저장되어있는 테이블을 가져오기 때문에 빠르고 큰 비용없이 접근 가능
  • 뷰
    • 테이블에서 일부만을 가져와 가상 테이블(뷰)를 만든다
    • 장점: 테이블 중 필요한 데이터만 가상테이블로 저장해 관리가 편하고 SQL문이 간결해짐
    • 단점: 독립적인 인덱스 가질 수 없음. SELECT 문에 구문이 실행되어 성능 문제 유발 가능

  • 서브쿼리 

    select *
from (select * from receipts where cust_id = 'B') a;

    • SQL문의 from 절에서 서브커리가 하나의 뷰 역할을 한다고 해서 인라인 뷰라는 이름을 붙이기도 함
    • 장점: SQL 구문 안에서 유연하게 또 다른 SQL문을 만들어 활용할 수 있음
    • 단점: 연산 비용이 추가됨. 최적화를 받을 수 없음. 쿼리가 복잡해짐
  • 서브 쿼리 장/단점
    • 장점
      • 쿼리 작성 편리함
      • 성능 관점에서 효율적인 쿼리 작성하기 위해서는 수고스럽지만 효율적인 방법을 생각해보자!
    • 단점
      • 서브쿼리 실체적인 데이터를 저장하고 있지 않아 1. 연산 비용 추가: 접근 시마다 SELECT 구문에 접근해 데이터 만들고 연산비용 증가 2. 최적화 못받음: 서브쿼리엔 메타정보 없어. 인덱스, 제약 다없어. PK도 없어. 옵티마이저 정보 못 얻어. 성능 저하 3. 쿼리가 복잡해짐: 쿼리 두개 읽는거랑 똑같아
  • Then what?
    • 성능 문제를 해결하기 위해 2가지를 고려할 것
      1. 불필요한 JOIN 연산 수행하지는 않았는지
      2. JOIN 시 불필요한 테이블 접근하지 않았는지
    • JOIN 시 서브쿼리 활용해 결합 레코드 수를 줄여 성능 효율을 높이자
    • 서브 쿼리의 성능적 문제는 서브쿼리가 데이터의 실체를 저장하지 않고 있다는 점
    • 내부적으로 복잡한 연산을 수행하거나 결과 크기가 큰 서브쿼리를 사용할 때 성능 리스크를 고려해야한다
    • 조인할 때는 조인 대상 레코드수를 최대한 줄이자.

DB 파티셔닝

참고: https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html

  • 개요
    • 서비스 커지고 DB에 많이 쌓을수록 용량 한계/성능 저하 발생
    • DBMS에 너무 큰 테이블이 들어가면 용량/성능 측면에서 많은 이슈가 발생하고 파티션이라는 작은 단위로 나누어 파티셔닝 기법이 나타남
    • SW 적으로 데이터베이스 분산 처리하여 성능이 저하되는 것 방지
  • 개념
    • 큰 테이블이나 인덱스를 관리하기 쉬운 파티션이라는 작은 단위의 물리적으로 분할 하는 것을 의미
  • 목적
    1. 성능
      • DML, Query 성능향상
      • 대용량 Data write 효율
      • Full Scan Access 범위 제한
      • 경합 줄임
    2. 가용성
      • 물리적인 파티셔닝으로 전체 데이터 훼손 가능성이 줄고 데이터 가용성 향상
      • 각 분할 영역 독립적으로 백업/복구 가능
      • 테이블 파티션 단위로 disk i/o 분산 => update 성능 향상
    3. 관리 용이성
  • 장단점
    • 장점
      • 관리적 측면
        • 데이터 손실 가능성 줄어 데이터 가용성 향상
        • 파티션 별로 백업 및 복구 가능
        • 파티션 단위로 I/O 분산 가능해 update 향상
      • 성능적 측면
        • 데이터 검색시 필요한 부분만 탐색해 성능 증가
    • 단점
      • 테이블간 조인 비용 발생
      • 테이블과 인덱스를 꼭 같이 파티셔닝할 것
  • DB 파티셔닝 종류
    1. 수평 파티셔닝
      • 샤딩과 같은 개념
      • 스키마를 복제하고 샤드키 기준으로 데이터 나눔
      • 장점
        • 데이터 갯수 기준으로 파티셔닝
        • 데이터 갯수 작아지며 인덱스 갯수도 작아짐
      • 단점
        • 서버간의 연결과정 많음
        • 하나 서버 고장나면 무결성 깨짐
    2. 수직 파티셔닝
      • 테이블의 일부 열을 빼내는 형태
      • 하나의 엔티티를 2개이상으로 분리하자