[Seminar] 7차 과제

[kbt82883]

🔥Pull requests

👷 과제 구현

필수과제

• 아티클 댓글 기능 추가 (CRUD, 댓글 작성 및 수정시 300자 제한, 유저 정보 연결)
• 게시글 상세조회시 댓글 리스트도 조회

선택과제

• 캐싱으로 성능 최적화
• 대용량 데이터 처리 및 정렬 최적화 (인덱싱)
• 인프라 설계 시각화
• 테스트 코드 도입

구현한 내용에 대해서 설명해주세요

• 기존 아티클 기능에 댓글 기능을 확장하였고, CRUD와 게시글 상세 조회 스펙을 확장했습니다.
• 댓글 300자 제한은 DTO 단에서 Bean Validation을 적용하여, 컨트롤러나 서비스 로직에 불필요한 검증 코드가 들어가지 않도록 했습니다.

구현하며 고민했던 내용을 적어주세요 (사소한 것도 좋아요)

• 댓글 삭제시 연관 데이터의 무결성을 유지하기에는 Soft Delete가 더 안전하다고 판단하였습니다.
• 인증 정보 처리 방식으로는 지난 세미나 실습으로 사용했던 코드를 살려, JWT 기반 인증 방식을 사용했습니다.
• 클라이언트에서 Authorization: Bearer {token} 헤더를 통해 인증 정보를 전달한다는 가정하에 임시로 인증 기능을 작성했습니다.
• 댓글이 더욱 많아질 경우엔 페이징 또는 별도의 API로 분리하는 방향으로 확장을 고려할 수 있을 것 같습니다.
• 데이터가 많을 경우 테이블을 풀스캔하여 O(N)의 시간복잡도로 꽤나 병목사항이 될 수 있습니다. B-Tree 기반으로 인덱스 탐색할 경우 조건에 해당하는 범위를 찾고 스캔하는 방식으로 성능에 많은 도움이 될 수 있을 것 같습니다.
• 인덱싱이 필요한 API는 모든 아티클 조회와 게시글 상세 조회 (댓글 리스트 포함)이 될 것 같습니다. 인덱스가 있다면 모든 아티클 조회시 createdAt 기준 인덱싱을 하여 최신순으로 정렬된 상태로 필요한 구간만 읽을 수 있습니다. (페이지 네이션) 또한 comments의 article_id로 필터링 + is_deleted=false 필터링한 후에 createdAt 정렬하여 조회하는 방식으로 인덱싱하면 성능 효율이 좋을 것 같습니다.
• 다만, 생성, 수정, 삭제시마다 인덱스도 함께 갱신되기 때문에 쓰기 성능이 약화될 것 같습니다. 또한, 인덱스를 저장할 디스크 공간이 필요할 뿐더러, DB 옵티마이저가 인덱스를 선택하는 과정, 주기적으로 통계 갱신하는 등을 모두 고려하는 운영 및 유지보수가 필요할 것 같습니다.

---

키워드 과제 정리내용

---

🚨 참고 사항