MERN Stack을 사용하여 고도로 I/O 집중적 인 애플리케이션 (좌석 가용성에 기반한 선택)을 연구 중입니다. 앱에 동시 사용자가 2000 명이 있어야합니다. 두 개의 MongoDB 인스턴스 (하나는 RAM에 있음)와 다른 하나는 하드 드라이브에 사용하는 것이 현명한 방법인지 알고 싶습니다.두 개의 MongoDB 인스턴스 실행
사용 가능한 자리를 저장하는 데 사용되는 RAM입니다. 그리고 하드 드라이브 하나가 정기적으로 데이터를 백업합니다. 하지만 동시에 서버가 충돌하면 MongoDB의 RAM 데이터가 손실된다는 것을 알고 있습니다.
아무도 나를 안내 할 수 없습니까? 내가 대신 AJAX의 소켓 IO를 사용하고
...
난 당신이 필요하다고 생각하지 않습니다. 좋은 RAM과 함께 좋은 서버를 얻을 수 있으며 인덱스를 올바르게 작성하면 모든 것이 잘 작동합니다.
또한 Mongo 2는 Mongo 2처럼 각 업데이트에서 전체 데이터베이스를 잠그지 않습니다.
나는 최선의 접근법이 읽기를 향상시키기 위해 Memcached과 같은 것을 사용할 것이라고 믿습니다. 또한 데이터베이스 성능을 향상시키고 자동 장애 조치를 사용하기 위해 샤딩 및 복제 세트를 사용합니다.
는 서버를 다시 시작할 때 두통이 것 또한 고려와 MongoDB를 이미 정확하게 아웃 - 오브 - 박스처럼 동작하기 때문에, 당신의 데이터 ...
이 불필요한 것을 잃게됩니다.
오래된 엔진 (MMAPv1)은 메모리 매핑 파일을 사용하고있었습니다. 즉, 데이터가있는만큼 많은 RAM을 가지고 있으면 실제로 자동 하드 드라이브 백업이있는 메모리 내장 데이터베이스처럼 작동합니다.
새로운 엔진 (Wired Tiger)은 조금씩 다른 방식으로 작동하지만 일반적으로는 동일합니다. 캐시 크기 (config key storage.wiredTiger.engineConfig.cacheSizeGB)를 설정할 수 있습니다. 캐시 크기가 충분히 크면 자동 하드 드라이브 미러링을 사용하는 메모리 내장 데이터베이스가 다시 생깁니다.
자세한 내용은 the storage FAQ입니다.
MMAP 및 WiredTiger와 메모리 내 엔진의 비교가 잘못되었습니다. 모든 데이터가 메모리에 들어 있어도 완전히 다른 동작. 메모리 내 엔진은 단순히 디스크에 쓰거나 디스크에서 읽지 않아도되기 때문에 모든 성능 테스트에서 대기 시간, 성능 및 예측 가능성 측면에서 뚜렷한 특징이 있습니다. 따라서 MMAP/WiredTiger가 메모리 내 엔진과 동일하게 작동한다고 말하는 것은 잘못된 것입니다. –
@AminJ 부정확 한 이의 제기. MMAPv1과 WT는 모두 RAM의 인덱스 외에도 많은 양의 데이터를 유지하려고합니다. 이 데이터 세트를 작업 세트라고합니다. 구성에 따라이 데이터 세트는 선택한 쓰기 문제로 정의 된 동작 외에도 디스크에 "동기화"되거나 동기화되지 않을 수 있습니다. 지금까지 _behavior_ (구현이 아니라)는 높은 수준의 관점에서 동일합니다. 필자가 볼 수있는 한, 필자는 MongoDB가 RAM에있는 많은 양의 데이터를 유지하면서 수동 관리가 목에 걸릴 수 있으므로 전용 메모리 내 DB로 실행하지 않는 것이 좋습니다. –
작업 집합에 대한 올바른 관찰이지만 여기서는 읽기가 중요하지 않습니다. 쓰기 문제는 클라이언트가 승인을 얻는 방법에 영향을 미치지 만 궁극적으로 mongo는 데이터를 디스크로 플러시합니다 (비활성화 할 수있는 저널 또는 예를 들어 wiredtiger 체크 포인트). 그리고 이것은 몽고의 예측 가능성과 대기 시간에 막대한 영향을줍니다. 나는 여전히 MMAP 또는 WiredTiger를 사용하여 메모리 내 엔진을 모방 할 수 있다고 말하는 것이 너무 단순하다고 생각합니다. –
당신이 말하는 것은 스케일링 문제입니다. 확장에 있어서는 두 가지 옵션이 있습니다. 병목 현상을 유발하는 리소스를 기존 설정 (더 많은 RAM과 더 빠른 디스크)에 추가하거나 설정을 확장하십시오. 먼저 리소스를 추가하면 리소스를 추가하지 않아도 리소스를 추가해야합니다.
어느 시점에서이 "스케일 업"은 더 이상 가능하지 않으며 노드 사이에로드를 분산해야합니다.
MongoDB에는 (논리) 노드 사이에로드를 분산하는 기능이 있습니다 (sharding).
기본적으로 다음과 같이 작동합니다. 각 복제본 세트는 샤드라는 논리 노드를 형성합니다. 각 샤드는 차례대로 데이터의 하위 집합 만 보유합니다. 샤드에 직접 연결하는 대신, 어떤 샤드가 쿼리에 응답하기위한 데이터를 보유하고 있고 새로운 데이터를 어디에 쓸 것인지를 알고있는 mongos query router을 통해 데이터를 에이커한다.
carefully selecting your shard key으로 읽기와 쓰기가 샤드간에 균등하게 분산되어야합니다.
사이드 노트 : 복제본 세트 대신 독립 실행 형 인스턴스에 프로덕션 데이터를 넣는 것은 내 책의 과실 테두리를 교차시킵니다. 오늘날의 (렌털 된) 하드웨어의 가격을 감안할 때 MongoDB 복제본 세트를 사용하는 것보다 단일 실패 지점을 제거하는 것이 더 쉬워 진 적이 없습니다.
Mongo의 여러 인스턴스를 실행하려면 샤 도드를 분할해야합니다. 웨더 (Wether) 또는 확장 할 필요가없는 것은 테스트를 수행하거나 실제로 너무 많은 사용자에게 문제가있는 무언가를 실행 한 후에 만 대답 할 수있는 것입니다. – adeneo