[View] 멍청하게 뷰를 쓰지 말자.

현재 운영중인 신 시스템에서 결제 프로세스를 만들었는데, 그간 쏠쏠하게 재미를 본 View를 이번기회에 대규모 데이터 처리에 어떤 퍼포먼스를 보여주는지 테스트를 해봤다. 

결과는 생각보다 엉망진창이었다.

가상으로 임의 생성한 결제 데이터는 대략 3,000개 정도이고, 테이블 조회시 사용자 데이터 조회와 부가 정보 조회를 위해 3개의 inner join이 들어갔다. 막판에 기획팀에서 전혀 다른 테이블에 있는 부가 상품조회도 넣어달라는 요청을 해서 동일한 방식으로 UNION을 구성 통째로 View를 만들었다.

View를 만들면서 고려한 사항은 기본적인 최적화 검증과 인덱싱을 했고, 문제로는 불특정 다수의 데이터를 조회할 때 검색조건이 없는채로 정보를 만들어야 한다는 것이다. 일단 조건을 정리하자면 다음과 같다.

• 기본 상품 결제 테이블에는 3,000개의 데이터가 들어있다.
• 부가 상품 결제 테이블에는 2,500개의 데이터가 들어있다.
• 각각 상품 테이블을 긁어올때 사용자 정보와 상품 정보까지 불러오므로 각각 3개의 테이블을 join한다.
• 이후 union으로 2개의 조회 결과를 합쳐 한개의 뷰를 만든다.

이때 문제가 된게 조건절의 부재였다.(모든 데이터를 조회해라 닝겐)

결국 초반에는 잘 돌아가던 View가 데이터의 양이 많아지고, 동일한 정보를 다중으로 조회하여 그 안에있는 데이터를 추출해야하는 문제가 생기고나니 결국 페이지 로딩이 5초까지 늘어지는 문제가 발생했다.

결국 쿼리캐싱이나 별짓을 다해봐도 영 깔끔하지가 않아 php로 쿼리를 직접 만들어서 날리게 했는데,

큰 수정없이 쿼리빌딩 프로세스만 잘 다듬어서 삽입했더니 0.4초 이내로 다시 속도가 좋아졌다.

어쨌든 편한 기능이지만 그만큼 퍼포먼스가 기대했던 것 보다 좋지 못했다는게 첫번째 소감이고, 두번째로는 데이터가 많이 생길 테이블이라면 멍청하게 조건절 안걸고 View를 만들지 말자. 내가 생각해도 좀 멍청했다.