<div id="readability-page-1" class="page"><article id="mainContent">
              <div>
                <p><a href="/m/category/%EC%BB%B4%ED%93%A8%ED%84%B0%EA%B3%B5%ED%95%99/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4"><span>컴퓨터공학/데이터베이스</span></a></p><h3>PostgreSQL Materialized View 사용기</h3>
              </div>
              <p><cite>Berno</cite>
                <span> 2024. 1. 12. 22:30</span>
              </p>
              

<ins data-ad-client="ca-pub-9527582522912841" data-ad-slot="8674651030" data-ad-format="auto" data-full-width-responsive="true" data-ad-type="inventory" data-ad-adfit-unit="DAN-we6apVVPwuoDAazb"></ins>




            
                <div>
                                <h3 data-ke-size="size23"><b>0. 이 글을 작성하는 이유</b></h3>
<p data-ke-size="size16">최근 PostgreSQL을 사용하던 중 기능 구현을 위해 Materialized View라는 걸 알게 되었는 데 사용하면서 알게 된걸 간단하게 정리하기 위함</p>
<h3 data-ke-size="size23"><b>1. Materialized View와 일반 View를 비교하면서 알아보자.</b></h3>
<p data-ke-size="size16">물리적 저장을 하느냐 안 하느냐의 차이에서 시작할 것 같다.</p>
<p data-ke-size="size16">일반 View는 논리적으로 사용하지만 Materialized View는 의미 그대로 이를 구체화하여 물리적으로 저장한다.</p>
<p data-ke-size="size16">View는 이 특성으로 인해 결과값을 저장하는 게 아닌 이 View 전체를 조회하는 쿼리를 참조하고 있어 별도의 갱신이 없어도 계속해서 값을 갱신한다.</p>
<p data-ke-size="size16">Materialized View는 실제 값을 저장하기 때문에 갱신을 명시적으로 해주어 한다.</p>
<p data-ke-size="size16">즉, 우리가 View를 기준으로 조회를 할 때 실제로는 View자체에서 모든 데이터를 조회한 이후 검색이 들어간다. 이로 인해 속도가 빠르지는 않다.</p>
<p data-ke-size="size16">하지만 Materialized View는 이미 모든 결과를 값으로 저장하고 있다. 이로 인해 다시 조회하는 과정이 없어 조회가 빠르다.</p>
<p data-ke-size="size16">이러한 이유로 생각을 해보면 Materialized View는 이미 고정된 값을 조회하는 데 있어 상당히 빠르게 할 수 있다.</p>

<h3 data-ke-size="size23"><b>2. 그러면 나는 이걸 왜 사용했는가?</b></h3>
<p data-ke-size="size16">일주일에 한 번씩 누적된 로그로 데이터를 갱신해서 해당 데이터로 일주일간 보여주는 일이 생겼다. 그러던 중 Materialized View라는 것을 알려 주어서 조금씩 보게 되었다.</p>
<pre id="code_1705066046296" data-ke-language="sql" data-ke-type="codeblock"><code>CREATE MATERIALIZED VIEW [VIEW_NAME] AS
       SELECT [가져오는 칼럼들]
       FROM [가져오는 원본 테이블];</code></pre>
<p data-ke-size="size16">이제 여기서 Materialized View에는 Unique Index를 추가할 수 있어서 추가해 주었다.</p>
<p data-ke-size="size16">방법은 테이블과 동일했다.</p>
<pre id="code_1705066062633" data-ke-language="sql" data-ke-type="codeblock"><code>CREATE UNIQUE INDEX IF NOT EXISTS [인덱스 이름] ON [타겟 VIEW] ([타겟 칼럼]);</code></pre>

<p data-ke-size="size16">문제는 직접 JPA를 이용해서 별도로 업데이트는 불가능하고 쿼리로만 갱신이 가능했다.</p>
<pre id="code_1705066085784" data-ke-language="kotlin" data-ke-type="codeblock"><code>entityManager.createNativeQuery("REFRESH MATERIALIZED VIEW CONCURRENTLY [뷰 이름]").executeUpdate()</code></pre>

<p data-ke-size="size16">나는 위에서 바로 했지만 Materialized View에 갱신 중 접근을 하기 위해서는 2가지를 만족해야 한다.</p>
<ul data-ke-list-type="disc">
<li>쿼리에서 CONCURRENTLY 옵션 추가</li>
<li>Unique Index 추가</li>
</ul>
<p data-ke-size="size16">더 다양한 옵션이 있겠지만 오늘은 여기까지 정리하고 사용하면서 더 정리를 해보도록 하겠다.</p>
            
            
                </div>
            

              

            </article></div>

흔한 컴공출신 개발자

bernoyoun

0. 이 글을 작성하는 이유
최근 PostgreSQL을 사용하던 중 기능 구현을 위해 Materialized View라는 걸 알게 되었는 데 사용하면서 알게 된걸 간단하게 정리하기 위함
1. Materialized View와 일반 View를 비교하면서 알아보자.
물리적 저장을 하느냐 안 하느냐의 차이에서 시작할 것 같다.
일반 View는 논리적으로 사용하지만 Materialized View는 의미 그대로 이를 구체화하여 물리적으로 저장한다.
View는 이 특성으로 인해 결과값을 저장하는 게 아닌 이 View 전체를 조회하는 쿼리를 참조하고 있어 별도의 갱신이 없어도 계속해서 값을 갱신한다.
Materialized View는 실제 값을 저장하기 때문에 갱신을 명시적으로 해주어 한다.
즉, 우리가 View를 기준으로 조회를 할 때 실제로는 View자체에서 모든 데이터를 조회한 이후 검색이 들어간다. 이로 인해 속도가 빠르지는 않다.
하지만 Materialized View는 이미 모든 결과를 값으로 저장하고 있다. 이로 인해 다시 조회하는 과정이 없어 조회가 빠르다.
이러한 이유로 생각을 해보면 Materialized View는 이미 고정된 값을 조회하는 데 있어 상당히 빠르게 할 수 있다.
 
2. 그러면 나는 이걸 왜 사용했는가?
일주일에 한 번씩 누적된 로그로 데이터를 갱신해서 해당 데이터로 일주일간 보여주는 일이 생겼다. 그러던 중 Materialized View라는 것을 알려 주어서 조금씩 보게 되었다.
CREATE MATERIALIZED VIEW [VIEW_NAME] AS
       SELECT [가져오는 칼럼들]
       FROM [가져오는 원본 테이블];
이제 여기서 Materialized View에는 Unique Index를 추가할 수 있어서 추가해 주었다.
방법은 테이블과 동일했다.
CREATE UNIQUE INDEX IF NOT EXISTS [인덱스 이름] ON [타겟 VIEW] ([타겟 칼럼]);
 
문제는 직접 JPA를 이용해서 별도로 업데이트는 불가능하고 쿼리로만 갱신이 가능했다.
entityManager.createNativeQuery("REFRESH MATERIALIZED VIEW CONCURRENTLY [뷰 이름]").executeUpdate()
 
나는 위에서 바로 했지만 Materialized View에 갱신 중 접근을 하기 위해서는 2가지를 만족해야 한다.
쿼리에서 CONCURRENTLY 옵션 추가
Unique Index 추가
더 다양한 옵션이 있겠지만 오늘은 여기까지 정리하고 사용하면서 더 정리를 해보도록 하겠다.

PostgreSQL Materialized View 사용기

댓글