여러분, 데이터베이스 선택이 얼마나 중요한지 아시나요? 현대 애플리케이션에서 데이터베이스는 그야말로 중심 역할을 합니다. 올바른 데이터베이스를 선택하는 것은 프로젝트의 성공을 결정짓는 중요한 요소 중 하나입니다. 저는 이번 글에서 대표적인 관계형 데이터베이스인 MySQL과 비관계형 데이터베이스인 MongoDB를 비교해 보려고 합니다. 각 데이터베이스의 특징을 살펴보고, 제가 직접 겪었던 경험도 공유해 보겠습니다.
MySQL과 MongoDB의 주요 차이점
데이터 구조
먼저, MySQL과 MongoDB의 가장 큰 차이점은 데이터 구조입니다.
- MySQL은 관계형 데이터베이스로, 데이터를 테이블 형태로 저장합니다. 스키마가 엄격하며, 데이터 무결성을 보장하기 위해 제약 조건이 많습니다. 각 테이블은 서로 관계를 맺고, 이 관계를 통해 데이터를 관리하죠.
- MongoDB는 비관계형 데이터베이스로, 데이터를 JSON과 유사한 문서(document) 형식으로 저장합니다. 이 방식 덕분에 스키마가 유연하여 데이터 구조를 쉽게 수정할 수 있습니다. 말하자면, 변화에 빠르게 대응할 수 있는 장점이 있습니다.
데이터 모델링
데이터를 어떻게 모델링하는지도 두 데이터베이스 간의 큰 차이 중 하나입니다.
- MySQL에서는 데이터를 여러 테이블로 나누고, 각 테이블 간의 관계를 정의합니다. 이를 통해 데이터 중복을 최소화하고 무결성을 유지합니다.
- MongoDB는 데이터를 중복 저장하는 방식으로, 하나의 문서에 관련된 데이터를 함께 저장하여 읽기 성능을 최적화합니다. 이 덕분에 특정 데이터를 조회할 때 여러 테이블을 참조할 필요가 없습니다.
JOIN 기능
이 부분에서 많은 차이가 있는데요, 바로 JOIN 기능입니다.
- MySQL에서는 여러 테이블을 연결할 때
JOIN기능을 사용합니다. 예를 들어, 사용자의 주문 정보와 해당 사용자의 정보를 한 번에 가져올 수 있죠. - MongoDB는 기본적으로
JOIN연산을 지원하지 않지만,aggregation파이프라인의$lookup을 사용하면 제한적으로 조인 기능을 구현할 수 있습니다. 하지만 이는 MySQL의JOIN만큼 최적화되어 있지는 않아서 대량의 데이터를 다루는 경우 성능 문제가 발생할 수 있습니다.
NoSQL, MongoDB를 선택하게 된 이유
저희 팀이 MongoDB를 선택하게 된 이유는 두 가지였습니다.
- 첫째, 유연한 데이터 구조였습니다. 변화하는 요구사항에 맞게 데이터 스키마를 쉽게 수정할 수 있었기 때문에, 빠르게 개발해야 하는 상황에서 큰 도움이 되었습니다.
- 둘째, 수평적 확장성 덕분이었습니다. 데이터가 급격히 늘어나는 프로젝트였기 때문에, 여러 서버로 데이터를 쉽게 분산시킬 수 있는 MongoDB의 장점이 크게 작용했습니다.
그렇지만 많은 데이터를 참조해야되는 인사관리 프로그래밍 특성상 맞지 않았고 이로 인해 직접적으로 문제와 그때 당시 해결했던 방법에 대해서 작성해볼까 합니다.
MongoDB를 사용하면서 가장 고생했던 순간 중 하나는 JOIN 기능의 부재였습니다.
당시 제가 맡았던 작업은 한 달 동안의 근무 기록을 가져와서 각 조직 내 근로자들의 하루 근무 데이터를 바탕으로 연장근무, 야간근무, 휴일근무를 계산해 보여주는 기능을 구현하는 것이었어요. 문제는 MongoDB에서 JOIN이 없기 때문에 각 데이터를 일일이 접근해야 했다는 점이었죠.
예를 들어, 한 조직에 대해서 user_id + company_id를 사용해서 userCompanyRecord(인사정보)를 가져오고, 다시 company_id 와 userCompanyRecord_id를 가지고 근태 기록을 가져와야 했죠. 이걸 매달 30일치(대략 한 달의 일수) 데이터를 조회하고, 이를 통해 연장근무, 야간근무, 휴일근무를 하나씩 계산해야 했습니다. 게다가 가장큰 조직은 회사 전체 조직으로 약 1000명의 근로자에 대한 데이터를 다루면서 각 인원의 근무 정보를 그래프로 시각화하는 기능도 포함되어 있었습니다.
이렇게 많은 데이터를 반복적으로 조회하다 보니, 개발 서버에서 테스트할 때 리소스 사용량이 급격히 증가했고, 속도도 매우 느려졌습니다. 결국 대량의 데이터를 실시간으로 처리하기에는 한계가 있었습니다. 외주 회사에서는 실시간성이 필요하지 않다고 했기 때문에, 이를 빠르게 해결하기 위해 자정에 하루 단위로 데이터를 미리 계산해 저장하고, 이를 조회하는 데이터 캐싱 방식으로 변경했습니다.
이 경험을 통해 대량의 데이터를 다루는 상황에서는 관계형 데이터베이스의 JOIN이 얼마나 효율적인지 다시 한 번 깨닫게 되었고, MongoDB를 사용할 때는 처음부터 데이터 조회 구조를 잘 설계하는 것이 얼마나 중요한지를 절실히 느꼈습니다.
추가적으로 그 당시에는 $lookup 기능을 사용하진 않았습니다. 아마 사용했으면 조금 더 좋아질 수는 있었겠지만 JOIN 과 완벽하게 동일하진 않기 때문에 여전히 문제가 지속될 가능성이 있습니다. (다음엔 기회가 된다면 $lookup 을 사용해 봐야겠습니다!)
이 부분에 대해서는 다음 기회에 더 자세히 다뤄보려 합니다!
MySQL과 MongoDB의 적합한 사용 사례
그렇다면 MySQL과 MongoDB는 어떤 경우에 적합할까요?
- MySQL은 데이터 무결성이 중요하고, 복잡한 관계를 관리해야 하는 금융 시스템이나 전자 상거래 시스템에 적합합니다.
- 반면, MongoDB는 유연한 데이터 구조가 필요하고, 빠른 개발 및 수평적 확장이 중요한 소셜 미디어 플랫폼이나 로그 데이터 저장에 적합합니다.
결론
결국, 적절한 데이터베이스를 선택하는 것이 중요합니다. MongoDB와 MySQL은 각기 다른 장점과 단점을 가지고 있으며, 프로젝트의 요구사항에 따라 알맞은 데이터베이스를 선택하는 것이 성공의 열쇠입니다. 저 역시 이번 경험을 통해 JOIN 없이도 효율적으로 데이터를 다루기 위해 데이터 모델링 방식에 대해 깊이 고민하는 것이 얼마나 중요한지 깨달았습니다.
마무리 질문
여러분은 어떠신가요? MongoDB나 MySQL을 사용하면서 겪었던 어려움이나 배운 점이 있다면 댓글로 공유해 주세요! 여러분의 경험을 통해 서로 배울 수 있기를 기대합니다.
