[Database] MongoDB(NoSQL) VS MySQL(SQL)

 MongoDB와 MySQL의 주요 차이점 

MySQL은 Oracle Corporation의 관계형 데이터베이스 관리 시스템(RDBMS)이다. 다른 관계형 시스템과 마찬가지로 MySQL은 테이블에 데이터를 저장하고 데이터베이스 액세스를 위해 구조화된 쿼리 언어(SQL)를 사용한다. MySQL 개발자는 애플리케이션의 데이터에 액세스해야 할 때 JOIN이라는 프로세스에서 여러 테이블의 데이터를 병합한다.

MySQL에서는 데이터베이스 스키마를 미리 정의하고 테이블의 필드 간의 관계를 제어하는 규칙을 설정한다.

 

MongoDB는 데이터를 JSON과 유사한 문서롤 저장하는 NoSQL 데이터베이스이다. 문서는 관련 정보를 함께 저장하고 액세스를 위해 MongoDB 쿼리 언어(MQL)을 사용한다. 필드는 문서마다 다를 수 있다. 문서는 자체 설명적이므로 시스템에 문서 구조를 선언할 필요가 없다. 선택적으로 스키마 유효성 검사를 사용하여 각 컬렉션에 대한 데이터 커버넌스 제어를 시행할 수 있다. 

 

 NoSQL이란 무엇인가? 

사람들은 보통 "NoSQL 데이터베이스"란 용어를 비관계형 데이터베이스를 지칭할 때 사용한다. 누군가는 "NoSQL"을 "non SQL(비 SQL)"의 약자로, 또 누군가는 "not only SQL(SQL만을 사용하지 않는)"의 약자로 생각한다. 어떤 경우든 대부분의 사람들은 NoSQL 데이터베이스가 관계형 데이터베이스 이외의 형식으로 데이터를 저장하는 데이터베이스라는데 동의한다.

 

흔히들 NoSQL 데이터베이스 또는 비관계형 데이터베이스는 관계 데이터를 저장하지 않는다고 오해한다. NoSQL 데이터베이스는 관계형 데이터베이스와 방식은 다르지만 관계 데이터를 저장할 수 있다. 실제로 SQL 데이터베이스와 비교해보면, 대체로 NoSQL 데이터베이스에 있는 관계 데이털ㄹ 모델링하는 것이 SQL 데이터베이스보다 쉽다는 것을 알 수 있는데, 이는 관련 데이터를 테이블 간에 분할할 필요가 없기 때문이다.

NoSQL 데이터 모델을 사용하면 관련 데이터를 단일 데이터 구조 내에 중첩시킬 수 있다.

 

NoSQL 데이터베이스는 2000년대 말에 스토리지 비용이 크게 하락하면서 등장했다. 단순히 데이터 중복 감소를 목적으로 복잡하고 관리가 어려운 데이터 모델을 생성해야 하던 시절은 지났다. 스토리지가 아니라 개발자들이 소프트웨어 개발의 1차 비용이 되었기 때문에 NoSQL 데이터베이스는 개발자 생산성에 맞게 최적화되었다.

 

때문에 저장 및 쿼리를 위해 필요한 데이터 애플리케이션의 양도 증가했다. 이러한 데이터는 정형, 반정형, 다형적 등 모양과 크기가 모두 다르기 때문에 미리 스키마를 정의하는 것이 거의 불가능해졌다. NoSQL 데이터베이스는 개발자가 엄청난 양의 비정형 데이터를 저장할 수 있도록 지원하여 뛰어난 유연성을 제공한다.

 

뿐만 아니라, Agile Manifesto의 인기가 높아지면서 소프트웨어 개발자들은 소프트웨어 개발 방식을 되짚어보기 시작했다. 그리고 변화하는 요구사항에 발 빠르게 적응해야 할 필요가 있음을 인지했다. 이들에게는 데이터베이스 모델에 이르기까지 소프트웨어 스택 전반에서 반복 작업과 변경을 신속하게 수행할 수 있는 능력이 필요했다. NoSQL 데이터베이스는 개발자들에게 이러한 유연성을 제공한다.

 

클라우드 컴퓨팅 역시 인기가 높아졌고, 개발자들은 퍼블릭 클라우드를 사용해 애플리케이션과 데이터를 호스팅하기 시작했다. 이들은 여러 서버와 리전에 데이터를 분산시켜 애플리케이션 복원력을 높이고, 스케일업(vertical scaling)이 아닌 스케일 아웃(horizontal scaling)을 수행하며, 데이터를 지능적으로 배치할 수 있기를 원했다. MongoDB 같은 일부 NoSQL 데터베이스들은 이러한 기능을 제공하고 있다.

 

SQL이란 무엇인가?

NoSQL 데이터베이스를 이해했다면 이제는 과거에 가장 인기 있었던 SQL(Structured Query Language)로 액세스하는 관계형 데이터베이스와 이들을 비교해볼 것이다. 데이터가 고정된 열과 행을 가지고 있는 테이블에 저장되는 관계형 데이터베이스와 상호 작용할 때 SQL을 사용할 수 있다.

 

SQL 데이터베이스는 1970년대 초반에 사용자들로부터 많은 사랑을 받았다. 당시만 해도 스토리지가 매우 비쌌기 때문에 소픝웨어 엔지니어들은 데이터 중복을 줄이기 위해 데이터베이스를 정규화했다.

 

또한 1970년대의 소프트웨어 엔지니어들은 일반적으로 소프트웨어 개발에 있어 폭포수(waterfall) 모델을 따랐다. 개발이 시작되기 전에 프로젝트에 대한 상세한 계획이 수립되었다. 소프투웨어 엔지니어들은 저장이 필요한 모든 데이터를 신중하게 고려하기 위해 애써서 복잡한 엔터티-관계(E-R) 다이어그램을 만들었다. 이러한 선행 계획 모델로 인해 소프트웨어 엔지니어들은 개발 주기 동안 요구사항이 바뀔 경우, 이에 대처하느라 애를 먹었다. 그 결과, 프로젝트에서 예산이 초과되고 마감 기간을 넘겨서 사용자 요구를 충족하지 못하는 일이 잦았다.

 

SQL과 NoSQL의 차이점

	SQL Database	NoSQL Database
데이터 저장 모델	행과 열이 고정된 테이블	문서: JSON 문서, 키-값: 키-값 쌍, 와이드 열: 행과 동적 열이 있는 테이블, 그래프: 노드 및 가장자리
개발 이력	데이터 중복 감소에 중점을 두고 1970년대에 개발됨	2000년대 후반에 확장에 중점을 두고 애자일 및 DevOps 방식으로 구동되는 신속한 애플리케이션 변경을 허용하도록 개발
예	Oracle, MySQL, Microsoft SQL, Server 및 PostgreSQL	document : MongoDB and CouchDB, Key-value: Redis and DynamoDB, Wide-column: Cassandra and HBase, Graph: Neo4j and Amazon Neptune
주요 목적	범용	document : 범용, Key-value: 단순 조회 쿼리를 통한 대용량 데이터, Wide-column: 예측 가능한 쿼리 패턴을 갖는 대용량 데이터, Graph: 연결된 데이터 간의 관계 분석 및 탐색
스키마	Rigid	Flexible
스케일링	Vertical(scale-up with a larger server)	Horizontal(scale-out across commodity servers)
다중 레코드 ACID 트랜잭션	지원	대부분은 다중 레코드 ACID 트랜잭션을 지원하지 않는다. 그러나 MongoDDB와 같은 일부는 지원한다.
조인	일반적으로 필수	일반적으로 필요하지 않음
데이터-객체 매핑	ORM(Object-Relational Mapping)	많은 경우 ORM이 필요하지 않는다. MongoDB 문서는 가장 널리 사용되는 프로그래밍 언어의 데이터 구조에 직접 매핑된다.

 

MySQL을 사용하는 것보다 MongoDB를 사용하는 것이 더 나은 이유는 무엇인가?

모든 규모의 조직에서 MongoDB를 특히 클라우드 데이터베이스로 채택하고 있다. MongoDB를 사용하면 애플리케이션을 더 빠르게 구축하고 매우 다양한 데이터 유형을 처리하며 대규모로 애플리케이션을 보다 효율적으로 관리할 수 있기 때문이다.

 

MongoDB 문서가 현대적인 객체 지향 프로그래밍 언어에 자연스럽게 매핑되므로 개발이 단순화된다. MongoDB를 사용하면 코드의 개체를 관계형 테이블로 변환하는 복잡한 개체 관계형 매핑(ORM) 계층이 제거된다. MongoDB의 유연한 데이터 모델은 또한 데이터베이스 스키마가 비지니스 요구사항에 따라 발전할 수 있음을 의미한다. MySQL의 엄격한 관계형 구조는 응용 프로그램에 오버헤드를 추가하고 개발자가 코드의 개체를 관계형 구조에 적용해야 하므로 개발의 속도를 늦춘다.

 

또한 MongoDB는 여러 분산 데이터 센터 내에서 확장할 수 있어 이전에는 MySQL과 같은 관계형 데이터베이스에서는 달성할 수 없었던 새로운 수준의 가용성과 확장성을 제공한다. 배포가 데이터 볼륨 및 처리량 면에서 증가함에 따라 MongoDB는 다운타임과 애플리케이션 변경 없이 쉽게 확장된다. 이와 대조적으로 MySQL을 사용하여 확장을 달성하려면 상당한 사용자 지정 엔지니어링 작업이 필요한 경우가 많다.

 

즉, 정리하자면 MongoDB의 장점은 다음과 같다.

 

고가용성

MongoDB는 고가용성과 내구성을 위해 데이터를 추가 노드에 자동으로 복제한다. 시스템 장애가 발생하면 일반적으로 5초 이내에 장애 조치가 자동으로 완료된다. MySQL은 데이터를 다른 노드로 복제할 수 있지만 노드 간의 장애 조치는 애플리케이션 다운타임을 증가시키는 복잡한 수동 프로세스이다.

 

개발 속도 향상

MongoDB의 JSON 문서 데이터 모델은 애플리케이션 코드의 객체에 자연스럽게 매핑되므로 개발자가 쉽게 배우고 사용할 수 있다.

많은 개발자가 MySQL이 사용하는 SQL 및 관계형 모델이 익숙하지만 개발 속도를 늦추는 데이터베이스 스키마 및 데이터 모델링에 제약을 가한다.

 

무한하고 저렴한 확장

MongoDB에는 애플리케이션에 투명한 방식으로 여러 상용머신에 데이터베이스를 배포하거나 샤딩하기 위한 기본 지원이 포함되어 있다.

MySQL을 확장하려면 더 강력한 서버를 구입하거나 애플리케이션에서 더 복잡한 샤딩 솔류션을 구현해야 한다.

 

참고자료 :

MongoDB vs MySQL