[이룸] 채팅 내역 저장을 위한 db 선택

📌 내용 요약

• 채팅 내역 영구적 저장 필요
• 아래는 해결 방법. 러닝 커브에 따라 1~3차로 나누어 구현할 예정. 
  • 1차 : redis에서 ttl 설정을 빼고 aof와 rdb 추가
  • 2차: 3일까지의 데이터는 redis에,이후 데이터는 MySQL에 저장
  • 3차: 3일까지의 데이터는 redis에,이후 데이터는 PostgreSQL에 저장

---

[문제]

• 현재 이룸에서는 채팅 내역을 저장할 때 인메모리 데이터베이스이지만 영구 저장이 가능하고 조회가 빠른 Redis를 사용한다.
• 채팅내역은 30일 TTL 설정을 걸고 있다. 그러나 서비스적으로 채팅 내역은 꼭 보관해야 할 소중한 데이터기 때문에 TTL 설정을 제거하고 채팅내역을 안전하게 영구보관할 방법을 강구해야 한다.
• Redis는 서버가 꺼지면 데이터도 날아간다. 따라서 데이터 지속을 위해 AOF나 RDB를 이용하여 데이터를 디스크에 저장한다. 하지만 데이터 양이 많아진다면 해당 파일의 크기가 지나치게 커지고 복구 시간도 오래 걸린다. 메모리는 비싼 자원이기 때문에 조회가 덜 되는 오래된 데이터는 디스크에 저장하는 것이 좋다.
• 또한 Redis는 채팅내역 조회와 같은 섬세한 조회에 적합하지 않다.
• 따라서 조회가 많이 되는 최근 며칠간의 채팅 데이터만 redis에 캐싱하고 그 이전 채팅은 영구 저장 및 조회가 쉽도록 db를 옮기려 한다. 이렇게 하면 최근 채팅 데이터에 빠르게 접근하면서, 동시에 오래된 채팅 데이터도 안전하게 보관할 수 있다.

[채팅 영구 저장 db 요구사항]

• spring과 호환성이 좋아야 한다
• 가격이 낮아야 한다
• 시간순으로 정렬해서 쿼리가 가능해야 한다.
• 많은 양의 데이터가 수시로 조회/생성이 가능해야 한다.
• 확장성이 좋아야 한다.

[고려한 옵션]

1. MySQL

 

   <장점>

• Spring Data JPA와 잘 통합되어 개발 용이
• 오픈 소스이므로 무료로 사용 가능
• 인덱스 활용한 시간 순 정렬 및 쿼리 가능
• read replicas를 통해 수평 확장이 가능하나, 쓰기 작업에 대한 확장은 제한적

   <단점>

• 대량의 실시간 읽기/쓰기 작업은 성능 저하 발생할 수 있음

2. PostgreSQL

 

    <장점>

• Spring과 호환성 좋음 + 무료 사용 + 시간순 정렬 가능
• Citus 등의 확장을 제공하여 수평 확장 가능
• 동시성 처리 등 다양한 기능을 통해 효율적으로 처리 가능

    <단점>

• 배우기 어렵고 관리가 복잡

3. MongoDB

 

    <장점>

• Spring Data MongoDB를 통해 쉽게 사용 가능
• 커뮤니티 버전은 무료
• document 지향적 접근 방식으로 시간순 데이터 처리 용이
• 대량의 데이터 처리 가능
• 자동 샤딩과 복제를 통해 높은 수준이 확장성 제공

    <단점>

• 배우기 어렵고 관리가 복잡

[선택한 DB]

• 이미 익숙한 JPA와 호환 가능하며, 무료이고, 시간순 처리가 가능하며, 대량의 데이터도 효율적으로 처리가 가능하며 확장성이 높은 PostgreSQL이 적합해 보임. 그러나 현재는 조회 기능만이 구현되어 있기 때문에 조회 처리 속도가 좋은 MySQL도 좋은 대안. 
• 따라서 1~3차로 나누어 프로젝트를 수정할 예정. 여력이 된다면 3차까지 가보는 걸로!
  1차 : redis에서 ttl 설정을 빼고 aof와 rdb 추가
  2차: 3일까지의 데이터는 redis에,이후 데이터는 MySQL에 저장
  3차: 3일까지의 데이터는 redis에,이후 데이터는 PostgreSQL에 저장