MongoDB - GridFS

MongoDB는 BSON(Binary JSON)를 이용하여 바이너리
데이터를 저장할 수 있고 시스템 자원의 낭비를 방지를
하기 위하여 BSON(Binary JSON)의 크기를 16MB로 제한
최대 문서 크기는 단일 문서가 과도한 양의 RAM을 사용하거나 전송 중에 과도한 양의 대역폭을 사용하지 않도록 하는 데 도움이 됨

16MB 이상의 바이너리 데이터를 저장하기 위한 기능으로 서브 컬렉션(Collection)을 이용한 GridFS 분산파일시스템을 제공한다. GridFS는 바이너리 데이터를 작은 청크 조각으로 나누어 분산 저장한다.

GridFS는 MongoDB가 16MB보다 큰 파일을 저장하고 검색하는 데 사용하는 파일 추상화 방법

GridFS는 대용량 파일을 기본 크기 255kB의 동일한 청크로 나누어 별도의 문서로 저장. 마지막 청크는 필요한 크기로 저장함. 청크 크기보다 크지 않는 파일에는 필요한 만큼의 공간화 일부 추가 메타데이터만 사용하는 최종 청크만 존재

MongoDB는 파일을 저장하기 위해 두 개의 컬렉션을 생성
첫 번째 컬렉션 – chunks– 파일 청크를 저장
두 번째 - files- 파일 메타데이터를 저장
GridFS에서 파일을 검색하면 드라이버가 필요에 따라 청크를 재조립합니다.

GridFS는 MongoDB에 파일을 저장하는 적합한 메커니즘으로, 문서 모델에서 제공하는 스키마 없는(따라서 더 빠른) 정보 검색을 보완합니다.

GridFS를 사용하는 경우

• 전체 파일을 메모리에 로드하지 않고 대용량 파일의 일부 정보에 액세스하려는 경우 GridFS를 사용하여 전체 파일을 메모리로 읽지 않고 파일 섹션을 호출할 수 있습니다.

• 파일이 더 작은 청크로 분할되기 때문에 파일의 특정 섹션에 액세스하기가 더 쉬워져 전체 파일을 로드하는 메모리 소모 작업을 절약할 수 있습니다.

• 파일 시스템이 디렉토리의 파일 수를 제한하는 경우 GridFS를 사용하여 필요한 만큼 파일을 저장할 수 있습니다.

• 파일과 메타데이터를 자동으로 동기화하고 여러 시스템과 시설에 배포하려는 경우 GridFS를 사용할 수 있습니다. 지리적으로 분산된 레플리카 셋를 사용하는 경우 MongoDB는 파일과 해당 메타데이터를 여러 mongod인스턴스 및 시설에 자동으로 배포할 수 있습니다.

전체 파일의 내용을 원자적으로 업데이트해야 하는 경우 GridFS를 사용하지 마십시오. 대안으로 각 파일의 여러 버전을 저장하고 메타데이터에서 파일의 현재 버전을 지정할 수 있습니다. 파일의 새 버전을 업로드한 후 원자적 업데이트에서 "최신" 상태를 나타내는 메타데이터 필드를 업데이트하고 나중에 필요한 경우 이전 버전을 제거할 수 있습니다.

또한 파일이 모두 16MB BSON 문서 크기 제한보다 작은 경우 GridFS를 사용하는 대신 각 파일을 단일 문서에 저장하는 것이 좋습니다.

GridFS의 Collections

컬렉션 chunks_

{
  "_id" : <ObjectId>,
  "files_id" : <ObjectId>,
  "n" : <num>,
  "data" : <binary>
}

chunks document 컬렉션에는 다음 필드가 포함됩니다.

chunks._id 청크의 고유한 ObjectId입니다 .

chunks.files_id files 컬렉션에 지정된 "부모" 문서의 _id.

chunks.n 청크의 시퀀스 번호입니다. GridFS는 0부터 시작하여 모든 청크에 번호를 매깁니다.

chunks.data 청크의 페이로드는 BSON Binary 유형입니다.

컬렉션 files_

{
  "_id" : <ObjectId>,
  "length" : <num>,
  "chunkSize" : <num>,
  "uploadDate" : <timestamp>,
  "md5" : <hash>,
  "filename" : <string>,
  "contentType" : <string>,
  "aliases" : <string array>,
  "metadata" : <any>,
}

files document 컬렉션에는 다음 필드 중 일부 또는 전부가 포함됩니다.

files._id document의 고유 식별자입니다.
_id의 데이터 타입은 원본 문서에 대해 선택한 데이터 유형입니다. MongoDB 문서의 기본 유형은 BSON ObjectId 입니다 .

files.length 문서의 크기(바이트)입니다.

files.chunkSize 바이트 단위 의 각 청크 크기입니다 .
GridFS는 문서를 chunkSize필요한 만큼만 큰 마지막 청크를 제외하고 기본 크기의 청크로 나눕니다. 기본 크기는 255KB입니다.

files.uploadDate GridFS에서 문서를 처음 저장한 날짜입니다. 이 값에는 Date유형이 있습니다.

files.filename (선택) GridFS 파일의 사람이 읽을 수 있는 이름입니다.

files.metadata (선택) 메타데이터 필드는 모든 데이터 유형일 수 있으며 저장하려는 추가 정보를 보유할 수 있습니다. 컬렉션의 문서에 추가 임의 필드를 추가하려면 files 메타데이터 필드의 개체에 추가하십시오.

레플리카 셋

레플리카 셋은 기본적으로 자동 장애 넘김 기능이 있는 마스터-슬레이브클러스터이다.

마스터-슬레이브 클러스터와 레플리카 셋의 가장 큰 차이점은 레플리카셋은 여러 마스터 노드를 가진다는 점이다. 레플리카 셋은 모든 것이 자동화되어 있다. 우선 스스로 슬레이브를 마스터로 바꾸고 일관성을 유지하는 등 많은 관리 작업을 알아서 처리한다. 마스터 노드에 장애가 발생할 경우 다른 노드로 요청을 넘겨주어 레플리카 셋은 개발자 관점에서 사용 편의성을제공한다.

작동 원리

MongoDB의 복제 설정은 언제나 적어도 두 대의 서버 또는 노드로구성된다.

하나는 마스터로 클라이언트의 일반적인 요청을 처리한다.

다른 하나(또는 셋은)는슬레이브이고 마스터에 저장된 데이터를 복제하는 역할을 한다.

슬레이브는 주기적으로 마스터에 새로운 연산 기록을 요청하고 데이터의 사본에 그대로 수행한다.

마스터 노드가 수행한 연산을 똑같이 수행함으로써 슬레이브는 마스터 데이터와 같은 최신 데이터를 유지한다.
샤드란 클러스터 전체 데이터 중 일부를 책임지는 하나 이상의 서버군을 의미한다.

시스템을 실제로 운용할 때는 보통 레플리카 셋으로 샤드를 구성한다.

MongoDB는 시스템 장애에 대비하기 위하여 Master-Slave와 Replica-Set 두 가지 복제 정책을 제공한다. 두 복제정책을 통하여 MongoDB에서는 데이터 읽기작업을 분산함으로써 시스템의 안정성을 보장한다. Master-Slave 구조는Master 노드에서 Slave 노드로 데이터를 백업하여 시스템의 신뢰성 및 성능을 향상시킨다. 그러나 Master- Slave 구조에서 Master 노드에 장애가 생기면 모든 Node를 사용하지 못한다는 단점이 있다. MongDB는 이런 단점을 보완하기 위하여 Replica-Set 복제방법을 제공한다. Replica-Set복제방법은 Master 노드에서 장애가 발생하면 다른 Slave노드에서 새로운 Master 노드를 선출하여 시스템의 신뢰성을 보장한다.
현존하는 많은 데이터베이스는 데이터가 급격히 증가할 때 여러 노드로 데이터를 확장하는 샤딩(Sharding) 기능을 제공한다. 그러나 대부분 데이터베이스에서 제공하는 샤딩(Sharding) 기능은 사용자 및 운영자는 수동으로
노드를 추가해야하고 분할해야 하는 등 관리상의 어려움이 가지고 있다. MongoDB에서는 오토샤딩(AutoSharding)기능을 제공하여 사용자 및 운영자가 손쉽게 데이터를작은 청크 단위로 분할하여 여러 샤드로 분산하고 저장
할 수 있는 장점을 제공한다.
복제 세트
복제 및 자동 장애 조치를 구현하는 MongoDB 서버 클러스터입니다. MongoDB의 권장 복제 전략입니다. 복제를 참조하십시오 .

복제
여러 데이터베이스 서버가 동일한 데이터를 공유하여 중복성을 보장하고 로드 밸런싱을 용이하게 하는 기능입니다. 복제를 참조하십시오

링크
https://www.mongodb.com/docs/drivers/java/sync/current/fundamentals/gridfs/#overview
https://www.mongodb.com/docs/manual/reference/program/mongod/
https://www.mongodb.com/docs/manual/core/transactions/
https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/

https://koreascience.kr/article/JAKO201304164260607.pdf