urls.py 파일에 작성한 코드 분리 여부

안녕하세요! 재밌게 들어주셔서 감사합니다 😄 파이썬에도 프로젝트가 커지면 service나 repository를 분리합니다. 다만 예시 프로젝트에서는 비지니스 로직이 복잡하지 않아서 따로 계층을 분리를 하지 않았습니다. 가장 마지막 강의에 매우 간단하게 service layer를 분리하는 강의가 있습니다.

레디스 사용관련 질문

안녕하세요 :) 해당 상황에서 안정성을 위해서라면 별도의 레디스 서버를 구축하는게 낫지만, 사이드 프로젝트를 위해 간단하게 구성한다면 같은 서버에 레디스를 띄울 수도 있습니다. 정답은 없고 컴퓨팅 자원을 어떻게 관리하고 운영할 것인지에 따라 결정하시면 될 것 같습니다!

pg_bigm으로 product의 name필드로 상품 검색

안녕하세요! 재밌고 듣고 계신다니 기쁘네요 😀 . 맞습니다. pg_bigm 사용시에는 별도의 trigger를 생성하지 않아도 자동으로 index에 반영됩니다.

product의 name 필드로 상품 검색시 생성한 gin index사용 여부

안녕하세요! 말씀 주신 테스트 상황이 데이터를 충분히 많이 생성한 상태에서 limit을 100개로 쿼리한 경우에 풀 스캔을 사용하였다는 말일까요? 데이터가 적은 경우에는 몇 개를 쿼리하든 풀 스캔을 사용할 확률이 높습니다. (정확한 임계치는 데이터베이스 엔진에서 결정하기 때문에 상황에 따라 달라집니다.) 데이터가 충분히 많은 경우에는 반대로 index를 활용할 확률이 높아집니다. 실제로 제가 실습에서 보여드린 예제에서도 실습 쿼리 문에 limit을 지정하진 않았지만 IDE에 의해서 자동으로 limit이 500으로 고정되어 있습니다! 예외적으로 데이터가 충분히 많더라도 전체를 전부 스캔하려고 하면 풀 스캔이 사용될 수도 있습니다.

Rate Limiter 예제에 대해 질문있습니다!

안녕하세요! 캐시 key 구성을 보면 {클라이언트 IP}:{요청 시각(분)} 으로 이루어져 있습니다. 해당 캐시는 1분 동안의 요청 횟수를 관리하는 데이터로 최대 1분 동안만 유효한 데이터입니다. 예시에서 현재 시각이 0시 10분이라고 가정 했을 때, 0시 10분부터 11분 이전까지의 1.1.1.1 IP로부터의 요청 횟수를 기록하고 있습니다. Fixed-window 방식에서는 11분이 되는 순간부터는 1.1.1.1:11 캐시에 새로 기록되기 시작하기 때문에 1.1.1.1:10 캐시는 더 이상 사용되지 않습니다. 정확히 남아있는 시간을 계산하여 expiry를 동적으로 지정하는 방법도 있지만, 예시에서는 고정적으로 캐시의 최대 유효 시간인 60초 후에 만료가 되도록 설계하였습니다. Key 구성에서 시(hour)를 기록하지 않는 이유 역시 1시간 뒤에 1시 10분이 되었을 때 1.1.1.1:10 key를 재활용 할 수 있기 때문입니다 :)