서론
★혹시 좋은 의견이 있으시다면 댓글로 좀 알려주시면 감사하겠습니다.. 초보 개발자에게 한줄기 빛을..
토이 프로젝트의 방향이 결국 리그오브레전드 챔피언들의 모의 투자 로 방향성이 잡혔다.
https://developer.riotgames.com/docs/lol
위의 라이엇 공식 docs에서 챔피언 및 관련 정보를 확인할 수 있고 원하는 데이터를 사용할 수 있음
현재 포스팅하는 2023년 08월 11일 기준 챔피언 개수는 총 164개이며, 분 단위의 차트를 생성한다고 가정했을 때
분 단위로 기록해야하는 챔피언의 가격정보는 총 9,840개(164 * 60)이며
이를 일 단위로 환산했을 때 236,160건의 데이터가, 월 단위로는 700만 건의 데이터가 생성되게 되는데
처음 겪는 일이기 때문에 이를 어떻게 다루어 프로젝트에 적용시켜야 하는지 방향성을 잡기 위한 포스팅이 되겠다.
생각의 변화나, 좋은 방향으로의 학습 혹은 진행 상황이 개선된다면 포스팅을 주기적으로 업데이트 하도록 하겠다.
본론
현재 챔피언과, 챔피언 로그에 대한 테이블은 아래와 같다.
현재 테이블 구성이며, ChampionPriceLog에서 가격 변동에 대한 데이터를 관리하고자 했다.
(23.08.11)
하지만 대량의 데이터를 적재적소 핸들링하며 개발을 해 본 경험이 전무하기 때문에 세 가지 방향을 생각하고 있다.
1. 현 상황 유지
2. 가격 정보에 대한 DB를 새로 생성한 뒤, 일 단위의 테이블을 매번 생성 후 관리 (PriceLog230811)
3. 로그를 파일로 관리하고, 내 프로젝트에서 가장 중요한 매 09:00의 가격 정보만 PriceLog에 담는다.
1번의 장점은 한 테이블에서 모든 조회가 가능하다보니 조건에 원하는 조회 시간대만 잘 입력하면 되겠지만, 위에서 언급했듯이 2달만 지나도 1400만건의 데이터가 들어있을 것이고, 1년이면 7천만건...
인덱스를 적절하게 생성했지만, row가 늘어남에 따라 해당 테이블이 어떻게 될 지 잘 모르겠다. 아직 학습해야하는 부분인 것 같다.
2번의 경우 파티셔닝이라고 생각해도 무방할 것 같았다. 2번의 문제는, 과연 일 단위로 테이블을 생성하는 것에서 부터 시작됐다. 테이블 생성을 서버단의 코드에서 작성을 해야할지, 사용하는 DB의 이벤트 스케줄러를 통해 생성해주어야 하는지에서부터 두 가지의 정확한 장단점을 파악하지 못했다.
3번의 경우, 속도 측면에서 괜찮을 것 같다고 생각했지만 치명적인 단점이 있다. 로그 파일이 날아가면 차트를 구현할 수 가 없다. 다른 장단점들도 분명 존재하겠지만, 치명적인 단점이 있어 생각을 멈췄다.
논외로 모든 경우에서, 서버가 죽어버린다면? 과연 어떻게 구현해야 가장 관리가 용이하고 유지보수 또한 쉬울까에 대한 고민을 계속 하고있는 중이다.
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!