MongoDB는 웹 애플리케이션 및 인터넷 인프라용으로 설계된 데이터베이스 관리 시스템입니다. 예, MongoDB는 NoSQL 유형의 데이터베이스입니다.
(1) MongoDB는 문서와 컬렉션의 개념을 제안하며, 데이터 모델 구조로 BSON(JSON 유사)을 사용하며 그 구조는 2차원 테이블이 아닌 객체 지향적입니다. MongoDB의 사용자는 다음과 같습니다.
이러한 데이터 모델을 사용하는 MongoDB는 프로덕션 환경에서 높은 읽기 및 쓰기 기능을 제공할 수 있으며, mysql과 같은 SQL 데이터베이스에 비해 처리량이 크게 향상됩니다.
(2) 확장이 쉽고 자동 장애 조치가 가능합니다. 확장이 쉽다는 것은 데이터 세트를 샤딩하고 데이터 스토리지 압력을 여러 서버에 분산할 수 있는 샤딩 기능을 제공한다는 것을 의미합니다. 자동 장애 조치는 복제본 세트의 개념입니다. MongoDB는 마스터 노드가 비활성화되면 자동으로 슬레이브 노드를 마스터 노드로 승격하여 장애 조치를 수행할 수 있습니다.
(3) 데이터 모델은 객체 지향적이기 때문에 풍부하고 계층적인 데이터 구조를 나타낼 수 있습니다. 예를 들어 블로그 시스템에서는 '댓글'을 '기사' 문서에 직접 추가할 수 있습니다. 그러한 관계를 설명하기 위해 myqsl과 같은 세 개의 테이블을 만들 필요가 없습니다.
(1) 문서 데이터 유형
SQL 유형 데이터베이스는 정규화되어 있으며 기본 키 또는 외래 키 제약 조건을 통해 데이터의 무결성과 고유성을 보장할 수 있으므로 SQL 유형 데이터베이스는 종종 높은 데이터 무결성이 필요한 시스템에 사용됩니다. MongoDB는 이러한 측면에서 SQL형 데이터베이스보다 열등하며 MongoDB에는 고정된 스키마가 없습니다. 정확하게는 MongoDB에는 이러한 제약이 없기 때문에 데이터 저장 데이터 구조를 더 유연하게 만들고 저장 속도를 더 빠르게 만들 수 있습니다.
(2) 실시간 쿼리 기능
MongoDB는 관계형 데이터베이스의 실시간 쿼리 기능과 인덱싱 기능을 유지합니다(하위 레이어는 B 트리 기반). 이는 관계형 데이터베이스의 장점을 활용한 것으로, 동일한 유형의 NoSQL Redis와 비교할 때 위의 기능이 없습니다.
(3) 복제 기능
MongoDB 자체는 자동 장애 조치 및 확장된 읽기 기능을 제공할 목적으로 중복성을 달성하기 위해 여러 시스템에 데이터를 분산할 수 있는 복제 세트를 제공합니다.
(4) 속도와 내구성
MongoDB의 드라이버는 쓰기 의미론적 화재 및 망각을 구현합니다. 즉, 드라이버를 통해 쓰기를 호출하면 성공적인 결과가 즉시 반환될 수 있습니다( 오류가 보고되더라도) 이렇게 하면 쓰기가 더 빨라질 것입니다. 물론 어느 정도의 불안감이 있을 것이며 전적으로 네트워크에 의존하게 될 것입니다.
MongoDB는 실제로 mysql의 bin-log 로그와 유사한 저널링 로그 개념을 제공합니다. 삽입이 필요할 때 먼저 로그에 기록된 다음 실제 데이터 작업이 완료됩니다. 이렇게 하면 정전이 발생하거나 프로세스가 갑자기 중단되는 경우 데이터가 정확하지 않은지 확인할 수 있으며 복구 기능을 통해 저널링 로그를 읽어 복구할 수 있습니다.
(5) 데이터 확장
MongoDB는 샤딩 기술을 사용하여 데이터를 확장합니다. MongoDB는 샤드에 있는 데이터 블록을 자동으로 샤딩하고 전송할 수 있으므로 각 서버에 데이터가 모두 저장됩니다. 같은 크기.
MongoDB 코어 서버는 주로 mongod 프로그램을 통해 시작되며, MongoDB가 시작 시 사용하는 메모리를 구성할 필요가 없습니다. 왜냐하면 메모리 관리는 운영 체제에 맡기는 것이 가장 좋다는 설계 철학 때문입니다. 그리고 메모리 구성이 부족한 점이 MongoDB의 디자인적 특징입니다. 또한, mongos 라우팅 서버를 통해서도 샤딩 기능을 사용할 수 있습니다.
MongoDB의 주요 클라이언트는 대화형 js 쉘입니다. js 쉘을 사용하면 js 구문을 사용하여 MongoDB 데이터를 쿼리할 수 있습니다. sql 문을 사용하여 mysql 데이터를 쿼리할 수 있습니다. 또한, 다양한 언어로의 접근을 용이하게 하기 위해 다양한 언어의 드라이버 패키지가 제공됩니다.
데이터베이스 백업 및 복원을 위한 표준 도구인 mongodump 및 mongorestore. BSON 형식으로 출력하고 데이터베이스를 마이그레이션합니다.
mongoexport 및 mongoimport는 JSON, CSV 및 TSV 데이터를 가져오고 내보내는 데 사용됩니다. 데이터가 여러 형식을 지원해야 할 때 유용합니다. mongoimport는 대규모 데이터 세트의 초기 가져오기에도 사용할 수 있지만 가져오기 전에 mongoDB를 최대한 활용하려면 일반적으로 데이터 모델을 일부 조정해야 한다는 점에 유의하세요.
네트워크 스니핑 도구인 mongosniff는 데이터베이스로 전송된 작업을 관찰하는 데 사용됩니다. 기본적으로 네트워크로 전송되는 BSON을 사람들이 읽기 쉬운 쉘문으로 변환합니다.
따라서 MongoDB는 키-값 저장과 관계형 데이터베이스의 장점을 결합한 것이라고 결론 내릴 수 있습니다. 단순성으로 인해 데이터는 매우 빠르고 확장이 상대적으로 쉬우며 복잡한 쿼리 메커니즘을 갖춘 데이터베이스를 제공합니다. MongoDB는 64비트 서버에서 실행해야 하며, 별도로 배포하는 것이 가장 좋습니다. 데이터베이스이므로 hot 및 cold 대기도 필요합니다.
이 글은 API 매뉴얼이 아니기 때문에 여기서 쉘의 사용은 어떤 기능을 사용할 수 있는지, 어떤 문장을 사용하는지에 대한 기본적인 소개이기도 합니다. 주로 MongoDB 사용의 편리함을 보여주기 위한 것입니다. shell.특정 MongoDB 쉘 구문을 알아야 하는 경우 공식 문서를 참조하세요.
데이터베이스 생성은 필수 작업이 아닙니다. 데이터베이스와 컬렉션은 문서가 처음 삽입될 때만 생성되며 이는 데이터의 동적 처리와 일치합니다. 개발 프로세스를 단순화하고 속도를 높이며 네임스페이스의 동적 할당을 촉진합니다. 실수로 데이터베이스나 컬렉션이 생성되는 것이 걱정된다면 엄격 모드를 활성화할 수 있습니다.
위의 명령은 단순한 예일 뿐이며 이전에 데이터베이스 구문을 배운 적이 없다고 가정하고 동시에 SQL 쿼리 구문과 MongoDB 쿼리 구문을 배우기 시작하면 어떤 것이 더 쉬울까요? Java 드라이버를 사용하여 MongoDB를 운영하면 어떤 쿼리든 Hibernate에서 제공하는 쿼리 메소드와 동일하다는 것을 알 수 있습니다. 쿼리 조건 객체만 구축하면 쉽게 쿼리할 수 있습니다(예제는 다음에 설명하겠습니다). 저는 이전에 ES6에 익숙했기 때문에 MongoDB js 쉘로 시작하는 데 아무런 문제가 없었습니다. 제가 MongoDB를 깊이 사랑하게 된 이유는 바로 ES6의 단순성과 완벽한 쿼리 메커니즘 때문이었습니다.
Java 드라이버를 사용하여 MongoDB에 연결하는 것은 매우 간단한 일이며 간단한 참조와 추가, 삭제, 수정 및 쿼리입니다. Java 드라이버를 사용한 후에 Spring의 MongoDB 캡슐화는 자체적으로 제공되는 공식적인 것만큼 유용하지 않다는 것을 발견했습니다. 다음은 그 사용에 대한 간략한 데모입니다.
여기에는 간단한 링크와 간단한 MongoDB 작업의 예만 나와 있어 작업의 용이성을 보여줍니다. 드라이버를 사용할 때 MongoDB와의 통신은 TCP 소켓을 기반으로 합니다. 쿼리 결과가 너무 많아 첫 번째 서버에 넣을 수 없는 경우 getmore 명령이 서버로 전송되어 다음 쿼리 결과 배치를 얻습니다.
서버의 응답을 기다리지 않고 서버 시간에 데이터를 삽입합니다. 드라이버는 쓰기가 성공했다고 가정하고 실제로 클라이언트를 사용하여 개체 ID를 생성합니다. 안전 모드를 활성화하면 안전 모드에서 서버 측 삽입 오류를 확인할 수 있습니다.
MongoDB의 기본 데이터 단위를 명확하게 이해합니다. 관계형 데이터베이스에는 열과 행이 있는 데이터 테이블이 있습니다. MongoDB 데이터의 기본 단위는 BSON 문서입니다. 키 값에는 정의되지 않은 값을 가리키는 키가 있습니다. MongoDB는 즉각적인 쿼리를 제공하지만 단순 키-값 저장은 기반으로만 값을 얻을 수 있습니다. 단일 키이며 트랜잭션을 지원하지 않지만 다양한 원자 업데이트 작업을 지원합니다.
예를 들어 읽기-쓰기 비율은 얼마인지, 어떤 종류의 쿼리가 필요한지, 데이터가 어떻게 업데이트되는지, 동시성 문제가 있는지, 데이터 구조화 정도가 높은지 낮은지 등이 있습니다. 시스템 자체의 요구 사항에 따라 mysql 또는 MongoDB가 결정됩니다.
스키마를 설계할 때 다음과 같은 몇 가지 원칙에 주의하세요.
데이터베이스는 컬렉션의 논리적, 물리적 그룹입니다. MongoDB는 데이터베이스를 삽입할 때만 구문을 제공하지 않습니다. 컬렉션, 데이터베이스가 방금 생성되기 시작했습니다. 데이터베이스가 생성되면 일련의 데이터 파일이 디스크에 할당됩니다. 데이터베이스의 모든 컬렉션, 인덱스 및 기타 메타데이터가 이 파일에 저장됩니다. 데이터베이스를 통해 데이터베이스의 디스크 상태를 볼 수 있습니다.
컬렉션은 구조적으로나 개념적으로 유사한 문서의 컨테이너입니다. 컬렉션의 이름에는 숫자, 문자 또는 기호가 포함될 수 있지만 완전히 문자나 숫자로 시작해야 합니다.
컬렉션 이름은 128자 이하로 제한됩니다. 실제로 . 기호는 컬렉션에서 매우 유용하며 일종의 가상 네임스페이스를 제공할 수 있으며 이는 다른 컬렉션과 동일하게 취급됩니다. . 컬렉션으로 제공됩니다.
다음은 키 값입니다. MongoDB의 모든 문자열은 UTF-8 유형입니다. 숫자 유형에는 double, int 및 long이 포함됩니다. 날짜 유형은 모두 UTC 형식이므로 MongoDB에 표시되는 시간은 베이징 시간보다 8시간 느립니다. 전체 문서 크기는 16m로 제한됩니다. 이렇게 하면 보기 흉한 데이터 형식의 생성을 방지할 수 있고 작은 문서는 성능을 향상시킬 수 있기 때문입니다. 문서 일괄 삽입에 이상적인 개수 범위는 10~200개이며 크기는 16MB를 초과할 수 없습니다.
(1) 인덱스는 .explain() 메서드를 통해 특정 비교를 수행하는 데 필요한 작업 부하를 크게 줄일 수 있습니다.
(2) 쿼리를 구문 분석할 때 MongoDB는 최적의 계획은 가장 적합한 인덱스가 없을 때 먼저 각 인덱스를 쿼리에 사용하고 마지막으로 쿼리에 가장 적합한 인덱스를 선택합니다.
(3) a-b 인덱스가 복합된 경우 a만의 인덱스는 중복됩니다
(4) 복합 인덱스에서 키의 순서는 매우 중요합니다
(1) 단일 키 인덱스
(2) 복합 색인
(3) 고유 색인
(4) 희소 색인
색인이 생성된 필드에 null 값이 있는 경우 또는 많은 수의 문서에 색인된 키가 포함되어 있지 않습니다.
데이터 세트가 큰 경우 인덱스를 구축하는 데 시간이 오래 걸리고 프로그램 성능에 영향을 미칩니다.
mongorestore를 사용하면 인덱스가 다시 구축됩니다. 대규모 삭제가 수행된 경우
를 사용하여 인덱스를 압축하고 다시 작성할 수 있습니다.
(1) 느린 쿼리 로그 확인
(2) 느린 쿼리 분석
MongoDB 새 버전의 explain 메소드에는 매개 변수가 필요하며, 그렇지 않으면 일반 정보만 표시됩니다.
이 섹션에서는 또한 MongoDB 복제본 세트 구축의 단순성, 복제본 세트의 견고성 및 모니터링 용이성을 간략하게 설명합니다.
마스터-슬레이브 복제 기능, 핫 백업 기능 제공 및 장애 조치 기능
실제로 MongoDB의 복제본 세트 작업은 mysql의 마스터-슬레이브 작업과 유사합니다. 먼저 mysql의 마스터-슬레이브 데이터 흐름 프로세스를 살펴보겠습니다.
로그 MongoDB가 주로 의존하는 파일은 oplog입니다.
쓰기 작업은 먼저 기록되어 마스터 노드의 oplog에 추가됩니다. 동시에 모든 슬레이브 노드는 oplog를 복사합니다. 먼저, oplog에서 마지막 항목의 타임스탬프를 확인하고, 두 번째로 이 타임스탬프보다 큰 마스터 노드의 oplog에 있는 모든 항목을 쿼리하고, 마지막으로 해당 항목을 자신의 oplog에 추가하고 자신의 라이브러리에 적용합니다. 슬레이브는 긴 폴링을 사용하여 마스터의 oplog에서 새 항목을 즉시 적용합니다.
다음 상황이 발생하면 슬레이브 노드는 복제를 중지합니다.
로컬 데이터베이스는 모든 복제본 세트 요소 데이터와 oplog 로그를 저장합니다.
다음을 사용할 수 있습니다 복제 상황을 보는 명령
각 복제본 세트 구성원은 rs.status()를 통해 노드의 마지막 하트비트 감지 타임스탬프와 상태를 볼 수 있습니다.
이 점은 자세히 설명할 필요는 없지만, 특별한 경우가 있는데, 슬레이브 노드와 중재 노드가 모두 죽고, 마스터 노드만 남게 되면 스스로 강등됩니다. 슬레이브 노드.
마스터 노드의 데이터가 슬레이브 데이터베이스에 기록되지 않은 경우 마스터 노드가 슬레이브 노드가 되면 롤백이 트리거되고 해당 데이터는 제출된 것으로 간주되지 않습니다. 슬레이브 데이터베이스에 기록되지 않은 내용은 삭제되며, 롤백된 내용은 롤백 하위 디렉터리의 BSON 파일을 통해 복원할 수 있습니다.
(1) 단일 노드 링크 사용
슬레이브 노드에 링크할 경우에만 쓰기 작업이 거부됩니다. Mongo의 실행 후 잊어버리기 기능은 쓰기를 거부하는 예외를 잡아먹기 때문에 안전 모드는 사용되지 않습니다.
(2) 레플리카 세트 연동 사용
쓰기 상황에 따라 자동 장애 조치를 수행할 수 있지만, 레플리카 세트가 새로운 선택을 수행하지 않으면 여전히 실패가 발생합니다. 안전 모드를 사용하면 쓰기가 실패하는 상황이 여전히 발생하지만 실제로는 성공합니다.
샤딩은 데이터베이스 샤딩을 개념적으로 구현한 것입니다. 샤딩이 사용되는 이유와 그 원리 및 작동에 대한 간략한 요약은 다음과 같습니다.
데이터 양이 너무 많으면 인덱스와 작업 데이터 세트가 점점 더 많은 메모리를 차지하게 되므로 이 문제는 로드를 샤딩하여 해결해야 합니다
(1) 샤딩 구성 요소
(2) 샤딩의 핵심 작업
컬렉션 샤딩: 샤딩은 속성의 범위에 따라 분할됩니다. MongoDB는 소위 샤딩 키를 사용하여 각 샤딩을 허용합니다. 문서는 이 범위에서 자신의 위치를 찾습니다.
블록: 샤드에 위치한 연속적인 샤드 키 범위입니다. 샤드를 형성하는 여러 블록으로 이해될 수 있으며 샤드는 MongoDB의 모든 데이터를 구성합니다.
(3) 분할 및 마이그레이션
블록 분할: 초기화 중에는 블록이 하나만 있습니다. 최대 블록 크기가 64MB 또는 100,000개 문서에 도달하면 블록 분할이 시작됩니다. 원본 범위를 반으로 나누어 각각 동일한 수의 문서가 포함된 두 개의 블록을 만듭니다.
마이그레이션: 샤드의 데이터 크기가 다른 경우 마이그레이션이 발생합니다. 예를 들어 샤드 A에 더 많은 데이터가 있으면 샤드 A의 일부 블록이 샤드 B로 전송됩니다. 샤드된 클러스터는 샤드 간에 블록을 이동하여 균형을 유지합니다. 이는 밸런서라는 소프트웨어 프로세스에 의해 관리됩니다. 클러스터에서 가장 많은 블록을 가진 샤드가 샤드 간에 균등하게 분산되도록 하는 것입니다. 블록을 소유한 블록의 최소 조각의 블록 차이가 8보다 크면 등화기는 등화 프로세스를 시작합니다.
복제본 세트 2개, 구성 서버 3개, mongos 프로세스 1개 시작
샤딩 구성
(1) 샤딩 쿼리 유형
< p> ( 2) 인덱스샤드 컬렉션은 _id 필드와 샤드 키에만 고유 인덱스를 추가할 수 있으며 다른 곳에서는 추가할 수 없습니다. 이는 샤드 간의 통신이 필요하고 구현하기가 매우 복잡하기 때문입니다.
샤드가 생성되면 샤드 키를 기반으로 인덱스가 생성됩니다.
(1) 샤드 키는 수정할 수 없으며 샤드 키 선택이 매우 중요합니다.
(2) 비효율적인 샤드 키
(3 ) 이상적 샤딩 키
(1) 배포 토폴로지
다양한 데이터 센터에 따라 분할
여기에 그림 설명을 작성하세요
( 2) 최소 요구 사항
(3) 구성 고려 사항
클러스터 크기를 추정해야 하는 경우 다음 명령을 사용하여 기존 컬렉션을 샤딩할 수 있습니다.
( 4) 샤딩된 클러스터 백업
샤드 백업 시 밸런서를 중지해야 합니다.
(1) 배포 아키텍처
64비트 머신 및 32- 비트 머신은 Mongodb의 메모리를 제한하여 최대 값이 1.5GB가 되도록 합니다.
(2) CPU
Mongodb는 인덱스와 작업 세트가 모두 가능해야 CPU 병목 현상이 발생합니다. mongodb에서 CPU의 역할은 데이터를 가져오는 것입니다. CPU 사용량이 포화 상태인 경우 느린 쿼리 로그를 쿼리하여 쿼리 문제로 인한 것인지 확인하면 문제를 해결할 수 있습니다. 인덱스를 추가하여
Mongodb는 데이터를 쓸 때 CPU를 사용하지만, mongodb는 데이터를 쓸 때 한 번에 하나의 코어만 사용합니다. 이 문제는 샤딩을 통해 해결할 수 있습니다.
( 3) 메모리
mongodb는 큰 메모리를 보장합니다. 작업 세트 크기가 메모리를 초과하면 메모리에 데이터를 로드하는 작업이 증가하므로 성능 저하가 발생합니다.
(4 ) 하드 디스크
기본적으로 mongodb는 60초마다 강제로 디스크와 동기화합니다. 이를 백그라운드 새로 고침이라고 하며 I/O 작업을 생성합니다. 다시 시작하면 mongodb가 디스크의 데이터를 메모리로 로드하고 고속 디스크는 동기화 시간을 줄입니다.
(5) 파일 시스템
ext4 및 xfs 파일 사용 시스템
마지막 액세스 시간 비활성화
(6) 파일 설명자
Linux의 기본 파일 설명자는 1024이며 크게 늘려야 합니다.
(7) 시계
mongodb의 각 노드 서버 간 ntp 서버 사용
(1) IP 바인딩
시작 시 -bind_ip 명령 사용
(2) 인증
시작 시 --auth 명령 사용
(3) 복제본 세트 인증
keyFile 사용, 지불 keyFile 파일에 주의하십시오. 권한은 600이어야 합니다. 그렇지 않으면 시작되지 않습니다.
(1) 토폴로지
복제본 세트를 구축하려면 최소한 두 개의 노드가 필요하며 쿼럼 노드는 그렇지 않습니다. 자체 서버가 필요하지 않습니다.
(2) 저널링 로그
데이터를 쓸 때 로그가 먼저 기록되며 이때의 데이터는 하드에 직접 기록되지 않습니다. 그러나 저널링 로그는 메모리를 소비하므로 메인 라이브러리에서 닫고 슬레이브 라이브러리에서 시작할 수 있습니다.
솔리드 스테이트를 사용할 수 있습니다 저널링 로그용 드라이브
삽입할 때 다음을 수행할 수 있습니다. 드라이버는 피드백 전에 저널링이 삽입되도록 보장하지만 이는 성능에 큰 영향을 미칩니다.
logpath 옵션은 로그 저장 주소를 지정합니다.
-vvvvv 옵션(v가 많을수록 출력이 더 자세해집니다.)
db.runCommand({logrotare: 1}) 롤링 로그가 켜져 있음
(1) serverStatus
여기에 그림 설명 쓰기
(2) top
(3 ) db.currentOp()
mongodb 활동 데이터를 동적으로 표시
현재 mongodb 수신 대기 포트 위의 포트 1000 점유
(1) mongodump
데이터베이스 넣기 콘텐츠는 BSON 파일로 내보내지며 mongorestore는 이러한 파일을 읽고 복원할 수 있습니다.
(2) mongorestore
내보낸 BSON 파일을 데이터베이스에 복원
p>
(3) 원본 데이터 파일 백업
이렇게 할 수도 있지만 라이브러리 잠금 처리를 수행해야 합니다 db.runCommand({fsync:1,lock:true})
p>
db.$cmd 작업 전 .sys.unlock.findOne()이 잠금 해제 작업을 요청하지만 데이터베이스가 즉시 잠금 해제되지 않으며 db.currentOp()를 사용하여 확인해야 합니다.
(1) 수리
mongd --repair는 모든 데이터베이스를 복구합니다.
db.runCommand({repairDatabase:1})는 단일 데이터베이스를 복구합니다.
< p> 복구는 모든 데이터 파일을 읽고 다시 쓰고 Jourling 파일을 기반으로 각 인덱스를 다시 작성하는 것을 의미합니다.(2) 압축
압축은 데이터 파일을 다시 작성하고 컬렉션을 다시 작성합니다. 모든 인덱스 슬레이브 데이터베이스에서 종료하거나 실행해야 하는 경우, 쓰기 잠금이 추가되었는지 확인하기 위해 force 매개변수를 추가해야 합니다.
(1) 디스크 상태 모니터링
(2) 성능 향상을 위해 인덱스 및 쿼리 확인
일반적으로 가능한 한 적은 수의 문서를 스캔하십시오.
중복 인덱스가 없는지 확인하세요. 중복 인덱스는 디스크 공간을 차지하고 더 많은 메모리를 소비하며 각 쓰기에 더 많은 작업이 필요합니다.
(3 ) 메모리 추가
< p> dataSize 데이터 크기와 indexSize 인덱스 크기의 합이 메모리보다 크면 성능에 영향을 미칩니다.StorageSize가 dataSize를 두 배 이상 초과하는 경우 디스크 조각화로 인해 성능에 영향을 미치므로 압축이 필요합니다.