-
Notifications
You must be signed in to change notification settings - Fork 4
Description
💡 Description
전체적인 프로젝트에 대해 하나의 DB를 사용하는게 관리측면에서 훨씬 간편하다
RDBMS과 NoSQL의 차이점을 생각해 볼 필요가있다.
NoSQL vs RDBMS
현재 프로젝트는 MariaDB 즉 RDBMS을 사용해서
Member를 생성하고 Member가 생성하는 Report와 Image를 따로 관리한다.
이런식으로
OrderBy를 이요한 Sorting,
Group By를 이요한 Grouping ,
Join 을 이용한 개체간 Relationship 정의
에 대해서 명확하기 구분하기 위해 RDBMS을 사용한다.
하지만 실시간으로 채팅메시지가 많이 생성되고 저장이 될텐데
여러개의 Join로직이 첨가된 객체들이 생성되고 저장된다면
쿼리성능이 저하될 것이다.
NoSQL의 데이터 모델링 패턴
비정규화 , 데이터중복 : Denormalization
채팅기능에서는 User의 ChatMessage, User, ChatRoom 의 정보에 대해서 저장하고있습니다. RDMS를 사용할때는 이런 정보를 쿼리할때 JOIN연산을 통해 데이터를 결합해 하는데 하지만 MongoDB에서 denormalization을 통해 하나의 문서에 대한 모든 관련정보를 중복해서 저장한다.
이렇게되면 쿼리의 복잡도가 감소하고 데이터 접근속도도 빨라진다.
사용자가 채팅방에 입장할때 한번의 쿼리로 모든 정보를 빠르게 로드할수있다.
하지만 데이터 중복으로인해 저장공간이 필요하고 데이터 일관성유지는 되지않는 특징이 있다. 하지만 메시지는 데이터가 일반적으로 변경되지않으므로 채팅메시지에 MongoDB를 사용하는게 적합하다
예를 들어보면 채팅메시지에 다음항목이 포함된다고 한다.
public class ChatMessage {
private String chatRoomId;
private String content;
private String senderId;
private String recipientId;
private String senderProfileImageUrl;
}
여기에서 우리는 senderId, recipientId, imageUrl에 대한 각 메시지의 사용자의 정보를 중복해서 저장하는데 이렇게 함으로써 메시지를 조회할때 추가적인 User정보를 얻기위해 별도로 Join 쿼리없이 필요한 정보를 한번에 받을수있습니다.
채팅메시지를 로드할때 각 메시지에 정보가 이미 포함되어있기때문에 성능이 향상된다. 하지만 단점은 사용자의 프로필사진이 변경되면 모든 관련 메시지를 업데이트해야하는 데이터 일관성문제가 발생할수있다
왜 하필 MongoDB를 선택했나요?
- 빠른 쿼리속도 : Denormalization 비정규화를 통해 쿼리 복잡도 감소
- Join 연산없이 빠르게 정보 제공
- Document-oriented 데이터 모델
- 정형화되지않은 데이터 구조 지원 -> 새로운 데이터필도 추가, 변경 용이
- 다른 NoSQL들과의 비교
- Cassandra : 강력한 일관성을 제공하지만 MongoDB는 더 빠른 읽기/쓰기 성능을 제공한다. 메시지,사용자정보, 채팅방정보를 별도의 테이블에 저장한다. 복잡한 데이터 모델에 더 적합하고 MongoDB는 유연한 데이터 구조를 지원한다.
- Redis : 키-값 저장소 이기때문에 데이터 모델링 기능이 제한적이다. -> 메시지 내용만 저장하고 데이터 분석이 어렵다 하지만 MongoDB는 문서기반 데이터베이스로서 메시지내용, 사용자정보, 시간정보를 함께 저장할수있다.
🚗 Todo
- 채팅방 입장 ( 만약 채팅방이 존재하지않으면 채팅방을 한뒤 입장 )
- 웹소켓 통신 구현
## 📚 References https://bcho.tistory.com/666 https://velog.io/@murphytklee/%EC%B1%84%ED%8C%85-%EC%8B%9C%EC%8A%A4%ED%85%9C-NoSQL-%ED%8A%B9%EC%84%B1-%EB%B0%8F-%EB%B9%84%EA%B5%90-%EB%B6%84%EC%84%9D-CAP-PACELC