DB

[DB] Materialized view의 사용시 장점과 단점

멋진놈 2024. 11. 27. 11:03
728x90

프로젝트를 진행하면서 복잡한 쿼리를 작성하게 되었다.

해당 쿼리는 각각의 자재들의 공식들이 들어갔는데, 이것을 프로시저나 뷰테이블로 작성하고 해당 부분을 mybatis mapper로 불러들여서 api로 가져와봤는데, api 하나당 거의 5~10초 정도 걸렸다.

그래서 이것으로는 답이 없다는 생각이 들었다.

그랬더니 이야기를 들었다. 그럴때 사용하는것이 Materialized view라고. 그래서 결론은 이것을 사용하니 api 하나당 0.1초~ 1초 사이로 줄어들게 되었다. 많이 오래 걸려봐야 1초가 되었다는 이야기고, 속도 개선이 다행히 되었다.

그러면 Materlialized view는 왜 빠를까?

# 주요이유 :

 

Materialized View가 빠른 이유는 데이터를 미리 계산하고 물리적으로 저장하기 때문이라고 한다. 이는 쿼리 실행 시 실시간으로 데이터를 가져오는 일반 View와 달리, 사전 준비된 데이터를 바로 활용할 수 있어 성능이 크게 향상됨을 볼 수 있다.

 

1. 사전 계산된 결과 저장

  • Materialized View는 복잡한 SQL 쿼리나 조인을 미리 실행하여 결과를 저장해 둡니다.
  • 따라서, 쿼리 실행 시 데이터베이스가 다시 계산할 필요 없이 저장된 결과를 바로 반환합니다.
  • 복잡한 연산(조인, 집계, 필터 등)이 많은 경우 성능 차이가 특히 큽니다.

2. 저장소에서 바로 데이터 제공

  • 일반 View는 실행 시마다 동적으로 데이터를 생성하지만, Materialized View는 생성 시점에 데이터를 물리적으로 저장합니다.
  • 저장된 데이터를 직접 읽어오기 때문에 디스크 I/O나 CPU 부하가 줄어들고 응답 속도가 빨라집니다.

3. 인덱스 및 파티셔닝 활용 가능

  • Materialized View는 물리적으로 존재하기 때문에 인덱스를 생성하거나 데이터를 파티셔닝할 수 있습니다.
  • 이러한 최적화를 통해 데이터 검색 및 조회 성능이 크게 향상됩니다.

4. 네트워크 부화 감소

  • 원격 데이터베이스나 분산 환경에서 데이터를 조회하는 경우, Materialized View는 로컬에서 데이터를 제공하므로 네트워크 트래픽을 줄이고 응답 시간을 단축시킬 수 있습니다.

5. 읽기 전용 작업에 최적화

  • Materialized View는 읽기 중심의 워크로드에서 매우 효과적입니다.
  • 예를 들어, 데이터 분석 대시보드, 통계 보고서 등에서 동일한 데이터가 자주 조회된다면 반복적인 쿼리를 실행할 필요 없이 빠른 응답을 제공합니다.

# 장점 :

 

은 주로 성능 최적화와 데이터 활용 측면에서 나타납니다. 아래는 주요 장점들을 정리한 내용입니다:

1. 쿼리 성능 향상

  • 복잡한 SQL 연산(조인, 집계 등)을 미리 계산하여 저장하므로, 동일한 데이터를 조회할 때 쿼리 실행 시간이 크게 단축됩니다.
  • 저장된 데이터를 그대로 반환하므로 실시간 계산 비용이 줄어듭니다.

2. 복잡한 연산 단순화

  • 일반적으로 조인, 필터링, 집계 등이 포함된 복잡한 쿼리를 매번 실행하지 않아도 됩니다.
  • 예를 들어, SUM, COUNT, AVG와 같은 집계 연산이 자주 필요한 보고서나 분석 쿼리의 성능을 최적화할 수 있습니다.

3. 인덱스 및 파티셔닝 가능

  • Materialized View는 물리적으로 저장되기 때문에 일반 테이블처럼 인덱스를 생성하거나 데이터를 파티셔닝할 수 있습니다.
  • 이러한 최적화를 통해 대규모 데이터 세트에서 특정 키나 범위 기반 조회 성능을 높일 수 있습니다.

4. 데이터 가용성 및 신뢰성

  • 원본 데이터가 손실되거나 접근이 불가능한 경우에도 Materialized View에 저장된 데이터를 활용할 수 있습니다.
  • 원본 데이터베이스의 부하를 줄이면서 동일한 데이터를 반복적으로 제공할 수 있습니다.

5. 네트워크 비용 절감

  • 분산 데이터베이스 환경에서, 원격 데이터 조회 대신 Materialized View를 사용하면 네트워크 트래픽을 줄일 수 있습니다.
  • 데이터를 미리 저장하여 지역별로 분산된 시스템에서 빠르게 제공할 수 있습니다.

6. 읽기 전용 작업 최적화

  • 읽기 중심의 워크로드에서 빠른 조회 성능을 제공합니다.
  • 예: 데이터 분석 대시보드, 보고서 생성, 대규모 읽기 전용 작업 등.

7. 실시간 데이터를 저장해 과거 데이터 유지 가능

  • Materialized View는 특정 시점의 데이터 상태를 저장할 수 있습니다.
  • 이를 통해 과거 데이터를 유지하거나 이력 데이터를 분석하는 데 유용합니다.

8. OLAP(Online Analytical Processing)에 적합

  • 데이터 분석(OLAP) 환경에서 대규모 데이터 처리 성능을 향상시킵니다.
  • 복잡한 비즈니스 인텔리전스(BI) 쿼리를 미리 준비하여 사용자 대기 시간을 줄입니다.

9. 사용자 정의 데이터 준비

  • Materialized View를 통해 사용자가 자주 사용하는 데이터 형태를 미리 준비할 수 있습니다.
  • 예: 특정 비즈니스 로직에 따라 데이터를 사전 가공.

10. 원본 데이터 보호

  • 원본 데이터 테이블을 직접 조회하거나 수정하는 위험 없이, Materialized View를 통해 안전하게 데이터를 제공할 수 있습니다.

# 단점 ;

데이터 동기화 비용

Materialized View는 데이터가 변경될 때 업데이트(Refresh)가 필요합니다. 이는 추가적인 동기화 비용을 발생시킬 수 있습니다.

두 가지 Refresh 방식:

  1. Complete Refresh
    • 전체 데이터를 다시 계산하여 저장.
    • 정확하지만 느림.
  2. Incremental Refresh (Fast Refresh)
    • 변경된 데이터만 반영.
    • 빠르지만 제약 조건이 많음.
    1. 매번 refresh or drop view materialized 로 삭제 후 재생성 해서 동기화 시켜줘야함.

# refresh, drop 사용하는 경우

# refresh를 사용하는 경우 :

이미 들어가 있는 테이블에서 값이 변경 되었을때. 사용.

materialized view는 생성시에 a 값이 3이었다. 근데 어느날 사용자가 쓰다보니 a값이 5로 바꼈다. 그럴때 refresh를 해주지 않으면. a값은 그대로 3으로 되어 있는 경우때 refresh로 동기화 시켜줘야함.

=> ( REFRESH MATERIALIZED VIEW VIEWNAME;)

# drop을 사용하는 경우 :

materialized view로 복잡한 쿼리를 작성했다. 작성된 것은 2024년 11월 1일부터 ~ 11월 30일 까지 데이터를 가져오는 것이다. 이럴때 사용하다가 갑자기 2024년 10월 1일 부터 ~ 10월 30일 까지 데이터를 가져와야한다. 그러면 기존의 materialized view를 조회하면 11월달의 값을 가져오게 된다. 거기다 설상가상으로 materialized view가 생성 되어 있으면, 재생성이 불가능하다. 그럴때 drop view materialized로 해당 뷰를 날리고 다시, 조건에 날짜값을 변경해서 재생성 해줄때 사용. 즉

  • 예를 들어, startDate와 endDate가 변경되면서 쿼리가 바뀌어야 하는 경우.
  • 기존 Materialized View는 더 이상 유효하지 않으므로 삭제 후 새로 생성하는 것이 합리적이다.

( => DROP MATERIALIZED VIEW IF EXISTS VIEWNAME; CREATE MATERIALIZED VIEW VIEWNAME )