MongoDB의 공식 문서 Comparing MongoDB vs MySQL 을 번역했습니다.
사진출처: https://www.fosslinux.com/49904/mysql-vs-mongodb.htm
What are the main differences between MongoDB and MySQL?
mongoDB와 MySQL의 주요한 차이점은 무엇인가?
MySQL은 Oracle Corporation에서 만든 Relational Database Management System 관계형 데이터베이스 관리 시스템(RDBMS)이다. 다른 관계형 시스템처럼, MySQL은 데이터베이스 액세스를 위해 structured query language(SQL)을 사용하여 테이블 형태로 데이터를 저장한다.
MySQL 개발자가 애플리케이션에서 데이터에 접근할 때, JOIN이라 불리는 작업을 통해 다수의 테이블을 병합한다. MySQL에서는 데이터베이스 스키마를 미리 정의하고, 테이블에서 필드 사이의 관계를 제어하는 규칙을 설정한다.
MongoDB는 데이터를 데이터를 JSON-like documents로 저장하는 NoSQL 데이터베이스이다. Document는 관계된 정보를 함께 저장하고 MongoDB query language(MQL)을 사용하여 접근한다. Document별로 필드는 다를 수 있으며 - document가 자기 기술self-describing 하므로 시스템에 Document의 구조를 따로 정의할 필요가 없다.
선택적으로, 각 컬렉션에 대해 스키마 유효성 검사를 사용하여 관리 제어를 할 수 있다.
Why is using MongoDB better than using MySQL?
MongoDB를 사용하는 것이 MySQL보다 나은 이유는 무엇인가?
MongoDB를 사용함으로써 애플리케이션을 보다 빠르게 구축, 매우 다양한 형태의 데이터를 처리하며 애플리케이션 규모에 맞게 효율적으로 관리할 수 있기 때문이다. 때문에 다양한 규모의 조직에서 MongoDB를 특히 클라우드 데이터베이스로써 채택중이다.
MongoDB documents가 현대적인 객체 지향 프로그래밍 언어(Object-oriented programming language)에 자연스럽게 매핑되므로 개발이 간소화된다.
MongoDB를 사용하면 객체 코드를 관계형 테이블로 변환하는 복잡한 ORM(Object-Relational Mapping) 계층을 제거할 수 있다.
또한 MongoDB의 유현한 데이터 모델은 데이터베이스 스키마가 비즈니스 요구사항에 맞게 발전할 수 있게 한다.
MySQL의 경직된 관계형 구조는 코드의 객체를 관계형 구조에 맞게 조정해야 하므로 애플리케이션에 오버헤드를 추가하고 개발 속도를 늦춘다.
또한 MongoDB는 분산 데이터 센터 내부적, 외부적으로도 확장될 수 있으므로 MySQL과 같은 RDB에서 이전에는 달성할 수 없었던 새로운 수준의 가용성과 확장성을 제공할 수 있다.
따라서 MongoDB와 함께 데이터 볼륨 및 처리량 측면에서 개발 품질이 향상됨에 따라 애플리케이션의 변경과 downtime 작동하지 않는 시간 없이 쉽게 확장할 수 있다.
이와는 대조적으로 MySQL을 통한 확장에는 상당한 공수가 들어가게 된다.
Always-On Availability
상시 이용 가능 여부
MongoDB의 데이터 레플리케이션은 1급 객체이다. 즉, 동일한 데이터 세트를 보유한 MongoDB 노드 그룹을 Replica set 레플리카 세트 라고 한다.
Replica Set는 개발자가 일관성 요구사항을 세부적으로 조정하여 성능과 가용성을 높임일수 있게 함으로써 데이터 고가용성을 실용할 수 있다.
Blazing fast failover 초고속 시스템 대체 작동
데이터베이스가 다운되면 매초가 중요하다. MongoDB는 기본적으로 장애를 감지하여 자동으로 5초 이내로 새 기본 노드를 선출하여 대체한다. 오작동하는 노드를 교체하는 동안 애플리케이션이 게속 작할 수 있다.
MySQL의 failover 대체작동은 수동 프로세스로, 가장 중요한 순간에 운영 팀에 부담을 줄 수 있다. 데이터베이스 노드가 중단된 경우, 교체 작업을 시작하기도 전에 몇 분이 걸릴 수 있다.
Tuneable consistency guarantees 조율가능한 일관성 보장
예를 들어, 낮은 읽기 문제를 요청하는 애플리케이션은 오래된 데이터를 볼 수 있는 대신 데이터베이스 지연 시간을 줄이고 심각한 데이터베이스 중단이 발생한 경우에도 계속 작동할 수 있다.
MySQL은 Tuneable consistency guarantee를 지원하지 않아, 개발자의 옵션을 제한한다 - 여러 데이터베이스 노드가 작동 중단된 경우에도 애플리케이션을 사용할 수 있도록 보장하지 못한다.
Faster Development with JSON Documents
JSON Documents를 사용한 빠른 개발
엄격한 Rows 행 과 Columns 열이 아닌 유연한 JSON documents 데이터로 작업하면 작업 생산성을 높일 수 있다. 관계형 데이터베이스에서 MongoDB로 전환한 후 개발 주기를 3~5배로 단축한 팀을 찾는 것은 어렵지 않다. 왜 그럴까?
Documents are natural: Documents는 자연스럽다.
document는 애플리케이션과 동일한 형태로 데이터를 표현한다.
MySQL과 같은 RDB의 rows, columns 와는 다르게, 데이터가 배열 및 하위 documents에서 구조화될 수 있다 - 이는 애플리케이션이 데이터를 리스트와 구성요소로 데이터/인스턴스를 표현하는 것과 동일한 방식이다.
Documents are flexible: Documents는 유연하다.
각각의 document는 다른 document들과 다른 속성을 가진 데이터를 저장할 수 있다.
예를 들어, 남성복 품목 세부 정보를 저장하는 document가 TV 세부 정보를 저장하는 document와 다른 속성을 저장하는 제품 카탈로그를 생각해보자.
이는 일반적으로 다형성이라고 불리는 특성이다. JSON documets를 사용하면 새로운 속성을 추가하고 싶을 때 centralized databse schema 중심 데이터베이스 스키마를 변경하지 않고도 새로운 속성을 추가할 수 있다.
MySQL과 같은 RDB에서 schema를 변경하는 것은 다운타임이 발생하거나 상당한 성능 오버헤드가 발생하게 된다.
Documents make application fast: 애플리케이션 성능을 향상시킨다.
여러 관계형 테이블에 분산되지 않고 단일 document에 저장된 엔티티 데이터를 사용한다면 데이터베이스는 단일 위치에서 읽고 쓰기만 하면 된다.
또한 객체 관련 모든 데이터를 한 곳에 저장하면 개발자가 쿼리 성능을 쉽게 이해하고 최적화할 수 있다.
Scale Infinitely and Cheaply
경제적이고 무한한 확장
MongoDB는 자체적으로 여러 노드에 걸쳐 데이터를 샤딩하는 기능을 지원한다.
Scale your applications cheaply 애플리케이션의 경제적 확장
샤딩은 데이터베이스 부하를 다수의 하드웨어에 분산시켜 경제적이다.
저비용의 장치를 많이 구매하는 것이 관계형 데이터베이스를 확장하기 위해 소수의 고비용의 장치를 구매하는 것보다 대부분 비용이 적게 든다.
No need to make changes to your application to scale 확장을 위해 애플리케이션을 변경할 필요가 없다
애플리케이션과 연결된 대부분의 관계형 데이터베이스 시스템에서 데이터베이스를 확장하는 것은 애플리케이션 레벨을 변경하거나 데이터베이스가 더 큰 서버로 마이그레이션 되는 동안 downtime을 견뎌야한다.
관계형 데이터 모델에서 빈번한 JOIN이 이루어지므로 여러 노드에 걸쳐 테이블을 배치하는 작업은 신중하게 이루어져야 한다.
MongoDB에서는 언제든지 새 샤드를 추가할 수 있으며 데이터 마이그레이션을 자동으로 시작한다. 응용 프로그램에서 변경할 내용은 없다. 샤드는 Atlas Global Cluster를 사용하여 짧은 지리적으로 전 세계에 분산될 수 있고, 전 세계의 사용자는 짧은 latency로 액세스 할 수 있다.
Which query language does each database use?
각 데이터베이스가 사용하는 query language는 무엇인가?
두 데이터베이스 모두 풍부한 쿼리 언어를 지원한다.
다른 관계형 데이터베이스처럼 MySQL은 SQL를 사용한다.
MongoDB는 개발자가 사용하기 쉽게 설계된 MongoDB Query Language (MQL)을 사용한다.
Is MongoDB faster than MySQL?
MongoDB는 MySQL보다 빠른가?
데이터베이스 성능은 데이터베이스 설계, 응용프로그램 쿼리 패턴 및 일부 데이터베이스 부하와 같은 다양한 변수에 따라 크게 달라질 수 있다.
MongoDB의 document 모델은 관련 데이터를 함께 저장하므로 MySQL의 다수의 테이블에서 데이터를 JOIN하는 것 보다 MongoDB에서 단일 문서를 검색하는 것이 더 빠른 경우가 많다.
많은 사용자가 평가 이후 MySQL보다 MongoDB를 선택했는데, 이는 규모 확장과 개발 생산성 측면에서 우수했기 때문이다.
Does MySQL support JSON documents?
MySQL이 JSON documents를 지원하는가?
위에서 언급된 이유로 MySQL와 다른 관계형 데이터베이스들에서 JSON을 지원하기 시작했다.
그렇지만, 단순히 JSON 데이터 타입을 지원하는 것만으로는 MySQL에 document의 이점과 생산성을 가져다주진 않는다. 왜일까? MySQL의 접근 방식은 개발자의 생산성을 향상시키는 것이 아니라 떨어뜨릴 수 있다.
다음의 몇가지를 고려하자.
- SQL에 의존확장:
JSON document의 내용을 쿼리하고 조작하기 위해 value에 엑세스 하는 데에 별도의 MySQL 관련 SQL 함수를 이용해야 한다. 이는 대부분의 개발자에게 익숙하지 않은 작업이다.
또한, BI 플랫폼, 데이터 저장소 커넥터, ETL, ESB 파이프라인 등과 같은 써드파티 SQL 툴을 지원하지 않는다.MongoDB API는 업계 표준 툴과 커넥터에 의해 널리 이해되고 채택된다. 몇몇 메가 벤더 데이터베이스 회사들은 MongoDB API를 자체적으로 채택하기까지 했다.
- Legacy Relational Overhead 기존의 관계형 오버헤드:
JSON을 지원하더라도 MySQL 사용자는 여전히 JSON 데이터와 상호 작용하기 위해 낮은 수준의 JDBC/ODBC 드라이버와ORM Object Relational Mapping와 같은 SQL/관계형 함수의 다수 계층에 종속 되어 있다.
이러한 계층은 습 학습 오버헤드를 유발한다.
또한 ORM은 관계형 구조에 경험이 풍부한 개발자에게도 성능 및 쿼리 효율성을 최적화하기 어려운 것으로 여겨지는게 일반적인 인식이다.
더불어 JSON 데이터 쿼리 최적화 통계는 일반 관계형 데이터 유형 통계보다 더 제한적이다.MongoDB 드라이버는 개발자가 사용하는 프로그래밍 언어에 관용적이고 자연스러운 방법과 기능으로 구현된다.
- 복잡한 데이터 처리:
JSON 데이터를 사용할 때, MySQL 드라이버는 JSON을 애플리케이션에서 사용할 수 있는 기본 데이터 유형으로 정확하고 적절하게 변환할 수 없다.
여기에는 다양한 유형의 숫자 값(예: 부동 소수점, 64비트 정수, 소수점) 타임스태프 및 날짜, Java의 Map, List, Python의 Dictionary 및 List 등이 포함된다.
개발자는 애플리케이션에서 텍스트 기반 JSON을 수동으로 변환해야 하며,
서로 다른 document에서 여러 데이터 유형을 처리할 수 있는 필드를 가질 수 없게 되고(다형성),
값의 계산, 정렬 및 비교가 어렵고 오류가 발생하기 쉽다.MongoDB에서는 MongoDB와 그 드라이버가 사용하는 BSON(Binary Encoded JSON)은 일반 텍스트 기반 JSON에서 지원되지 않는 고급 데이터 유형을 지원한다.
- No Data Governance 데이터 가버넌스(관리)가 없음:
MySQL은 데이터베이스에 삽입되거나 업데이트된 JSON의 스키마를 검증하는 네이티브 매커니즘을 제공하지 않으므로 개발자는 데이터 거버넌스 제어를 적용하기 위해 애플리케이션 또는 데이터베이스 측 기능을 추가해야 한다.MongoDB는 JSON Schema IETF 표준을 기반으로 하는 스키마 유효성검사를 통해 개발자와 DBA는 각 MongoDB 컬렉션에 미리 지정된 스키마를 정의하고 적용할 수 있다.
- Schema Rigidity 스키마 엄격성:
MySQL 사용자는 일반 관계형 데이터에 대한 스키마를 정의해야 한다.
그 다음 새 애플리케이션 요구 사항을 수용하도록 스키마를 수정하면 기존 데이터가 새 스키마에 복사될 때까지 일부 작업에 대해 테이블이 lock 되므로, 스키마 마이그레이션 중에는 애플리케이션을 중지해야 한다.MongoDB는 개발자와 DBA는 완전히 동적인 스키마 유연성과 데이터베이스에 저장된 모든 데이터에서 일부 애플리케이션에 필요한 거버넌스 컨트롤을 모두 가져갈 수 있다.
REFERENECE
