MySQL VS MongoDB 비교해보자!

MySQL VS MongoDB

---

NoSQL

MySQL과 MongoDB는 각 RDBMS와 NoSQL 이다. NoSQL은 Not Only SQL 의미로 SQL 이외의 다른 데이터베이스를 얘기한다. 즉, NoSQL 이 곧 MongoDB라고는 할 수 없다. 그저 전통적으로 RDBMS가 주류로 있어왔기 때문에 SQL 과 NoSQL 이라고 나누는 것이다.

데이터를 구성하는 방법

관계형 데이터베이스와 도큐먼트 데이터베이스는 데이터를 구성하는 방법이 서로 다르다.

관계형 데이터베이스의 경우 속성을 정의한 열의 집합으로 테이블을 정의하고 이러한 테이블들을 모아 하나의 데이터베이스를 이룬다. ROW 를 구성한다.

도큐먼트 데이터베이스의 경우 BSON(Binary JSON) 형태의 도큐먼트를 모아둔 컬렉션이 있고 이 컬렉션들을 모아 하나의 데이터베이스로 구성한다.

RDBMS		MongoDB
Cluster	➡️	Cluster
Database	➡️	Database
Table	➡️	Collection
Row	➡️	Document
Column	➡️	Field

관계형 데이터베이스의 경우 스키마가 고정적이며 모든 로우는 그 스키마의 규칙을 따라야 한다. 하지만 도큐먼트 데이터베이스의 경우 스키마가 고정적이지 않고 유연하다.

이러한 특징 때문에 관계형 데이터베이스는 예측 가능하고 일관된 형태를 유지할 수 있는 반면에 구조적 변경이 필요한 순간에 인덱스 설정 및 레코드 수정에 큰 리소스가 발생한다.

반대로 도큐먼트 데이터베이스의 경우 스키마가 따로 정해져 있지 않아 유연하고 빠르게 변경하며 개발이 가능하다 하지만 이러한 유연성은 데이터를 예측하기 힘들고 일관성을 깨 유지보수가 힘들다는 단점으로 다가올 수 있다.

조인과 Extended Refrecence 패턴

관계형 데이터베이스는 정규화를 통해 중복 데이터를 각기 다른 테이블에 한 번만 저장하고, 조인을 통해 테이블의 경계를 넘어선 데이터를 결합해 보여줄 수 있다. 때문에 일관성 있는 데이터를 유지하기 쉽다는 것을 의미한다. 단 한 곳만 변경해도 참조로 되어 있어 모든 곳에서 일관성있게 데이터를 유지할 수 있다.

하지만 이러한 조인은 데이터를 읽어오는 과정에서 여러 테이블을 메모리에 올리고 결합해야 하기 때문에 많은 컴퓨팅 리소스가 필요해 성능 문제로 다가온다. 때문에 상대적으로 분산환경 구축이 힘든 관계형 데이터베이스에서 조인(Join)이 항상 옳은 선택이 아닐 수 있다.

도큐먼트 데이터베이스인 MongoDB의 경우 성능을 위해 Join 대신 쿼리를 두 번 날려 연관 데이터를 불러오는 방법을 주로 사용한다. 그리고 이렇게 두 번 쿼리를 날리는 경우가 잦아지면 Extended Reference 패턴을 사용해 관련 연관 데이터를 도큐먼트 내에 포함시켜 쿼리를 두 번 날리거나 조인이 필요하지 않도록 한다. 때문에 성능에 이득을 얻을 수 있다.

하지만 Extended Reference 패턴 을 사용하게 되면 조인이나 쿼리의 수를 줄일 수는 있지만. 해당 데이터가 중복되어 여러곳에 분산 저장되어 있다보니 그 일관성을 지키기가 힘들어진다는 단점을 가진다. 때문에 비즈니스적으로 실시간 일관성이 중요한 시스템이라면 적합하지 않을 수 있다.

ACID 와 BASE

일반적으로 MySQL은 ACID 모델, MongoDB는 BASE모델을 지킨다고 알려져 있다.

ACID는 원자성, 일관성, 독립성, 지속성을 만족하는 데이터베이스 모델을 의미한다. 즉, 모든 순간에 정확한 데이터를 제공하며 그 저장된 데이터가 영구적으로 유효해야 함을 의미한다. MySQL의 경우 정확하고 일관성있는 데이터를 주는 것에 목표를 둔다는 의미이다.

BASE 모델의 경우 일관성보다 가용성을 중요시 하는 모델을 의미한다. 그렇다고 해서 BASE모델이 일관성을 포기한 것은 아니다. 그저 어느 것을 더 중요시 하느냐의 문제이다. 즉각적인 일관성은 분산환경을 위해 조금 포기하지만 결국에는 데이터의 일관성을 맞추기 위해 노력한다.

• Basically Avaliable
  • 언제든지 사용할 수 있다 즉, 가용성을 보장한다.
• Soft state
  • 외부 개입 없이 상태변경이 가능하다. 즉, 분산환경에 네트워크 문제로 일관성을 헤칠 때 일관성 유지를 위해 자동으로 그 값을 수정할 수 있다.
• Eventually consistent
  • 즉각적인 일관성을 보장하지 않을 수는 있지만, 결국에는 그 일관성을 유지한다는 의미이다.

MongoDB의 Transaction

트랜잭션을 만족한다는 것은 ACID 속성을 충족하는 데이터베이스 라는 의미이다. MongoDB의 경우 BASE 모델을 따른다고 얘기했지만 MongoDB 4.0 에 도입된 Multi Document Transaction 과 MongoDB 4.2에 Shard Cluster Transacion 으로 ACID 속성을 만족하는 데이터베이스가 되었다. 기본적으로 MongoDB는 Single Document Transaction 을 제공하는데 이는 하나의 도큐먼트에 대해서만 트랜잭션을 지원한다는 의미이다. 이것이 가능했던 것은 기본적으로 MongoDB는 조인이 아닌 Embed 를 통해 하나의 도큐먼트로 조회하는 것을 베스트 프랙티스라 생각하기 때문에 하나의 도큐먼트에 대해서만 트랜잭션을 보장해도 완벽히 트랜잭션을 제공할 수 있을 것이라는 생각 때문이다.

하지만 현실을 녹녹지 않다 항상 MongoDB가 희망하는 모델링만 가능한 것은 아니다. 때문에 MongoDB 4.0 에서 등장한 것이 Multi-Document Transaction 이다.

Multi-Document-Transaction

Multi Document Transaction 은 말 그대로 다수의 도큐먼트에 대해 트랜잭션이 가능하다는 의미이다.
다수의 도큐먼트에 대해 트랜잭션이 가능해져 ACID를 충족하는 트랜잭션이 되었다. 하지만 MongoDB는 SInge Document Transaction 을 권장하고 있다. 그리고 이 편이 더 나은 성능을 보여줄 것이라고 설명한다. 때문에 최대한 권장하는 도큐먼트 모델링을 통해 Multi Document Transaction 의 사용은 최소화 해야 한다.

Shard Cluster Transaction

Shard Cluster Transaction 의 경우 여러 클러스터 간에도 트랜잭션이 정상 작동함을 의미한다. 덕분에 분산된 환경에서도 ACID를 충족할 수 있다. 즉, MongoDB는 ACID를 충족하는 데이터베이스라고 부를 수 있다.

수평적 확장

MongoDB 와 MySQL은 모두 레플리케이션을 통한 수평적 확장을 제공한다. 둘 모두 일반적으로 Master-Slave를 나누어 레플리케이션을 진행한다. 차이점은 샤딩에 있다. MySQL의 경우 샤딩을 구현하기 상당히 힘들다 하지만 MongoDB의 경우 데이터베이스 자체적으로 샤딩의 구현을 지원해주고 있어 MySQL에 비해 그 구성이 상당히 쉽다. 즉, MongoDB의 경우 가용성 확보를 위해 다양한 수평적 확장 수단을 자체적으로 제공하고 있다.

참조

• ACID VS BASE
• ORM과 ODM 차이
• MongoDB 성능
• MongoDB Transaction1
• MongoDB Transaction2
• MongoDB VS MySQL