[MongoDB] MongoDB란?

NoSQL

• Not Only SQL
• NoSQL 탄생 배경
  • 수평 확장 가능한 분산 시스템
  • Schema-less
  • 완화된 ACID

 

MongoDB

MongoDB

• C++로 짜여진 오픈 소스 데이터베이스
• 문서 지향적(Document-Oriented)으며 뛰어난 확장성과 성능을 자랑

MongoDB 특징

• 가용성, 확장성, 성능
• Document 기반 데이터베이스
  • Database > Collection > Document > Field 계층으로 이루어 짐

• ObjectId (12 bytes) - UNIX Timestamp (4 bytes) + Random Value (5 bytes) + Count (3 bytes)
  • RDBMS의 Primary Key와 같이 고유한 키를 의미
  • 차이점은 Primary Key는 RDBMS가 직접 부여한다면 ObjectId는 클라이언트에서 생성
  • ObjectId를 사용하여 MongoDB 클러스터 내에서 Sharding된 데이터를 빠르게 가져올 수 있음
• BASE (완화된 ACID) : 일관성을 어느 정도 포기하고 성능과 가용성을 우선시
  • Basically Avaliable
    • 언제든지 사용할 수 있다는 의미로 가용성이 필요하다는 뜻
  • Soft state
    • 외부의 개입이 없어도 정보가 변경 될 수 있다는 의미
  • Eventually consistent
    • 일시적으로 일관적이지 않은 상태가 되어도 일정 시간 후에는 일관적인 상태가 되어야 한다는 의미
• Full Index Support : 다양한 인덱스를 제공
  • Single Field Indexes : 기본적인 인덱스 타입
  • Compound Indexes : RDBMS의 복합 인덱스 타입
  • Multikey Indexes : 배열에 매칭되는 값이 하나라도 있으면 인덱스에 추가되는 멀티키 인덱스
  • Geospatial Indexes and Queries : 위치 기반 인덱스와 쿼리
  • Text Indexes : String에도 인덱싱이 가능
  • Hashed Index : BTree 인덱스가 아닌 Hash 타입 인덱스도 사용 가능
• Replicaset & High Availability : 간단한 설정으로 데이터 복제 지원 (가용성)
• Auto-Sharding : MongoDB는 처음부터 자동으로 데이터를 분산하여 저장하며, 하나의 컬렉션처럼 사용할 수 있게 지원 (scale-out)
• Aggregation Pipeline : 문서는 여러 단계의 파이프라인을 거쳐서 변화하고, 하나의 문서 형태로 집계 가능

 

메모리 크기와 MongoDB 성능 이슈

MongoDB는 데이터를 write할때, 논리적으로 memory 공간에 write하고 일정 주기에 따라, 이 메모리 block들을 주기적으로 disk로 write한다. 즉 이 디스크 writing 작업은 OS에 의해서 이루어 진다.

실제 메모리(RAM) 사이즈가 작더라도 OS의 가상메모리를 쓸 수 있다. 가상메모리는 block단위로 나뉘어지는데, 이 Block들은 Disk의 block에 mapping이 되고, 이 block들의 집합이 하나의 데이터 파일이 된다.

만약 RAM에 해당 데이터 블록이 없다면, page fault가 발생하게 되고, disk에서 그 데이터 블록을 로딩하게 된다. 물론 그 데이타 블록을 로딩하기 위해서는 다른 데이터 블록을 disk에 써야 한다. 즉, page fault가 발생하면, page를 memory와 disk 사이에 switching하는 현상이 일어나기 때문에, disk IO가 발생하고, 성능 저하를 유발하게 된다.

고로, 메모리가 성능을 크게 좌우한다는 것은 page fault와 관련이 있다. page fault시 disk로 write되는 데이터는 LRU 로직에 의해서 결정이 된다. 그래서 자주 안쓰는 데이터가 disk로 out되는데, 일반적인 application에서 자주 쓰는 데이터의 비율은 그리 크지 않다. (예를들어 게시판이나 블로그를 생각해보면, 앞의 1~10 페이지 정도를 사람들이 많이 본다.)

이렇게 자주 조회되는 데이터를 Hot Data라고 하는데,이 Hot Data들이 집중되서 메모리에 올라가도록 key 설계를 하는 것이 핵심이다. 쓸 데 없이 전체 데이터를 scan하는 등의 작업을 하게 되면, 무조건 page fault가 발생하기 때문에, table scan등이 필요한 시나리오는 별도의 index table(summary table)을 만들어서 사용하는 등의 전략이 필요하다.

 

 

 

 

 

출처: https://bcho.tistory.com/746