하지만 편하다고 아무렇게나 코딩을 하게 되면 골치아픈 상황들이 여럿 발생합니다.
프레임워크에서 어떤 SQL을 생성하는지, 각 쿼리들은 속도가 어떠한지 꾸준히 확인을 해 줘야합니다.
이 포스팅은 제가 정말 생각없이 코딩을 하게 되어서 겪은 여러가지 상황을 정리한 것입니다.
#1. N+1 문제
흔히 말하는 N+1 케이스입니다.
멀쩡해 보이는 코드지만.. 날아가는 쿼리가.. 대략.. 이렇습니다...-_-
Eager Loading 으로 해결가능 합니다만..
Eager Loading 으로 쿼리의 수는 1개로 확실히 적어지지만, 항상 성능이 좋아지는 것은 아닙니다.
자세한 건 이 글 을 참고하시면 좋겠습니다.
덧붙여서 윗글의 정보와는 달리 현재 Edgerails 에서는 :preload 옵션이 없고 :include 를 사용해도,
preload 가 가능한 경우는 Eager Loading이 아니라 Preload 를 하도록 패치되어 있습니다.
#2. Find conditions 에 시간을 사용할 경우는 한 번 더 생각을...
얼마전 테스트를 하다가 우연히 발견했습니다.
어느 쪽이 더 빠를까요? 당연히 테이블 전체를 가져오는 1번보다 2번이라고 생각하기 쉽습니다.
그런데 실제로 해보면 예상치 못한 결과가 나오더군요.
첫번째 호출할 때는 2번이 빠른데.. 두번째 이상 호출을 하게 될 경우, 1번이 훨씬 빠릅니다.
답은 각자 생성하는 쿼리에 있었습니다.
1의 경우는
로 처음이나 두번째 호출 후나 일정한 반면에..
2의 경우는
처럼 초단위가 변해서 쿼리가 날아갑니다.
한마디로 쿼리 캐시가 안되고 계속 새로운 쿼리를 보내는 것이죠.
아마 1초단위 까지 정확히 하루 전이라고 하고 싶으면 어쩔 수 없겠지만..
초단위 혹은 분단위를 올림/내림 등을 하는 것만으로도 쿼리 캐시의 효과를 잘 이용할 수 있게 될 겁니다.
#3. Pagination 의 함정.
이번엔 페이지를 나누는 Pagination 에서 생기는 문제입니다.
레일스 2.0 에서는 Pagination이 레일스 코어에서 빠지고 플러그인 식으로 설치를 해야 하는데..
제가 설치해 본 대부분의 Pagination 플러그인이 같은 문제를 가지고 있었습니다.
Pagination의 동작은 크게 두 부분으로 나눌 수 있습니다.
페이지 표시를 위해 전체 레코드 수를 가져오는 것과 페이지 번호를 이용해 :offset 과 :limit 으로 특정 부분의 레코드를 가져오는 부분입니다.
Pagination 의 플러그인 중 하나인 will_paginate 같은 경우 다음과 같이 Paginate를 합니다.
find 의 옵션들을 그대로 쓸 수 있으므로 아주 편하게 paginate를 할 수 있습니다.
그런데 문제는 include 옵션이 들어가게 되면 문제가 발생합니다.
우선은 paginate 는 #1 에서 언급한 preload 가 구현이 되어 있지 않고..
두번째 문제는 전체 레코드 수를 가져오는 부분에서 쓸 데없는 Join 이 일어납니다.
위의 경우는.
와 같은 쿼리가 생성됩니다. 그런데, 위의 경우는 굳이 comments와 join 할 필요가 없고,
만약 join을 해아할 테이블이 훨씬 많아지면 오버헤드는 상상할 수 없을 정도로 커집니다.
단순히 레코드가 몇 개인지 세는 것 뿐인데 말이죠.
외국의 글입니다. 이 paginate 문제 의 해결책을 제시하고 있습니다만 count 를 하는 쿼리와 선택을 하는 쿼리를 직접 SQL 로 만들어서 하는 방식은 가장 유연한 방식이지만 그다지 깔끔해 보이진 않네요.
will_paginate 의 이슈 트래커에 정확히 같은 문제를 지적한 티켓이 올라왔군요.
이올린에 북마크하기
이올린에 추천하기
