회사에 들어오고, 제일 큰 일 중에 하나가 주기적 데이터 갱신과 함께 view를 업데이트하는 것에 있었다.
그래서 업데이트를 하게 되는데, 하다하다 이게 시간이 너무 걸리는 것이 아닌가?
열심히 하는데, view 업데이트 시간이 거의 한시간이 넘어가는 상황에 가만히 바라보다가 여러가지를 알게 되었다.
Materialized view는 일반 view와는 다르게 사용자가 직접 업데이트 명령어를 실행해야 한다. view와 같이 물리적 데이터 없이 논리적 접근을 하는 게 아니라, 업데이트 명령을 통해 물리적으로 db에 적용이 된다. 복잡한 다중 쿼리를 사용할 수 있는 대신, 물리적으로 적재가 되기 때문에 그에 따른 비용이 발생하고, update를 실행하면 업데이트 되는 것만 가져가는 것이 아니라, 전체를 다시 리로드 하는 것에 가깝기 때문에 데이터가 크고, 자주 변경될 경우 비용 부담이 클 수 있다.
view는 논리적으로 저장하는 것이다. 조금 더 말하면, 쿼리와 그에 대한 결과를 가져오는 것이다. 그렇기 때문에 데이터가 삽입될 때마다 쿼리가 실행되고, 쿼리의 복잡성이 높아질수록 그에 따른 비용도 증가한다. 대신, 물리적 저장이 아니기 때문에 직접 저장에 대한 비용이 적다.
정리하자면, Materialized view 의 경우 업데이트가 자주 이루어지지 않으면서, 다룰 데이터의 쿼리가 복잡한 경우에 사용하면 좋고,
view의 경우에는 쿼리의 복잡성이 낮아서 자주 실행이 되어도 괜찮을 경우에 좋은 차이를 보인다.
문제는, 내가 사용하는 것은
데이터가 크고 자주 변경이 되면서도, 실행 쿼리가 복잡하다는 것이다. 그러면 어떤 방법이 있을까? 생각하다가 그 무엇도 아니라 그냥 테이블을 만드는 것으로 결론을 지었다. 그래야만 모든 것을 충족시킬 수 있으면서도, 적당한 타협이 가능하다. 대신, 함수를 사용하여 데이터를 업데이트한 후 해당하는 테이블에 업데이트된 데이터에 맞춰서 추가, 삭제, 변경이 이뤄질 수 있도록 하는 것이다. 물론, 이것은 지금 당장 하는 게 아니라 (DB 구조부터 다시 설계하기로 했기 때문에 ^^;) 후에 생각할 일이지만, 이번 일을 통해서 view 와 Materialized view 의 차이는 명확하게 이해한 것 같다...
