[Project] ERD 고찰

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

---

2024-08-09 ~ 2024-08-29 첫 번째 프로젝트

주말동안 프로젝트 목업과 ERD를 구상해오기로 하면서
다들 생각해보니 채팅방을 구현하기에는 프론트가 해야할 일이 너무 많아진다는 것이 문제였다.
주로 백엔드 과정으로 수업을 들었기에 다들 React로 어떻게 구현할 것인가에 대해서 고민이 많았는데
웹소켓을 진행하게 되면 서버 뿐만 아니라 리액트로도 웹소켓을 구현해야 했다.

스프링으로 웹소켓 구현하는 것은 간단하게 테스트 진행했는데 이 부분에서는 무리가 없었지만
리액트랑 같이 해야하기 때문에 조금 더 생각해봐야할 문제인 것 같다.

채팅 기능을 추후에 구현하고 mbti 테스트 부분을 직접 진행하고
mbti별 게시판을 16개 만드는 것으로 변경했다

이번 주말 동안 프로젝트의 목업과 ERD를 구상하기로 했고 팀원들과 회고하면서 논의한 결과,
채팅방 기능을 구현하는 데에 있어서 프론트엔드에서 해야 할 일이 너무 많아지는 것이 문제가 있었다.

1. 채팅 기능 구현의 어려움

우리 팀은 주로 백엔드 개발 과정을 중심으로 수업을 들었기에
프론트엔드, 특히 React로 채팅 기능을 어떻게 구현할지 고민이 많았다.
웹소켓기반의 채팅 기능을 구현하기 위해서는 서버뿐만 아니라 React에서도 웹소켓을 처리해야 했기 때문이다.

• 스프링으로 웹소켓을 구현하는 것은 간단하게 테스트를 진행했으며, 백엔드에서는 큰 문제가 없음을 확인했다.
• 지금 목업을 하면서 프론트에 주어진 일이 많은데 거기에 **웹소켓을 React와 연동하여 구현하는 과정에서 프론트엔드 개발의 복잡도가 급격히 증가하게 된다. 프론트엔드의 부담을 줄이기 위해 채팅 기능의 구현은 추후로 미루는 것이 좋겠다는 결론을 내리게 되었다.

2. 채팅 기능 대신 MBTI 테스트 및 게시판 기능 구현

채팅 기능을 추후에 구현하기로 결정하고, 프로젝트의 주요 기능을 MBTI 테스트와 MBTI별 게시판으로 전환했다.

• MBTI 테스트 기능
  • 사용자들의 MBTI 테스트를 직접 진행할 수 있도록 설계할 것
  • 테스트 결과를 바탕으로 사용자는 자신의 MBTI 점수를 상세하게 도출해내기로 했다.
• MBTI별 게시판
  • 각 MBTI 유형별로 16개의 게시판을 생성
  • 같은 MBTI 유형을 가진 사용자들이 소통할 수 있는 공간을 마련하여 사용자들이 자신과 비슷한 성향을 가진 사람들과 더 쉽게 교류할 수 있도록 할 것

DB 설계: 정규화, 비정규화, 그리고 인덱싱 전략

이번 프로젝트에서 ERD를 구상하면서 테이블이 20개가 넘는 복잡한 구조가 되었다.
게시글, 게임별로 각각 좋아요와 댓글 기능을 구현하고,
MBTI 테스트의 질문, 답변, 결과를 고려하다 보니 ERD가 복잡해졌다.
그 과정에서 비정규화와 인덱싱에 대한 피드백을 받았는데, 정리해보니 중요한 개념들이 많아
지금 정리하지 않으면 놓칠 것 같아 한번 정리하고자 한다.

1. 정규화와 비정규화

• 정규화(Normalization)
  • 데이터베이스 설계에서 데이터를 중복 없이 구조화하는 방법이다. 이를 통해데이터의 일관성을 유지하고 저장 공간을 효율적으로 사용할 수 있다. 보통 1차 정규형부터 3차 정규형까지 정규화를 진행하며, 각 단계에서 중복 데이터를 제거하고 테이블 간의 관계를 명확히 할 수 있다.
• 비정규화(Denormalization)
  • 성능 향상을 위해 의도적으로 중복 데이터를 허용하는 것입니다. 정규화된 구조는 데이터 일관성을 높이지만, 때로는 복잡한 조인(JOIN) 연산이 발생하여 조회 성능이 저하될 수 있다. 비정규화를 통해 테이블 간의 조인을 줄이고, 데이터 조회를 빠르게 할 수 있다.

2. 인덱싱(Indexing)

1. 인덱싱이란
   • 인덱싱은 테이블 내 특정 컬럼에 대한 검색 성능을 높이기 위해 사용하는 기술
   • 데이터베이스는 인덱스를 통해 빠르게 데이터를 검색할 수 있다.
   • 하지만, 잘못된 인덱스 설정은 오히려 성능 저하를 일으킬 수 있기 때문에 신중한 설계가 필요
2. 프로젝트의 ERD에서 적용 가능성
   • 현재 ERD에서 Member 테이블이 대부분의 엔티티와 관계를 맺고 있어, 조회 성능을 개선하기 위해 memberId 컬럼에 인덱싱을 적용하는 것이 좋다는 피드백을 받았다.
   • 인덱싱을 통해 조회 성능을 향상시키게 되면, 비정규화가 필요하지 않을 수 있다.

3. 비정규화 적용 사례: 좋아요와 댓글

이번 프로젝트에서 좋아요와 댓글 기능을 비정규화할지 고민했다.

• 댓글(Comment): 게시글을 조회할 때 댓글도 함께 조회되어야 하므로, 이 경우에는 조인 비용이 꽤 많이 들 수 있어서 댓글 테이블은 그대로 유지하기로 결정했다.
• 좋아요(Heart): 좋아요 기능은 사용자가 한 번에 많은 데이터를 요청하는 경우가 많지 않기 때문에, 비정규화하여 테이블 수를 줄이기로 결정했다. 이를 통해 데이터 구조를 단순화하고, 조회 성능을 향상시킬 수 있다.

4. 신고 기능 구현과 스케줄링

• 신고 기능 구현에 대한 고민

  • 신고된 사용자를 일정 기간 동안 활동 정지시키는 로직

    신고로 인해 관리자가 활동정지를 회원에게 적용하는 시간 부터 7일을

  • 스케줄링과 배치 처리를 활용하는 방법이 있다는 것을 알게 되었다.

• 스케줄링(Scheduling): 특정 시간마다 주기적으로 실행되는 작업을 설정할 수 있습니다. 예를 들어, 활동 정지 기간이 끝난 사용자의 상태를 갱신하는 작업을 스케줄링할 수 있다.
• 배치 처리(Batch Processing): 대량의 데이터를 한 번에 처리할 때 유용합니다. 예를 들어, 매일 자정에 정지된 사용자 상태를 일괄적으로 갱신하는 작업을 배치로 처리할 수 있습니다.

결론

정규화와 비정규화, 그리고 인덱싱 전략은 데이터베이스 설계에서 매우 중요한 요소로 생각된다.
이번 프로젝트에서 인덱싱을 통해 성능을 개선하고, 특정 테이블에 비정규화를 적용하여 조회 성능을 높이는 결정했다.
또한, 스케줄링과 배치 처리를 통해 사용자 상태를 효율적으로 관리할 수 있는 방법을 고려했다.

이 과정에서 알게된 것은 모든 상황에서 비정규화가 정답은 아니라는 점
그리고 각각의 경우에 맞는 적절한 전략을 선택하여 데이터베이스 성능을 최적화해야 한다는 것을 알게 되엇다.

Project 카테고리 내 다른 글 보러가기