Database/MongoDB

mongodump 와 mongorestore 를 이용한 논리 백업 및 복구백업mongodump 는 공식적으로 제공되는 유일한 백업 도구인데, 논리적인 수준의 백업을 실행하는 도구이다.즉 물리적인 파일을 복사하는게 아니라 서버에 로그인 후 도큐먼트를 한건씩 덤프해서 bson 파일로 저장하는 방식이다. 그래서 mongodump 는 백업 시간뿐 아니라 복구 시간도 상당히 오래 걸린다.mongodump 는 기본적으로 특정 시점의 스냅샷을 덤프하지 않는다.즉, mongodump 도구가 데이터를 덤프하는 동안 변경되는 데이터에 대해서는 백업이 일관된 상태를 유지하지 못한다.그래서 mongodump 를 이용해 백업하는 경우 --oplog 옵션을 이용해서 실행해야만 덤프가 실행 중인 동안 변경되는 데이터의 OpLog ..

MongoDB 서버는 보안을 위해 크게 다음과 같이 5가지 형태의 코어 기능을 제공한다.형태설명인증 Authentication 권한 Authorization 암호화 Encryption데이터 필드 단위의 암호화와 데이터 파일을 DBMS 서버 하단에서 처리해주는 TDE 로 나눠볼수 있는데, 일반적으로 DBMS 에서 지원하는 방식은 TDE 방식이 많이 사용됨현재 MongoDB 서버에서 TDE 는 엔터프라이즈 버전에서만 지원되는데, WiredTiger 스토리지 엔진의 플러그인 모듈로 직접 개발해 사용할 수 있음 ( 하단 설명 )감사 Auditing어떤 사용자가 어떤 쿼리를 언제 실행했는지 모두 로그로 기록하여 DBMS 의 데이터에 문제가 발생했을 때 언제 누가 실행한 쿼리때문에 문제가 발생했는지 확인할 수 있음..

쿼리 최적화MongoDB 의 쿼리 튜닝에서 주의 깊게 살펴봐야 할 부분과 성능 튜닝이 필요한 쿼리를 수집하는 방법을 알아본다. 실행 계획의 쿼리 튜닝 포인트- 쿼리가 인덱스를 사용하는가 ?- 도큐먼트 정렬이 인덱스를 사용하는가 ?- 필드 프로젝션이 인덱스를 사용하는가 ?- 인덱스 키 엔트리와 도큐먼트를 얼마나 읽었는가 ?- 인덱스의 선택도는 얼마나 좋은가 ?- 어떤 스테이지가 가장 많은 시간을 소모하는가 ? 슬로우 쿼리 로그 분석 및 튜닝MongoDB 서버에서 실행된 쿼리 중 100 밀리초가 넘게 걸린 쿼리는 MongoDB 서버의 로그 파일에 모두 로깅된다.100 밀리초는 기본값으로 slowMs 옵션을 조정하면 로깅 시간을 조정할 수 있다. MongoDB 서버의 로그 파일에 기록된 슬로우 쿼리 로그에서 ..

MongoDB 서버도 세컨드리 인덱스를 지원하므로 하나의 컬렉션은 최소 1개 이상의 인덱스를 가질 수 있다.여러 개의 인덱스를 가지고 있을 때는 각 쿼리를 실행할 때 어떤 인덱스를 사용하는 것이 최적인지 확인하고 사용할 인덱스를 선별하는 작업이 필요하다.MongoDB 에서 같은 패턴의 쿼리는 같은 실행 계획을 재활용할 수 있도록 실행계획을 캐시하는 기능이 있다. 실행 계획쿼리의 처리 과정MongoDB 서버는 쿼리를 처리하기 위해 실행 계획을 사용하는데, 이 실행 계획은 트리 구조의 스테이지로 구성된다.실행계획 예시를 들어본다.실행계획설명FETCH -> IXSCAN인덱스 레인지 스캔을 실행한 다음 컬렉션 데이터 파일에서 도큐먼트를 읽음SORT -> COLLSCAN컬렉션 풀 스캔으로 조건에 일치하는 도큐먼트..

기본 CRUD 쿼리프로그램 언어로 MongoDB 쿼리를 작성하는 것은 쿼리 빌더와 같은 래퍼 클래스의 도움을 받으면 되기 때문에 그다지 어렵지 않으나, BSON 쿼리를 직접 손으로 입력해야 하는 경우에는 괄호 쌍을 맞추어야 한다. BSON 쿼리는 기존 RDBMS 의 SQL 과 문법과 오퍼레이터만 다를 뿐 실제 대부분의 기능을 제공하고 있다.RDBMS SQLMongoDB BSONINSERTdb.collection.insert()Batch DMLdb.collection.bulkWrite()UPDATE REPLCAE(INSERT ON DUPLICATE KEY UPDATE)db.collection.update()db.collection.update( { }, { $set : { } }, { upsert : tr..

데이터베이스와 컬렉션MongoDB 서버에서도 다른 RDBMS 와 동일하게 하나의 인스턴스에 여러 개의 데이터베이스를 가질 수 있다.각 데이터베이스는 다시 여러 개의 테이블을 가질 수 있다.MongoDB 에서는 NoSQL 을 지향하기에 테이블이라는 이름보다는 컬렉션이라는 이름을 공식적으로 사용한다. 네임스페이스MongoDB 에서는 데이터베이스 이름과 컬렉션의 이름 조합을 네임스페이스라고 한다.네임스페이스에서 데이터베이스와 컬렉션 이름 사이는 반드시 . 으로 구분해야 한다.인덱스의 네임스페이스는 컬렉션의 네임스페이스에 추가로 인덱스의 이름을 붙인 형태이다.요약하면 '데이터베이스.컬렉션.$인덱스' 와 같이 부여된다.네임스페이스가 중요한 이유는 MongoDB 내부적으로 데이터베이스 이름이나 컬렉션 이름이 단독으..

Read & Write Concern 과 Read PreferenceMongoDB 는 분산처리를 기본 아키텍처로 선택하고 있기 때문에 단일 노드에서 단일 노드의 격리 수준뿐 아니라 레플리카 셋을 구성하는 멤버들 간의 동기화까지 제어할 수 있어야 한다.그래서 MongoDB 서버는 데이터의 Durability 수준에 따라 데이터를 변경하거나 조회할 수 있도록 Read, Write Concern 옵션을 제공한다.클라이언트 프로그램에서 쿼리 단위로 다르게 설정할 수 있다. Write Concern트랜잭션의 시작과 종료를 명시적으로 실행할 방법이 없다.따라서 MongoDB 서버는 도큐먼트를 저장할 때 사용자의 데이터 변경 요청에 응답이 반환되는 시점이 트랜잭션의 커밋으로 간주된다.이렇게 사용자의 변경 요청에 응답..

인덱스 속성인덱스 필드가 NULL 이 아닌 경우나 지정된 조건을 만족하는 경우에만 인덱스에 추가할 수 있다.TTL 인덱스도 제공한다. 프라이머리 키와 세컨드리 인덱스MongoDB 프라이머리 키 필드는 사용자가 필드의 이름을 결정할 수 없다.프라이머리 키 필드는 무조건 _id 라는 이름으로 도큐먼트에 저장되어야 한다.그렇지 않으면 MongoDB 가 자동으로 _id 라는 이름의 필드를 생성해서 추가한다. 컬렉션마다 단 하나의 프라이머리 키만 가질 수 있고, 그 외의 인덱스는 모두 세컨드리 인덱스라고 한다.프라이머리 키는 반드시 유일한 값을 가져야 하므로 유니크 인덱스를 생성할 수 없는 해시 인덱스는 프라이머리 키로 사용할 수 없다.또한 하나의 샤드에서는 중복 값에 대한 체크를 MongoDB 가 해주지만, 샤..

잠금멀티 쓰레드의 동시 처리 중에 발생할 수 있는 쓰레드 간의 충돌 문제를 막기위해 데이터베이스와 컬렉션 그리고 도큐먼트들의 잠금을 사용한다.여러 계층의 데이터베이스 오브젝트들에 대한 동시 처리를 위해서 인텐션 락과 다중 레벨의 잠금을 활용한다.또한 MongoDB 잠금은 서버 차원에서 처리되는 잠금과 스토리지 엔진에서 처리되는 잠금으로 나누어 볼 수 있다. MongoDB 엔진의 잠금명시적 잠금과 묵시적 잠금으로 나눠볼 수 있는데, 명시적 잠금은 글로벌 잠금 뿐이며 나머지 모든 잠금은 묵시적 잠금이다.데이터베이스나 컬렉션에 대한 잠금은 모두 묵시적이며, 이는 쿼리가 실행될 때 자동으로 획득했다가 해제되는 잠금이다. 글로벌 잠금글로벌 잠금은 MongoDB 서버 인스턴스에 단 하나만 있는 잠금으로 인스턴스 잠..

해시인덱스해시 인덱스는 B-Tree 인덱스만큼 범용적이지는 않지만 고유특성이 있는 인덱스 중 하나다.단일검색에는 최적화되지만 범위검색이나 정렬된 결과를 가져오는 목적으로는 사용할 수 없다.쿼리의 검색 성능을 향상시키기 위한 인덱스의 목적보다는 해시 샤딩을 구현하기 위해 꼭 필요한 인덱스이다. 해시 인덱스의 구조 및 특성해시 인덱스의 가장 큰 장점은 빠르다는 것이다.해시 인덱스는 트리 형태의 구조가 아니므로 검색하고자 하는 값이 주어지면 해시 함수를 거쳐 바로 버켓의 주소를 알아내며, 그 버켓을 읽어 즉시 해당 데이터의 레코드를 가져오기 때문이다. 일반적으로 버켓은 메모리에 로드되어 있고 해시 인덱스로 데이터 레코드를 읽는것은 디스크를 한번만 읽어서 데이터를 가져올 수 있음을 의미한다.해시 인덱스는 B-T..