Cộng đồng Hỏi & Đáp của Inflearn

감사합니다. 저도 좀 찾아보니 빈번하게 변경하는 필드가 아니고, 해당 필드를 filter 등으로 조건으로 사용을 자주하는 경우라면 db_index를 True로 주는게 좋다고 하네요.

ORM에서 필드마다 index를 자동으로 생성하는 것 같은데, 이 경우 필드가 업데이트 되면 index 값도 변경 될 것 같은데 맞을까요?

db_index=True 지정을 하시면, 장고에서는 데이터베이스 마이그레이션 과정 (makemigrations 명령과 migrate 명령)에서 해당 테이블/컬럼 생성 시에 CREATE TABLE 쿼리 외에 CREATE INDEX 쿼리를 추가로 수행해줍니다.

그럼, ORM 사용하시거나 직접 SQL 쿼리를 수행하시더라도 해당 컬럼 값의 변화가 있을 때, 데이터베이스 단에서 자동으로 index가 자동으로 갱신됩니다. 즉 데이터베이스의 인덱스 생성을 ORM에서 수행해주는 것은 아닙니다. 마이그레이션 과정에만 참여합니다.

db_index=True 설정은 단일 컬럼에 대해서만 인덱스를 생성하는 것이구요. 한 번에 여러 컬럼에 대해서 조회를 하실 때에는 그때 사용할 "여러 컬럼"에 대해서 인덱스 생성이 필요하실 수 있습니다. 이때에는 모델에 Meta.indexes 설정을 사용하구요. 단일 컬럼 인덱스에서도 db_index=True보다 Meta.indexes 설정을 사용하시면, 보다 디테일하게 인덱스 설정을 하실 수 있습니다. :-)

팁 감사합니다^^

추가적으로 궁금한 사항이 있습니다.

1. 컬럼 값이 자주 변하는 필드라면 db_index를 설정하지 않는게 좋을 것 같은데, 혹시 그 기준이 있을까요?

예상되는 비율이 갱신:조회 비율이 1:10보다 낮을 경우 라던지,

2. 특별한 기준이 없다면 직감적으로 값의 변경이 거의 없을 것 같고 조건 절로 자주 사용될 만한 필드들이라면 지정을 하고 향후 오버헤드가 생기는 경우에 대응을 하시는 편인가요?

3. 추가로 오버헤드가 발생할 때 실서버에서 쉽게 포착할 수 있는 툴이나 서드파티 패키지가 있을까요?

컬럼 값의 변경 빈도보다 데이터 양이 중요한 포인트라고 생각하구요. 데이터 양이 아주 많은 경우, Full Table Scan이 아니라 Index Scan이 더 빠르게 조회가 될 경우 인덱스가 필요하겠구요.

한 테이블에서 너무 많은 컬럼에 대해서 여러 인덱스를 잡게 되면, 인덱스 생성 비용이 많이 들어가, 인덱스 저장 공간도 소모될테니깐요. (인덱스도 별도의 테이블로 보실 수 있습니다.) Trade off가 있구요. 필요한 만큼만 인덱스를 생성하셔야하실 것입니다.

장고 View를 통해 매 페이지가 렌더링될 때 django-debug-toolbar를 통해서도 그 페이지가 렌더링될 때 사용된 쿼리의 종류와 개수, 실행계획을 확인하실 수 있으니까, 꼭 확인이 필요합니다.

데이터베이스에서 slow query 로그를 확인하실 수도 있겠구요. APM (애플리케이션 성능 모니터링) 서비스를 사용하시면, 장고 애플리케이션과 데이터베이스, nginx 에서의 성능을 통합적으로 모니터링하실 수 있습니다. data dog, newrelic, sentry 등의 서비스가 있습니다.

감사합니다. 많은 도움 되었습니다.ㅎ