MongoDB의 구조 (1/2)
1. MongoDB의 구조
기본적인 구조는 비슷하나, 명칭이 다르다.
NoSQL은 3가지 database가 있다.
- admin: 권한 부여 & 일부 관리 작업을 하려면 admin Database 접근이 필요하다.
- local: 모든 인스턴스는 local database를 소유한다. local database 자체는 복제되지 않는다.
- config: shared cluster에서 각 shard 정보를 저장한다.
DBA 입장에서는 admin을 사용하고, local은 멤버 개별적으로 필요한 정보를 저장한다.
운영이 아닌 개발만 하는 경우. 위의 DB가 보일수도 안 보일수도 있다.
2. 왜 대세가 됐을까?
RDS에서 하지 못한 걸 했더니 인기가 많아졌다.
MongoDB는 Storage Engine이 있는데 데이터가 메모리와 디스크에 어떻게 저장하고 읽을지 관리하는 컴포넌트이다. MySQL과 동일하게 Plugin 형태로 있어서 몽고 DB도 다양한 Storage Engine을 사용할 수 있다.
3.2 버전부터 기본 Storage Engine이 WiredTiger로 바꼈다. 이게 도입이 되면서 MongoDB의 성능이 큰 폭으로 올라가서 많은 사람들이 사용하기 시작한다. wiredTiger 도입은 몽고 DB 입장에서 터닝포인트인 셈.
3.2 이전에는 MMAPv1을 사용했었다. 기존 NMAPv1 압축이 안 됐지만, wiredTgier는 압축이 가능해진다. 이에 성능이 엄청 향상됐고, 그다음 Lock이 엄청난 성능에 영향을 끼치게 된다.
대규모 트래픽 시에 write의 경우 절대 건들지 못한다. 하지만 wiredTiger는 컬렉션에서 도큐먼트로 lock이 내려가니까 경합이 덜 발생한다. 이에 write가 좀 쓸만해졌고, 계속해서 버전이 올라갈수록 성능이 개선되고 있다.
위의 전체적인 내용을 몰라도 MongoDB는 wiredTiger를 기본으로 사용하고 있다는 걸 알기만 해도 된다.
3. Collection의 특징
동적 스키마를 갖고 있어서 스키마를 수정하려면 필드값을 추가/수정/삭제하면 된다. Collection 단위로 index를 생성할 수 있고, Collection 단위로 shard를 나눌 수 있다.
몽고 DB는 타입이 다 달라도 삽입이 가능하고, 스키마가 자유롭다. 그래도 스키마를 어느 정도 정해줘야 한다. 그 이유는 연관된 데이터를 같은 컬렉션에 담는 게 중요하다. 중구난방이면 조회가 어렵다. 그래서 어느정도 스키마를 유지시켜줘야 한다.
몽고 DB는 스키마가 자유로워서 스키마 없이도 데이터 삽입이 가능하다.
사실상 스키마가 없다고 보면 된다. 여러가지 데이터 유형의 제약이 없다.
보통 JSON 형태로 표현하고, 저장이 될 때는 BSON(binary JSON) 경량 형태로 저장된다. 이로 인해 더 빠르고 효율적으로 저장한다.
4. Document의 특징
JSON 형태로 표현하고, BSON(Binary JSON) 형태로 저장된다. 모든 Document에는 "_id" 필드가 있고, 없게 생성하면 ObjectId 타입의 고유 값을 저장한다. 생성 시에 상위 구조인 Database나 Collection이 없다면 먼저 생성하고, Document를 생성한다.
Document의 최대 크기는 16MB로 고정하는데 이는 도큐먼트 크기가 한 없이 커지는 걸 방지하기 위해서다.
5. 정리
- Database->collections->document->field 순으로 구조가 형성됐다.
- admin, config, local DB는 MongoDB를 관리할 때 사용한다.
- Collection은 동적 스키마를 갖는다.
- Document는 JSON 형태로 표현하고, 저장할 때 BSON 형태로 저장된다.
- Document는 고유한 "_id" 필드를 갖고 있다.
- Document의 최대 크기는 16MB로 고정됐다.
출처: FastCampus 대용량 데이터 & 트래픽 처리