RDBMS vs NoSQL

❗ 이 글을 쓰게 된 계기

• 최근 백엔드 프로젝트를 진행하면서 RDBMS인 PostgreSQL과 NoSQL인 MongoDB를 사용했었다.
• 각 프로젝트마다 다른 DB를 사용했는데 두 유형의 DB를 사용하면서 느낀 차이점과 장단점을 정리해보면 후에 프로젝트에 DB를 선택해야할 때 도움이 될 것 같아서 글을 작성해본다.

😊 1. RDBMS (PostgreSQL)

1.1 RDBMS의 주요 특징

• 관계형 데이터 모델, SQL 기반 : 데이터를 테이블 형태로 구조화하여 관리하며, SQL 언어를 사용하여 데이터를 효율적으로 조회, 수정, 관리할 수 있다.
• 엄격한 스키마, 명확한 데이터 관계성 : 데이터의 구조가 사전에 정의된 스키마에 따라 관리되어 데이터의 무결성과 일관성을 유지하기 좋으며, 데이터 간 관계가 명확히 정의된다.
• 트랜잭션과 JOIN의 강점: 여러 작업을 하나의 작업 단위로 처리하는 트랜잭션을 완벽에 가깝게 지원하고, JOIN을 활용하여 복잡한 데이터 관계를 쉽게 처리할 수 있다.

1.2 RDBMS의 단점

• 스키마 변경(컬럼 추가)이 어렵고, 특히 데이터가 많을 때 변경 과정에서 위험부담이 크다.
• 데이터 중복 최소화를 위한 정규화가 복잡한 JOIN을 유발하여 성능 저하를 발생시킬 수 있다.
• 스케일 업 방식으로 서버 성능 확장에 의존하기 때문에 스케일 아웃(서버 추가를 통한 확장)이 보다 어렵다.

1.3 내가 PostgreSQL을 선택한 이유

• 이 프로젝트는 위치 기반 및 실시간 채팅 기능을 추가하여 캠핑장 방문객들이 실시간 정보를 공유하고, 같은 장소의 사용자들과 소통하는 위치 기반 캠핑 커뮤니티 플랫폼 프로젝트였다.
• 위치 기반 기능을 제공하는 데 있어 PostgreSQL의 PostGIS라는 지리 정보 시스템 확장 모듈을 지원해서 효율적이고 정확한 위치 기반 데이터 처리와 쿼리가 가능했다.
• 찾아본 결과 Mysql도 MySQL GIS를 지원하는데 성능,비용,안전성 면에서 PostGIS가 우수하다는 비교글이 많아서 PostgreSQL을 선택했다.
• 참고 글 : https://joojae.com/mysql-gis-vs-postgresql-postgis/
  https://steemit.com/kr-dev/@tmkor/db-2-mysql-vs-postgis-postgresql
  https://stackoverflow.com/questions/3743632/gis-postgis-postgresql-vs-mysql-vs-sql-server?ref=joojae.com
• 명확한 데이터 관계와 데이터 정합성이 필수였기 때문에 이를 보장하는 PostgreSQL이 프로젝트 목적에 가장 적합했다.

1.4 배운점 & NoSQL의 필요성

• 프로젝트에서 실시간 채팅 기능을 구현할 때 PostgreSQL을 사용했는데, 지금처럼 사용자가 소수일 때에는 속도나 기능면에서 정상작동 하지만, 후에 사용자가 많아질 수록 스키마 구조상 채팅 메시지가 증가할수록 연산이 많아져서 성능이 저하되는 문제가 있을 것이라는 예상이 된다.
• RDB의 특성상 JOIN 연산을 빈번히 수행해야 하기 때문에 채팅 메시지를 저장하고 불러오는 과정에서 사용자 정보, 채팅방 정보, 메시지 데이터가 서로 다른 테이블로 나누어져있고, 이를 매번 JOIN으로 연결해 가져와야 하므로 데이터가 많아질수록 연산이 복잡해지고 처리 시간이 길어지게 된다. 특히, 실시간으로 데이터가 지속적으로 쌓이는 채팅 서비스에서는 이런 JOIN 연산이 병목 현상을 초래할 수 있다는 문제점이 예상된다.
• 이 때문에 실시간 채팅 같은 빠른 데이터 처리와 빈번한 읽기 및 쓰기 작업이 필요한 경우 MongoDB와 같은 NoSQL을 사용하는 것이 성능적으로 더 적합했을 것이라는 아쉬움이 남았다.
• 추후에 채팅기능만 MongoDB로 옮기는 작업을 하면 좋을 것 같다.

😁 2. NoSQL (MongoDB)

2.1 NoSQL의 주요 특징

• 비정형 데이터, Document 기반(JSON 형태) : 데이터를 유연한 JSON 형태의 Document로 저장하여 다양한 형태의 데이터를 쉽게 관리할 수 있다. 스키마를 사전에 엄격하게 정의할 필요가 없어 데이터 구조 변경이 간편하다.
• 유연한 스키마, 확장성 용이 : 요구사항 변화가 빈번한 환경에서 필드를 자유롭게 추가하거나 제거할 수 있어 빠른 개발 속도와 높은 확장성을 제공한다.

2.2 NoSQL의 단점

• JOIN 연산 제한 : 관계형 데이터 모델과 달리 JOIN 연산이 제한적이어서 서로 다른 컬렉션 간의 복잡한 데이터 조회가 어렵고, 애플리케이션 코드에서 별도의 처리 로직을 구현해야 한다. (MongoDB는 aggregate , $lookup, find 지원)
• Mongoose의 populate도 비슷한 JOIN 기능을 하는데 데이터가 많아질 수록 성능이슈가 있어서 해당 프로젝트에서는 사용하지 않았다.
• 참고 : https://medium.com/@truong.minh.michael/when-to-use-find-vs-aggregate-lookup-vs-populate-in-mongoose-and-mongodb-5a08f650639f
• https://dev.to/sujeetsingh123/unlocking-data-relationships-mongodbs-lookup-vs-mongooses-populate-mc5
• 데이터 중복 관리 : 데이터 중복이 허용되는 구조이기 때문에 같은 정보가 여러 Document에 저장될 수 있으며, 이를 관리하는 책임이 애플리케이션 레벨에서 관리를 해줘야 한다.

2.3 내가 MongoDB를 선택한 이유

• MongoDB를 사용한 프로젝트는 역할 기반의 권한 관리 등을 제공하는 팀별 일정 공유 및 업무 지원 플랫폼이었다.
• 프로젝트의 ERD 구조상 프로젝트, 업무, 팀, 사용자, 이미지 등 여러 테이블 간의 빈번한 상호작용과 데이터의 추가 및 수정이 잦았다. 업무와 프로젝트 관련 정보가 지속적으로 추가되고 수정되었기 때문에, 데이터 양이 많아졌을 때 MongoDB의 뛰어난 Scale-out 덕분에 서버 추가 및 성능 확장이 용이할 것으로 판단했다.
• MongoDB Atlas로 클라우드기반 데이터베이스를 서버 설치 없이 기본 기능들이 잘 탑재되어 있어서 빠르게 시작할 수 있다는 장점도 이용했다.

😎 3. 결론

• RDBMS 와 NoSQL 둘 다 장단점이 명확하므로, 프로젝트 특성에 따라 적절히 선택하는 것이 중요하다고 생각이 든다. 각각의 장점을 뽑아먹으면서 앞으로의 프로젝트에 활용해야겠다.