이전 포스팅에서 MongoDB BSON에 대해서 알아보았는데
이번에는 MongoDB를 사용하기전에 알았으면 좋았을 기본적인 개념과 특징들을 정리해볼 예정이다.
점점 MongoDB를 사용하는 추세가 올라가는데 한번 알아보자.
그럼 시작!
MongoDB
"MongoDB가 뭐야?" "그거 NoSQL아니야?"
맞다. MongoDB는 확장성과 유연성을 제공하는 document db로 NoSQL 데이터베이스의 한 종류이다.
근데 음... 와닿지 않는다.
document db... NoSQL.. 많이 들어는 봤는데 뭘까?
NoSQL?
NoSQL이라하면 SQL만을 사용하지 않는(Not Only SQL)이라는 뜻의 말로 사용 한다고 한다.
NoSQL의 의미는 사람마다 다르게 해석하는 것 같은데 NoSQL 데이터베이스는 관계형 데이터베이스가 데이터를 저장하는 방식 이외에 다른 방식으로 데이터를 저장하는 데이터베이스라는 의미는 동일한 것 같다.
그럼 다른 방식의 데이터베이스엔 뭐가 있을까
- Key-Value Database: 단순하게 key-value로 데이터를 저장해 이러한 쌍의 모음으로 이루어져 있는 데이터베이스
- In-Memory Database: 빠른 응답속도를 위해 데이터베이스의 데이터에 대한 작업을 메인 메모리에서만 수행하는 데이터베이스
- Wide-Column Store: 이 데이터베이스는 명칭이 조금 나뉘는 것 같은데 테이블, 행, 동적인 열에 데이터를 저장하여 RDBMS와 다르게 각 행이 동일한 열을 가질 필요가 없는 데이터베이스로 생각하면 될 것 같다.
- Graph Datase: 흔히 알고 있는 그래프의 노드와 간선에 데이터를 저장하는 데이터베이스로 일반적으로 사람이나 장소가 노드에 저장되고, 노드간의 관계정보가 간선에 저장된다.
그럼 이제 MongoDB의 Document Database에 대해서 알아보자.
Document DB
데이터를 document에 저장하는 데이터베이스라는 개념의 documentDB
document에는 하나의 개체및 관련 메타데이터에 대한 정보를 저장한다.
여기서 document를 RDBMS의 레코드와 비슷하다고 보면 되는데 하나의 행이라고 생각하면 이해가 조금 쉬울 것이다.
MySQL Row = MongoDB Document, MySQL Table = MongoDB Collection
MySQL: 행 하나 조회해서 알려줘봐!
MongoDB: document 하나 조회해서 알려줘봐!
그럼 기본적인 document의 구조를 한번 봐보자.
{
"BookId": "9992-192",
"Title": "안녕 MongoDB",
"Year": "1998"
}위와 같이 BookId와 같은 key와 9992-192와 같은 value의 쌍들로 이루어져 있고 value에는 숫자, 날짜, 배열, 객체등 다양한 유형이 올 수 있다.
이러한 document 데이터베이스는 정해진 스키마가 없기 때문에 다음 document에 동일한 필드에 대해서 값이 다른 데이터 타입으로 올 수도 있고 필드가 없어져 있을 수 있다.
그러므로 다음과 같은 장점을 가진다.
- 애플리케이션의 요구사항에 따라 스키마가 유연하게 변경될 수 있다.
- 각각의 document는 독립적인 개체이므로 여러 테이블 사이에 조인을 신경써야 하는 RDBMS에 비해 여러 데이터베이스 서버에 분산되어 있어도 영향이 없기 때문에 수평적 확장에 용이하다.
특징
MongoDB가 Document Oriented(문서 지향)적이라는 특징말고 다른 특징도 한번 살펴보자.
1)인덱스
MongoDB에서는 인덱스를 생성해서 효율적인 쿼리 실행을 할 수 있다.
MongoDB는 collection수준에서 인덱스를 정의하고 collection내에 있는 문서의 모든 필드나 하위 필드에 대해 지원한다.
기본적으로 인덱스가 없는 경우 MongoDB는 collection내의 모든 document를 스캔하여 쿼리 문과 일치하는 문서를 선택하기 때문에 쿼리문의 성능을 개선하려면 인덱스를 정의해야 한다.
2)확장성
MongoDB는 데이터를 여러 서버로 분할하는 샤딩을 사용해서 수평적 확장을 가능하게 하는데 여러 서버로 나누고 용량을 늘리기 위해서는 단지 서버를 추가하여 확장해 나갈 수 있다.
다만 샤딩할 때 MongoDB의 기본 필드인 _id컬럼이 ObjectId로 되어있는 경우 새로 데이터를 삽입 할때마다 단일 샤드로 이동하기 때문에 해시 된 샤딩을 사용하자.
3)복제와 고가용성
샤딩이 데이터를 분할이라면 복제는 데이터를 그대로 복사하는 것이다.
동일한 데이터 복사본을 여러 서버에 저장하면서 한 서버가 다운되도 데이터가 저장된 다른 서버에서 데이터를 쉽게 검색할 수 있게 하여 고가용성을 보장한다.
4)집계
데이터 집계를 위한 기본 도구를 제공하므로 대량의 데이터를 쉽게 분석하고 조작할 수 있다.(pipeline)
_id 필드
MySQL에서 PK가 있다면 MongoDB에는 _id필드가 존재한다.
하나의 document를 저장할 때 별도로 _id필드에 값을 넣지 않으면 MongoDB가 알아서 _id필드에 값을 넣어주는데 ObjectId값을 넣는다.
그러니 하나의 document당 하나의 _id필드는 무조건 존재하게 된다.
이 _id필드에는 컬렉션 내에서 고유하면서 배열을 제외한 BSON 타입의 데이터 유형이 올 수 있다.
그럼 ObjectId값을 내가 생성해서는 못 넣을까?
MongoDB에서는 ObjectId의 값을 직접 생성하고 ObjectId로 반환된 값을 문자열로 변환해주는 메소드도 제공하고 있다.
만약 ObjectId를 직접 생성해서 넣어주고 싶다면 ObjectId("507f1f77bcf86cd799439011")와 같이 24자의 16진수 문자열 값을 넣어주면 되고
ObjectId(32)와 같이 정수를 사용해서 TimeStamp를 조정한 ObjectId를 생성할 수도 있다.
TimeStamp를 조정한다는 말은 ObjectId의 처음 4바이트는 생성 시간별 정렬을 위해 TimeStamp로 이루어져 있어 정수로 생성하면 해당 4바이트를 정수값에 해당하는 16진수로 변경해준다는 말이다.
MongoDB에서는 _id필드의 고유성 보장을 위해 ObjectId이외의 대안들을 설명해주고 있는데 ObjectId는 데이터베이스 수준에서 고유성을 보장한다고 한다.
애플리케이션 수준에서의 고유성을 보장받으려면 UUID나 ObjectId가 중복되었을 경우의 처리를 고려해보자.
마치면서..
MongoDB는 유연한 스키마, 샤딩을 통한 로드밸런싱, 데이터 복제를 통한 고가용성, 개발자는 JSON 형식으로 데이터를 처리등 명확한 장점이 많다.
조심할 점이라면 높은 성능의 기반인 메모리를 사용하기 때문에 메모리 사용량과 하나의 document당 정해져 있는 최대크기정도라고 생각하면 될 것 같은데 후자는 MongoDB에서 방법을 설명해주니 공부해보면 될듯하다.
또한 프로젝트에 ODM을 사용을 하는지도 궁금하다.
개인적인 프로젝트에는 Node를 사용해 Mongoose가 있었지만 ODM을 사용하려면 스키마를 정의해야 하고 ODM에 익숙해지고 싶지 않아서 사용하지 않았다.
그리고 어차피 Mongoose도 MongoDB를 기반으로 동작할테니...
참고
Documents
What is NoSQL?
What is a Document Database?
MongoDB Features
