[개념] MongoDB 알고 사용하기

💡 참고

Real MongoDB

---

📌 MongoDB vs. RDBMS(MySQL)

MongoDB	RDBMS(MySQL)
데이터베이스 (database)	데이터베이스 (database)
컬렉션 (collection)	테이블 (table)
도큐먼트 (document)	레코드 (record or row)
필드 (field)	컬럼 (column)
인덱스 (index)	인덱스 (index)
쿼리의 결과로 cursor 반환	쿼리의 결과로 record 반환

 

쿼리의 결과로 "커서(Cursor)" 반환

• MongoDB는 쿼리 결과로 커서를 반환하는데, 커서를 통해 실제 도큐먼트(레코드)를 가져올 수 있다.

• MongoDB에서 쿼리의 결과로 커서를 반환하는 이유는 쿼리의 결과를 클라이언트 서버의 메모리에 모두 담아두지 않아도 처리할 수 있게 하기 위해서이다.
  • MongoDB에서 커서를 읽을 때마다 서버에서 그때그때 도큐먼트를 가져오는 것은 아니고, 필요할 때마다 지정된 페이지 사이즈 단위로 서버로부터 전송받아 MongoDB 클라이언트 서버에 캐싱한 후에 유저에서 서비스하는 것임

 

스키마 프리(Schema-Free)

• 테이블의 컬럼 수준에만 적용되어, 사용할 컬럼을 미리 정의하지 않고 언제든지 필요한 시점에 데이터를 저장할 수 있다는 것을 의미함
• 대부분의 NoSQL 데이터베이스는 컬럼의 메타 정보(컬럼명, 데이터 타입 등)를 컬럼 값과 똑같이 사용자 데이터로 관리하므로 이런 자유로운 스키마 구성이 가능한 것임
• 하지만, MongoDB는 모든 부분에 있어서 스키마 프리라고 보기 어려움
  • 다른 NoSQL 데이터베이스와 달리 보조 인덱스를 생성할 수 있는데, 이때 보조 인덱스는 스키마 프리가 아니라 항상 먼저 인덱스를 구성하는 필드를 우선 정의해야 함

 

NoSQL

• SQL 문법을 지원하지 않고 자바스크립트 기반의 명령을 이용함
• MongoDB 명령어들은 기본적으로 JSON 도큐먼트를 인자로 사용함

db.users.insert({
	user_id: 'bcd001',
	age: 45,
	status: 'A'
})

 

📌 MongoDB vs. NoSQL(HBase)

• MongoDB와 HBase는 기본적인 데이터 저장 포맷에서 큰 차이가 있다.

 

MongoDB의 데이터 저장 포맷

• 컬럼이나 컬럼 패밀리 단위의 그룹 개념이 없고, 한 테이블의 데이터(document)는 하나의 데이터 파일로 저장됨
• 스키마를 별도로 정의하지 않는 DBMS이므로, 필드에 대한 정보는 모두 각각의 데이터(document)에 사용자 데이터와 함께 저장됨

• 도큐먼트에서 "_id"라는 이름의 필드가 자동으로 그 도큐먼트의 PK로 선정됨
• MongoDB에서는 Value의 JSON 값을 문자열 그대로 저장하지 않고, 문자열 기반의 JSON 텍스트를 BSON(Binary JSON)으로 변환해서 저장하여 마크업 문자로 인해 부가적으로 저장 공간이 낭비되지 않음

 

📌 MongoDB 아키텍처

• 응용 프로그램은 각 프로그래밍 언어별로 적절한 클라이언트 드라이버를 이용해 MongoDB 서버와 통신함
• MongoDB 서버의 네트워크 모듈은 클라이언트의 요청을 받아 MongoDB 서버의 쿼리 프로세서 모듈로 전달함
• 쿼리 프로세서 모듈은 여러 과정을 거쳐 사용자 데이터를 지정된 스토리지 엔진으로 주고받음
• 스토리지 엔진은 사용자 데이터를 디스크에 저장하거나 디스크로부터 읽어서 쿼리 프로세서 모듈로 전달함

 

📌 MongoDB 배포 형태

단일 노드 (Standalone)

• 해당 배포 형태의 MongoDB는 별도의 관리용 컴포넌트를 필요로 하지 않고, 복제를 위한 로그(OpLog)를 별도로 기록하지 않고, 다른 노드와의 통신도 필요하지 않음
• 위와 같은 단일 노드 구성에서는 응용 프로그램의 MongoDB 드라이버가 MongoDB 서버에 직접 연결하게 되며, 별도의 레플리카 셋을 가지지 않으므로 MongoDB 서버가 응답 불능 상태라 하더라도 자동 fail-over 및 HA 기능이 작동할 수 없음
  • 이로 인해 주로 개발 서버의 구성에 사용됨

 

단일 레플리카 셋 (Single Replica-set)

• 단일 레플리카 셋 구조에서도 별도의 관리용 컴포넌트가 필요하지 않지만, 레플리카 셋의 구축을 위해서 추가로 MongoDB 서버가 필요함
• 레플리카 셋은 특정 서버에 장애 발생 시 자동 복구를 위한 최소 단위이므로, 자동 복구가 필요하다면 항상 레플리카 셋으로 MongoDB를 배포해야 함
• MongoDB 서버는 직접 MongoDB 서버로 접속하지만, 단일 노드로 접속할 때와 달리 레플리카 셋(replicaSet) 옵션을 사용해야 함

세부 특징

• 하나의 레플리카 셋에는
  • 항상 하나의 프라이머리 노드와 1개 이상의 세컨드리 노드로 구성됨
  • 프라이머리 노드는 사용자의 데이터 변경 요청을 받아 처리하고, 세컨드리 노드는 프라이머리 노드로부터 변경 내용을 전달받아 서로의 데이터를 동기화함
  • 읽기 쿼리는 프라이머리 노드 뿐 아니라 필요 시 세컨드리 노드로 요청할 수도 있음
• MongoDB 레플리카 셋은 항상 레플리카 셋에 포함된 노드 간 투표를 통해 프라이머리 노드를 결정하므로, 가능하면 홀수 개의 노드로 구성하는 것이 좋음

 

샤딩된 클러스터 (Sharded Cluster)

• 샤딩된 클러스터 구조에서는 하나 이상의 레플리카 셋이 필요하며, 각 레플리카 셋은 자신만의 파티션된 데이터를 가짐
• 샤딩된 클러스터에 참여하고 있는 각각의 레플리카 셋을 '샤드'라고 하는데, 이 샤드들이 어떤 데이터를 가지는지에 대한 정보는 MongoDB 컨피그 서버가 관리함
• 해당 구조에서는 응용 프로그램의 MongoDB 드라이버가 직접 MongoDB 서버로 연결하도록 해서는 안됨
  • MongoDB 드라이버는 MongoDB 라우터(mongos)로 연결함
  • MongoDB 라우터는 자동으로 MongoDB 컨피그 서버로부터 각 샤드가 가지고 있는 데이터에 대한 메타 정보들을 참조하여 쿼리를 실행함
  • MongoDB 라우터는 이름 그대로 사용자로부터 요청된 쿼리를 실제 데이터를 가지고 있는 샤드로 전달하는 역할을 수행함
    • 또한, 모든 샤드로 쿼리를 요청하고 결과를 정렬 및 병합해서 반환하는 처리도 수행함
  • MongoDB 라우터는 각 샤드간의 데이터가 재분배되는 시점에도 동일한 역할을 수행하여 사용자가 알아채지 못하게 투명하게 데이터 밸런싱 작업을 처리함

•