🔗 nested_serializer에 대해 썼던 이전 게시글 참조

nested_serializer를 쓰게 되면 성능저하 문제가 일어난다는 사실을 알게 되었다. 해당 사항에 대해 알아보자.

N+1 Problem

DRF를 사용하면 Rest API를 손쉽게 구현할 수 있다. 하지만 많은 것을 제공한다는 것은 내부적으로 처리가 많다는 뜻이므로 이는 때때로 성능저하를 일으킬 수 있다.

N+1 Problem : 쿼리 1번으로 n건의 데이터를 가져왔는데, 데이터를 얻기 위해 이 n건의 데이터를 데이터 수 만큼 반복해서 2차적으로 쿼리를 수행하는 문제
ex) 전체 게시글 n개의 목록을 얻기 위한 쿼리 1회
게시글 작성자의 이름을 얻기위한 쿼리 n회

위와 같은 로직은 성능 면에서는 비효율적이지만, 로직을 이해하기 쉽다는 장점이 있다.

DRF에서의 문제

Django ORM 또한 다른 ORM들과 마찬가지로 lazy-loading 방식을 사용함.
(lazy-loading : ORM에서 명령을 실행할 때 마다 데이터 베이스에서 데이터를 가져오는 것이 아닌, 모든 명령 처리가 끝나고 데이터를 가져와야 할 시점이 되었을 때 데이터 베이스에 쿼리를 실행하는 방식)

장점 : 매 단계마다 쿼리를 실행하지 않으므로 쿼리 요청 최소화

그러나 nested_serializer의 경우, 요청되는 data 수가 많아질수록 성능에 악역향. 요청되는 쿼리 수가 너무 많아짐.

해결

Eager Loading

: lazy-loading의 반대 개념. 사전에 쓸 데이터를 포함하여 쿼리를 날리기 때문에 늘어나는 쿼리 요청을 효율적으로 사전에 방지 가능

: lazy-loading의 경우 쿼리 요청을 할 때 어떤 데이터를 필요로 하는지 모르기 때문에 하나하나 쿼리 요청을 보냄
: eager-loading의 경우 어떤 데이터를 쓸 건지 미리 알려줌으로써 쿼리 최소화.

Django ORM에 Eager-loading 적용

: prefetch_related
: selected_related