Two Scoops of Django - #7장

이번장은 쿼리와 데이터베이스 레이어에 대한 내용이다.

ORM은 각기 다른 테이터를 데이터베이스에 독립된 형태로 객체화하며 생성된 객체에 상호 작용할 수 있는 메서드 세트를 제공한다.

여기에는 장고 ORM을 사용하는데 팁을 제공하는 듯하다.

 

1. 단일 객체에서 get() 대신 get_object_or_404() 이용 - 다만 view에서만 사용

2. 예외를 일으킬 수 있는 쿼리 주의

 - ObjectDoesNotExist는 어떤 모델에도 사용 가능하나 DoesNotExist는 특정 모델에만 사용 가능

 - 여러 객체 반환 시 MultipleObjectsReturned

3. 쿼리를 좀 더 명확하게 하기 위해 지연 연산 이용

 - 지연 연산 : 데이터가 정말로 필요하기 전까지는 장고가 SQL 호출하지 않음. 그러므로 ORM 메서드와 함수를 얼마든지 원하는 대로 연결해서 코드를 쓸 수 있으며 실행 전까지 장고 실제 DB에 연동되지 않음. 결과적으로 쿼리 체인을 한 줄에 너무 길게 작성할 필요가 없다는 얘기.

4. 고급 쿼리 도구 이용하기

 - 쿼리 요청 세트를 파이썬에서 다시 다듬어야 하는 경우도 생기는데, 그전에 장고의 고급 쿼리 도구를 사용해서 데이터베이스를 통한 데이터 가공을 시도할 수 있다. 성능 향상 및 파이썬 기반 데이터 가공보다 더 잘 테스트되어 나온 코드를 활용한다는 이점이 있다.

 - 직접 for 문을 쓰는 등의 로직을 활용하지 않고 filter 식 등을 이용해서 쿼리에서 로직이 수행되어 나올 수 있게 수정 가능하다.

 - 데이터 베이스 함수들(UPPER(), LOWER(), COALESCE(), CONCAT(), LENGTH(), SUBSTR())등을 활용하라. 장고 ORM에서는 DB별로 다르지 않고 동일하게 통합해 놓았기에 재활용에도 용이하다.

5. 필수 불가결한 상황이 아니면 RAW SQL은 쓰지 말 것.

 - 그냥 안 쓰는 방향으로. 사실 장고 ORM을 사용 안 하면 장고 자체를 쓸 이유가 있나.. 싶은 부분도 있고.

 - RAW SQL 사용 시 발생할 수 있는 문제 : 유효성 검사, 보안 제공받지 못함. 앱의 이식성이 떨어질 수 있음. 마이그레이션 시 이슈 있을 수 있음.

6. 필요에 따라서만 인덱스를 이용. 마구잡이로 다 넣지 말 것

 - db_index=True 필드를 추가하는 건 간단하지만, 항상 왜/어떤 상황에서 추가해야 하는지 꼭 판단해서 쓸 것. 저자가 선호화는 방식은 처음에는 인덱스 없이 시작 -> 필요에 따라 하나하나씩 추가하는 방식.

 - 인덱스가 필요한 상황 : 인덱스가 빈번하게(모든 쿼리의 10-25% 사이에서) 이용될 때. 실제 데이터 또는 실제와 비슷한 데이터가 존재해서 인덱싱 결과에 대한 분석 가능할 때. 인덱싱을 통해 성능이 향상되는지 테스트 가능할 때.

7. 트랜잭션에 유의

 - 트랜잭션 : 원자성, 일관성, 독립성, 지속성을 가져야 하며 둘 또는 그 이상의 데이터베이스 업데이트를 단일화한 작업으로 처리함을 의미

 - 각각의 HTTP 요청을 트랜잭션으로 처리 : 성능 저하의 이슈가 있을 수 있지만 모든 DB 쿼리가 보호되는 안정성을 얻을 수 있음. 혹은 with transaction.atomic():을 활용하는 방향도 있다.

- 명시적인 트랜잭션 선언 : 트랜젝션에서 어떤 뷰와 비즈니스 로직이 하나로 엮여 있고, 어떤 것이 그렇지 않은지 명시해주는 것. 개발 시 더 많은 시간을 요구하는 단점 존재. DB에 변경이 생기지 않는 것은 논 트랜잭션으로, 생기는 것들은 트랜잭션으로 처리.

- django.http.StreamingHttpResponse와 트랜잭션 : response가 시작되면 트랜잭션 에러를 중간에 처리하기는 불가능.

- MySQL에서의 트랜잭션 : 만약 트랜잭션이 지원되지 않는다면 장고는 ATOMIC_REQUESTS나 트랜잭션을 지원하도록 쓰인 코드에 상관없이 늘 오토 커밋 모드로 동작.