PMPV

2020.07.17 새 프로젝트를 시작하면서 파이썬 3.8, 장고 3.0을 선택했다. 선택한 이유는 두 가지였다. - 현재 가장 안정화된 최신 버전을 사용해서 버전업 시기를 최대한 늦추자. - 버전 관리를 해보자! 사실 대단한 목적은 없었고, 두 번째가 99%의 이유였다. 지금껏 라이브러리나 프레임워크를 사용하면서 버전에 크게 신경쓴 적이 없었는데 이번엔 의도적으로 가장 최신 버전을 사용했다. 그로 인해 생기는 구 버전 라이브러리의 충돌이나 새로 릴리즈 된 기능들을 찾아쓰는 경험을 하고 싶었다. 이 글에서 장고 3.0에서 발생하는 구 버전 라이브러리의 충돌을 정리한다. 1. Django Rest Swagger 스웨거에 대한 설명은 생략한다. Django-Rest-Framework(DRF)를 세팅하면서 알..

또 다시 데이터가 늘었다. Factory boy를 사용해 400만 건 이상의 Post, 마찬가지로 수백만 건 이상의 Comment, Like를 추가하는데 30시간 이상이 걸렸다. 뭔가 이것도 실행 시간을 줄일 방법이 있지 않을까 싶다. 목표치였던 1억건의 Post는 현실적으로 불가능할 것 같아서 현재 데이터로 만족하기로 했다. 앞으로 데이터가 더 늘어날 일은 없을 듯 하다. 추가적으로 예상과 다르게 3번까지 늘어난 글을 보면서 나중에 불필요한 부분을 덜어내고 한 편의 글로 정리해야겠다는 생각을 했다. 우선 현 상황에 대해 다시 작성한다. 생각보다 쿼리 타임은 크게 늘어난 것 같지 않다. 대신 페이지네이션 부분에서 로드가 커졌다. 3번째 줄에 나타난 쿼리는 아래와 같다. 페이지네이션은 구글 검색을 통해 가..

당황스러운 결과가 나왔다. 코드를 뜯어 고치기 위해 레포를 새로 팠고, 데이터를 조금 추가했다. Post는 17만, Comment는 93만, Like는 170만, User는 280만 정도가 된다. 이전 포스팅에서 300ms 정도로 측정되던 속도가 1초 가량으로 올라갔다. 데이터의 양에 많은 영향을 받는다는 것을 확인할 수 있고, 데이터의 양이 이보다 훨씬 늘어난다면 (Post가 1억개 이상, Like는 30억개 이상) 더 많은 부하가 걸릴 것이라는 느낌이 들었다. 아무튼, 쿼리 요청을 처음부터 재설계하다가 확인한 부분인데.. 가장 기초가 되는 쿼리이다. SELECT * FROM "board_post" 형식. 여기에 N+1을 방지하기 위해 base_user 테이블의 정보를 select related 메서드..