면접 스터디 (1)

JM·2020년 8월 9일

1. select_related 와 prefetch_related 의 차이점과 이점

하나의 QuerySet을 가져올 때, 미리 related objects들까지 다 불러와주는 함수이다. 비록 query를 복잡하게 만들긴 하지만, 그렇게 불러온 data들은 모두 cache에 남아있게 되므로 DB에 다시 접근해야 하는 수고를 덜어줄 수 있다. 이렇게 두 함수 모두 DB에 접근하는 수를 줄여, performance를 향상시켜준다는 측면에서는 공통점이 있지만, 그 방식에는 차이점이 있다.

one-to-one과 single-valued relationships 관계에서 사용이 가능하고 1번의 쿼리로 related_objects도 가져온다.

many to many, foreign-key 등 가리지 않고 사용이 가능하고 main_query 실행 후 related_object에 대한 별도의 쿼리가 실행된다.

해당 내용을 한 번에 모두 가지고 오기 위해 호출해야 하는 횟수가 다르다.
select_related는 SQL 조인을 만들고 SELECT 문에 related_object를 포함시켜 한 번에 가져온다.
prefetch_related는 각 관계에 대해 별도의 쿼리를 수행하고 Django에서 쿼리에 대한 데이터를 결합한다.
1번의 쿼리를 수행하는 select_related가 더 빠른 속도를 보여주지만 사용할 수 있는 범위가 한정되어 있기 때문에 두 가지를 적절히 섞어 사용을 해야 한다.

SELECT 절에서 DISTINCT 사용을 피한다.(대신 WHERE EXIST 서브 쿼리 사용)
WHERE 절을 사용하여 쿼리의 결과셋을 제한한다.
WHERE 절 비교칼럼 데이터타입을 일치시킨다.
UNION보다는 UNION ALL을 사용하라.
Group by 사용 시 HAVING보단 WHERE절 조건 검색을 사용하라.
3개 이상의 테이블을 INNER JOIN 할 때는, 크기가 가장 큰 테이블을 FROM 절에 배치하고, INNER JOIN 절에는 남은 테이블을 작은 순서대로 배치하는 것이 좋다.
가능한 SQL Server 커서의 사용을 피한다.
테이블의 모든 컬럼이 아닌 필요한 컬럼의 레코드만 반환한다.

Row SQL이 빠르다. 이유는 Database와 상호작용할 수 있는 가장 빠른 native 언어이기 때문이다.
하지만 실제 서비스를 개발하는 입장에서 생산성이라는 부분을 다시 한번 생각해볼 필요가 있다.
이미지의 X축은 DB 모델의 복잡성, Y 축은 처리량 즉, 시스템의 트랜잭션 처리량을 나타낸다.
이를 보면 DB 모델들 간에 관계가 복잡한 함과 동시에 많은 양의 처리량을 필요로 할 경우 ORM을 사용하는 것이 개발 시간을 크게 단축하고 속도를 높일 수 있다.
그 이유는 ORM을 통해 DB를 쉽게 조작할 수 있기 때문이다.
ORM을 사용하는 것보다 SQL을 사용하는 것이 가장 빠른 방법이지만 대부분의 개발자는 SQL의 기초적인 수준(테이블과 뷰를 만드는 방법, 데이터를 선택하고 조인하는 방법, 데이터를 업데이트하고 삭제하는 방법을 의미)으로 알고 있으며 T-SQL, PL-SQL, 인덱스 및 그 효과에 대한 깊은 지식, 사용 방법 등등 SQL 지식이 풍부한 사람을 찾기가 훨씬 더 어려워진다.
이러한 부분들을 생각해 볼 때 일반적인 상황에서 더 높은 생산성을 보여주는 것은 ORM을 사용하는 방법일 수도 있다.

[참고]

IP(Internet Protocol)의 약자로 사전적 의미로는 인터넷상에서 독립적으로 운영되고 있는 통신망들을 서로 연결하는 규칙
[Protocol] 이란 컴퓨터 간에 정보를 주고받을 때의 통신방법에 대한 규칙과 약속
즉, 인터넷(네트워크 망) 사이에서 독립적(컴퓨터나 서버 등)끼리 연결하여 통신할 때
사용되는 규칙이라고 할 수 있다.
흔히 네트워크상에서 다른 컴퓨터와 구별될 수 있도록 고유번호를 의미한다.