🖥️ CS/DB

View 테이블

한국의 메타몽 2024. 10. 16. 21:21

목차

  1. 뷰(View) 테이블이란?
  2. 장점
  3. 단점
  4. Slave DB와의 차이점
  5. 현업에서 사용 사례



1. 뷰(View) 테이블이란?

  • 실제 데이터를 저장하지 않고 DB에서 미리 정의한 쿼리의 결과를 저장해 놓은 가상 테이블
    • 일종의 재사용 가능한 쿼리
  • 데이터를 별도로 저장하지 않으면서, 조회 시 원본 테이블의 데이터를 기반으로 결과를 보여줌
  • 결국 실제 데이터는 원본 테이블에 저장되어 있고, 뷰는 그 데이터를 가공해서 보여줌

 

예) view 테이블 생성 예시 코드

CREATE VIEW sales_department_view AS
SELECT employee_id, name, department
FROM employees
WHERE department = 'Sales';



2. 장점

  1. 재사용성 : 복잡한 쿼리를 쉽게 재사용 가능
  2. 보안성 : 특정 열, 또는 데이터를 제한해서 보여줄 수 있는 보안에 유리
  3. 유연성 : 여러 테이블의 데이터를 통합해서 보여줄 수 있음

핵심적으로 뷰는 데이터 복제 없이 원본 테이블의 데이터에 접근하는 방법을 간소화하거나 제한된 데이터를 보여주는데 사용됨



3. 단점

  1. 성능 저하
    • 가상 테이블이므로, 데이터를 저장하지 않고 원본 테이블의 데이터를 실시간으로 조회함
    • 따라서 원본 테이블에 복잡한 Join이나 연산이 포함된 경우, 뷰를 사용할 때 성능이 저하될 수 있음
    • 특히 뷰 위에 다시 쿼리를 실행할 경우, 그 뷰에 포함된 원본 테이블의 쿼리가 매번 실행되기 때문에 복잡한 쿼리일수록 성능 문제가 발생할 가능성이 높음
  2. 제한된 쓰기 작업
    • 읽기 전용이므로, DDL은 제한적으로 가능
    • Updatable View라는 개념은 있지만, 만약 여러 테이블을 기반으로 한 뷰일 경우엔 데이터 삽입, 수정, 삭제가 불가능
  3. 인덱스 사용 제한
    • 뷰 자체에 인덱스를 걸 수 없음
    • 뷰를 사용할 때는 원본 테이블에 정의된 인덱스만 사용할 수 있음 (기본적으로 원본 테이블의 인덱스를 그대로 따라감)



4. Slave DB와의 차이점

(1) Read-Only Slave DB

  • 목적 : Master DB에서 발생하는 읽기 작업의 부하를 줄이기 위해 사용
  • 데이터 저장 : Master DB로부터 데이터를 동기화, 즉, 실제로 동일한 데이터를 복제하여 저장

 

(2) View Table과의 비교

항목 Read-Only Slave DB 테이블 View 테이블
데이터 저장 실제 데이터를 저장하고 복제된 테이블 데이터 저장 안 함 (실제 테이블의 가상 테이블)
용도 주로 읽기 성능 개선 및 백업 목적 복잡한 쿼리 단순화, 데이터 제한
쓰기 가능성 불가능 (읽기 전용) 일반적으로 읽기 전용, 경우에 따라 쓰기 가능
데이터 동기화 주 DB와 복제된 데이터 동기화 원본 테이블 데이터를 실시간 조회
성능 읽기 성능 향상 (별도의 DB 서버) 성능에 큰 영향 없음 (원본 테이블 조회)




5. 현업에서 사용 사례

현업에서 최근에 사용 사례가 있었는데, 당시 상황을 축소해서 요약하면 다음과 같다.

1. A DB에서 A 테이블의 특정 유저의 sequence 값들을 List<Long>으로 저장
2. B DB에서 B 테이블의 productName을 1번에서 구한 sequence로 조회 (IN 절로 조회)
3. B DB에서 C 테이블의 prizeName을 1번에서 구한 sequence로 조회 (마찬가지로 IN절로 조회)


서로 다른 DB에 Connection을 일으키고 IN 절로 조회하자니 성능이 떨어진다.
그래서 다음과 같이 View 테이블을 사용하여 개선했다.

1. A DB의 A 테이블에 대한 View 테이블을 B DB에 생성
2. B DB에 생성된 View 테이블 (이하 A' 테이블)로 B DB의 B 테이블, C 테이블과 Join하여 조회


이제 IN절로 조회하지 않고 JOIN 하는 로직으로 변경됐다.

한 번에 JOIN을 하니 로직이 간소화 되긴 했다. 

다만 JOIN에 따른 테스트 코드 작성 로직이 필요하게 되었다.

 

개인적으로는 위와 같은 개선을 통해 성능이 좋아졌다고는 체감되지 않는다. 

View 테이블은 궁극적으로 미리 정의한 쿼리의 결과를 저장해 놓은 가상 테이블이기 때문이다.