PMPV

또 다시 데이터가 늘었다. 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 메서드..

2019.12.29, 현재 작성 중인 글입니다. 계속 업데이트될 예정입니다. 기초적인 웹 게시판을 만들었다. 포스트 테이블을 기반으로 User, Like, Comment, Hitcount 등의 기능이 있는 가장 기초적이고 보편적인 형태의 BBS이다. ERD를 보자. Comment와 Like는 Post 테이블 뿐만 아니라 다른 테이블도 범용적으로 바라볼 수 있는 FK를 가져야 한다. 따라서 장고의 Generic Relation을 사용했다. Content Type 테이블에는 장고 프로젝트의 모든 앱과 모델의 정보가 저장되어 있다. Generic Relation은 타겟이 되는 객체의 Content Type과 Object id를 저장해 해당 객체가 어떤 객체를 참조하는지 알 수 있다. 구현하고 싶은 비주얼은 아..

개인적으로 도커를 사용한 경험은 두 번이었다. 언제였냐면 1. 전 회사에서 한 번 Django+GraphQL 프로젝트였다. 개발 환경을 세팅할 때 docker-compose를 이용해 postgresQL, AWS X ray, ddb 등등의 컨테이너를 사용했다. 2. 당근마켓 프로그래머스 과제 개발 환경 세팅에서 Mysql Server, Rails Application을 모두 도커 컨테이너로 띄웠다. Dockerfile, dockerignore 등을 처음 봤다. 당근마켓의 사례를 접하고 도커에 대해 처음부터 공부 중이다. 생각해보니 내가 작업하는 모든 장고 프로젝트의 환경 세팅을 도커를 이용하면 멋질거 같아서 시도를 해봤다. 약 일주일, 다음과 같은 문제를 만났다. 1. 도커의 아키텍처가 너무 어렵다. 레이..

오랜만에 티스토리에 글을 작성한다. 지금 나는 멋사를 퇴사한 후 오랜 시간 생각 정리라는 핑계로 늘어지게 놀고 다시 구직 활동을 하고 있다. 구직 활동을 진행하며 포트폴리오의 필요성을 다시 한 번 느끼게 되었고, 통상적인 10장 내외의 pdf 파일로는 개발 이력을 모두 담아내기 어렵다는 것 또한 느끼고 있다. 이를 개선하기 위해 오랜만에 블로그를 다시 찾았고 개발 일기의 목적은 두 가지다. 1) 포트폴리오에 소개될 프로젝트의 A to Z 2) 개발 학습 복기 간단한 이미지와 기술 스택 소개로는 개발자로서 자기 PR에 무리가 있다고 생각한다. 여기에는 어떤 과정을 통해서 프로젝트가 진행되었고 어떤 경험을 얻었는지에 대해 최대한 자세하게 서술할 예정이다. 또한 정말정말 간단한 메서드나 프레임워크의 구조에 대..

주로 사용하던 크롬 계정을 변경했다. 새로 추가된 계정에는 기존 계정에서 쓰던 북마크와 확장 프로그램이 모두 반영되지 않기 때문에 백업을 진행했다. 북마크의 경우에는 비교적 간편한 방법으로 손쉽게 진행할 수 있었는데, 확장 프로그램의 경우는 불친절한 사용성으로 고생을 했다. 이 과정을 블로그에 요약한다. 1. 불편하고 손이 많이 가는 방법 확장 프로그램을 백업하기 위해선 crx 파일이 필요하다. 생전 이름도 처음 들어보는 확장자 형식인데 크롬 익스텐션을 해당 파일 형식으로 압축해줘야 한다고 한다. 익스텐션을 압축하는 방법은 크롬에서 chrome://extensions 에서 확인할 수 있다. 상단에 확장 프로그램 압축을 선택해 해당 익스텐션의 경로를 넣어주면 crx 파일로 저장해준다. 예시는 다음과 같다...

0.늘 그렇듯 참고 자료 출처 먼저! 1) Squash and merge - 킹갓빛황의조올타임남바완존잘남 이동근2) Github issue - huskyhoochu.com - github 하나로 1인 개발 워크플로우 완성하기: 이론 편 지난주, 멋사 6기 해커톤을 진행하며 팀 늘카테의 프로젝트 "늘어진 카세트 테이프"가 거의(아마) 완성되었다.9월 중 완성과 배포를 목적으로 진행 중인데, 해커톤에서 경험했던 협업의 어려움과 개선 방안을 여기에 서술한다.팀원들의 깃 활용 수준은 지난 포스팅에 서술했던 내용까지였다. 이번에 경험한 어려움은 크게 다음과 같다. (1) 복잡하고 불필요해보이는 커밋 이력(2) 커밋 메세지만으로는 부족한 마일스톤 파악과 공유 위 두 에러사항을 한눈에 알 수 있는 상황은 다음과 같다..

7. Github Desktop지금까지 git commit, push, remote repozit, origin & upstream 등의 루틴을 알아보았습니다.개인적으로 깃의 러닝커브를 높이는 요인은 두 가지라고 생각합니다. 1. 가시성이 떨어집니다. add와 commit의 과정은 어떤 변경 내역이 어떻게 기록되는지 보기가 어렵습니다. push의 경우 깃허브 저장소에 올라가기 때문에 변경 내역을 직접 볼 수 있지만 commit log와 같은 내용은 커맨드라인에서 하나하나 확인하기가 힘듭니다. 심지어 협업의 경우, fetch, pull, merge 등은 복수의 저장소를 넘나드는 명령어이기 때문에 구조를 상상하는걸 방해한다고 할까요? 내가 어떤 작업을 하고 있는지 직관적으로 이해하기가 힘듭니다. 2. 커맨드..

2. remote repository우리는 이제 커밋과 푸시의 개념을 잡았습니다. 그리고 원격 저장소에 대한 개념을 잡았습니다.이번에는 이 깃허브의 원격 저장소를 이용해 협업을 하는 과정을 살펴보겠습니다. 깃허브에 가입한 사용자들은 각 계정에 소속된 원격 저장소를 생성하고 관리할 수 있습니다.예를 들어, User라는 아이디를 가진 계정의 원격 저장소가 testApp, testGit 이렇게 두 개라고 가정하면 이 원격 저장소의 주소는 다음과 같습니다. https://github.com/user/testapphttps://github.com/user/testgit 각각의 원격 저장소에는 권한을 가진 사용자가 푸시한 프로젝트가 들어있습니다. 협업을 할 때는 이 원격 저장소의 권한을 공유한다는 느낌으로 자신의 ..

0.깃은 어렵습니다.개인적으로 초반 러닝커브가 굉장히 높은 스킬이라고 생각합니다.특히 깃의 기본 개념보다는 협업을 위한 워크 플로우를 학습할 때가 난이도가 높습니다.협업을 위한 깃을 학습하며 느낀 점은, 정말 다양한 방법론이 있습니다. 개발자마다 선호하는 방식이 다르고 이는 비기너의 혼란을 야기합니다. 어떤 플로우를 선택해야할지, 이것과 저것은 어떻게 다른지 구별하기도 힘듭니다. 개인적으로 생각하는 깃을 학습하기 위한 가장 좋은 방법은 선배입니다. 능숙하게 사용하는 선배의 방법론을 그대로 흡수하는 것에는 방법론에 대한 고민이 필요없습니다. 여기에 협업을 위한 제 방법 한 가지를 서술합니다. 저에게도 아직 숙달된 방법이 아니고 이해가 부족한 개념이 중간중간 섞여있기 때문에 설명이 부족한 부분은 댓글로 질문..