본문 바로가기

Project/DB

 (4)
Redis / RedisTemplate 실험 프로젝트의 RefreshToken과 1:1채팅의 읽음 처리를 구현하기 위해 사용자가 소켓에 접속했는지 저장하기 위해 Redis를 사용하기로 했다. 사용자가 소켓에 접속했는지 관리하려면 소켓에 접속하고 나갈 때 마다 계속 데이터를 저장하고 삭제해줘야 하는데 RDBMS 보다 Redis에 저장하는 것이 더 효율적이라고 판단했으며 이전부터 Redis 라는 기술을 사용해보고 싶었다. 기존엔 구현하기 쉽다는 이유로 CrudRepository를 이용해 간단하게 구현했다. 하지만 CrudRepository를 사용하니 실제 Redis에 저장된 값들이 직관적이지 못 했으며 Transaction을 지원하지 않았다. @Getter @RedisHash(value = "refreshToken", timeToLive = 60480..
[Independe] 채팅 DB 설계에 대한 고민 자취생 커뮤니티 개발을 진행하며 1:1 채팅을 지원해야 하는 요구사항이 있었다. 채팅과 같은 실시간 데이터 송/수신이 필요한 기능은 데이터베이스를 어떻게 구축해야할지 몰라 고민도 많이 하고 검색도 많이 해봤다. 검색결과 많은 사람들이 채팅과 같은 기능은 채팅방 정보 채팅방 이름, 참여자들 정도만 RDBMS에 저장하고 메시지와 같은 데이터는 모두 redis나 mongodb와 같은 nosql을 사용하라 했다. 이유는 RDBMS에 경우 실시간 데이터 저장에 있어 성능이 좀 떨어진다는 말이 많았다. 하지만 RDBMS 설계도 완벽하지 않은 내가 Nosql 설계를 하려니 데이터를 어떻게 저장해야될지 감이 잘 잡히지 않았다. 많은 고민끝에 아직 RDBMS로 채팅을 구현했을 때 성능의 저하를 경험해보지 못 했기 때문에..
[Independe] 추천, 신고, 즐겨찾기 DB 설계에 대한 고민 자취생 커뮤니티 개발을 하며 게시글, 댓글에 대해 추천, 신고, 즐겨찾기와 같은 요구사항이 발생했다. 처음엔 해당 기능들은 다 게시글과 1 : N 관계로 구축하면 되겠다고 쉽게 생각했다. 하지만 1 : N으로 맵핑한 뒤 구현을 할 수록 이상함이 느껴졌다. 추천은 '회원이 게시글을 추천한다' 그렇다면 추천이라는 테이블엔 회원, 게시글에 대한 정보가 모두 존재해야 한다. 또한, 한명의 회원은 여러개의 게시글에 추천을 할 수 있고 하나의 게시글 또한 여러명의 회원에게 추천을 받을 수 있다. 즉 1 : N이 아닌 N : M 다대다 관계로 구축해야 했다. 이 다음 발생한 고민이 추천, 신고, 즐겨찾기는 결국 boolean 값으로 isRecommend, isReport, isFavorite과 같이 컬럼에 저장되는데..
[Independe] 대댓글 설계에 대한 고민 자취생 커뮤니티를 개발하며 댓글과 대댓글에 대한 요구사항이 있었다. 난 단순히 댓글 테이블과 대댓글 테이블을 따로 두어 1 : N 관계를 맺으면 될것이라 판단했다. 그러나 구글링을 통해 다른 개발자분들이 대댓글을 구현한 것을 보니 모두 계층형 구조를 가져갔다. 계층형 구조 자체는 이해하기 수월했지만 구현된 코드를 보니 다소 이해하기 난해했다. 하지만 많은 개발자분들이 작성해주신 예제들을 이용해 직접 구현해보며 코드를 이해할 수 있었다. @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) // protected 기본 생성자 public class Comment extends BaseEntity { @Id @GeneratedValue @Co..

티스토리툴바