MongoDb vs Aws Dynamodb (채팅 메세지 데이터 저장)

 

 

이전글에서 채팅데이터를 담기 위한 DB로 Mongodb를 사용할 계획이라고 말했지만 , 데브옵스 팀원분께서 다른 의견을 주셨다.

 

 

1. 그냥 기존에 사용하는 MYSQL을 사용하는건?

2. NoSql을 사용한다면 관리포인트가 더 늘어나는데 Mongodb랑 DynamoDb중 어떤게 관리포인트 측면에서 좋을까?

3. Redis같은걸 써서 batch transcation을 사용하는건?

4. Kafka는 이전 데이터를 삭제하지 않기 때문에 Kafka를 Db처럼 사용할 수 있나?

 

결국 내가 채팅 데이터를 DB에 저장하는 이유는 이전에 했던 채팅내역을 그대로 들고오기 위함이다.

 

해당 내용을 기반으로 글을 작성해볼까 한다.

 

기존 MYSQL을 사용한다면...

 

우선 NOSQL이 기존의 RDB보다 더 빠른 읽기 쓰기 성능을 가지고 있다.

 

또한 채팅데이터는 뭔가 정형화된 데이터라는 느낌보다는 언제든지 바뀔 수 있으며 많은 양의 데이터가 수시로 Read/Write 기능이 요구가 된다.

 

또한 Write가 많은 채팅 데이터로 인해 다른 테이블의 트랜잭션이 일시적으로 중단될 수 있다.

 

그리고 가장 중요한건 scale-out측면이다.

 

채팅 데이터는 사용자가 많아질수록 더 많이 쌓이게 되는 데이터이다.

 

Mysql은 Scale-out이 어려운것으로 알 고 있다. 하지만 Nosql은 clustering을 대부분 지원해주기에 NOSQL이 좀더 합당한거 같다.

 

 

MongoDb vs DynamoDb

 

	MongoDb	DynamoDb
스프링과 호환성	O(더 많은 레퍼런스)	O
가격	시간당 0.236 USD	쓰기 요청 유닛 100만  개당 1.3556 USD 읽기 요청 유닛 100만  개당 0.271 USD 1유닛 당 1KB
스토리지 가격	범용 SSD(gp2) 볼륨 월별 제공된 스토리지 GB당 0.114 USD	월별 GB당 0.27075 USD
연결	TCP	HTTP
저장 방식	Document	Key-Value
관리	EC2직접 설치, serverless 존재	다른 NoSQL 과 다르게 serverless DB라는 특징으로 서버관리가 필요 없음

 

해당 비교를 통해 MONGODB를 선택

 

- 초기에는 기존에 존재한는 EC2에 standalone으로 가능

- 추후에 필요하면 cluster작업하여 scale up 가능

- springboot ORM제공

- serverless도 존재하기에 관리적 측면에서 이점을 얻을 수 있음

 

 

https://byline.network/2022/05/0512-2/

참고로 해당 글에서 당근마켓이 이전에는 Postgres를 사용하고 있었지만, 채팅데이터의 비중이 너무 많아져 DynamoDb로 마이그레이션 했다고 한다. 

 

https://velog.io/@jaymee/chatting-DB-%EC%84%A4%EA%B3%84

chatting DB 설계

 

Redis같은걸 활용해 Batch형태로 저장하는건?

 

해당 자료는 잘 나오지 않아 chatgpt한테 물어봤다.

 

If you are using a NoSQL database such as MongoDB or DynamoDB to store chat data, you generally don't need to use a separate caching layer like Redis for batch inserts.

NoSQL databases are designed to handle high write throughput, so they can handle a high volume of chat messages being written to the database. With proper indexing and partitioning, you can ensure that the database can handle a high volume of reads and writes without sacrificing performance.

That being said, you may still want to consider using a caching layer like Redis if you have specific performance requirements or if you want to optimize read performance. For example, Redis can be used to cache frequently accessed chat messages in memory, reducing the need to query the database for each request.

Ultimately, whether or not to use a caching layer like Redis depends on your specific performance requirements and use case. It may be worth considering if you have specific performance needs, but it is not strictly necessary if you are using a NoSQL database with good write throughput capabilities.

요약하면 NOSQLDB 자체가 쓰기성능이 좋게 나온것인데 굳이 Redis같은걸 써서 batch insert를 할 필요 없다고 한다. 아마 우리가 하는 프로젝트에서는 충분히 처리할 수 있다고 한다.

 

 

Kafka는 이전 데이터 삭제하지 않으니까 DB처럼은 사용못하나?

 

kafka는 장기용 저장 공간으로 설계된것이 아닌 데이터 스트리밍 플랫폼으로 나온것이다.

 

또한 나는 해당 메세지를 파티션에 저장된 그대로 읽는것보다 확실한 최근순 정렬이 필요하다 이것은 kafka만을 통해서는 불가능

 

또한 무기한으로 kafka에서 데이터를 저장하지도 않는다. 

 

즉 kafka는 채팅메세지를 실시간으로 처리하는데 사용되지 저장 및 검색 용도로사용되지 않는다.

 

 

결론

 

실제 mongodb를 우선적으로 사용하여 채팅메세지를 저장해보았다.

 

사용해보니 standalone으로 작업하니 docker로 구동하여 초반 관리 측면도 어느정도 자유롭게 있을 수 있었다.

또한 Springboot-mongo-data라이브러리르 제공하여 더 쉬운 작업이 가능했다.

 

다만 아쉬운점은 JPA를 사용하지 못하기에 채팅데이터의 외래키를 JAVA단에서 객체로 저장하는것이 아니라, 실제 외래키를 저장하기에 조금 아쉬운 부분이 있었다.

 

하지만  추후 데이터가 많아지는것을 예상했을때 좀 더 좋은 선택이 되었다고 생각한다.