MongoDB에 인서트가 너무 많으면 어떻게됩니까? 모든 데이터가 저장되도록하는 방법은 무엇입니까?

MongoDB를 사용하여 주기적으로 측정 한 값을 저장합니다. ~ 100ms마다 많은 값이 문서로 삽입됩니다. 잘 작동하지만 성능 문제가 걱정됩니다. (안전한 삽입을 사용합니다. PyMongo에서는 이것이 기본값 인 것 같습니다.)

mongod가 하드 디스크에 저장할 수있는 것보다 초당 삽입 수가 더 많으면 어떻게됩니까? 경고가 있습니까? 아니면 단순히 자동으로 실패합니까?

쓰기로드를 모니터링하는 방법이 있습니까? db.serverStatus().writeBacksQueued전화 할 때 항상 false로 설정된 것을 찾았 습니다. 쓰기 대기열을 채우기 위해 얼마나 많은 데이터를 삽입해야하는지 테스트하려면 어떻게해야합니까?

mongostat잠금을 표시합니다. 이것이 내가 걱정해야 할 것입니까?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

쓰기 잠금에 대해 걱정해야합니까? 쓰기 잠금 기간 동안 삽입물은 어떻게됩니까? 나중에 큐에 저장되고 저장됩니까?

하나의 마스터와 하나의 슬레이브를 사용하는 간단한 복제 설정에 대해 생각하고 있습니다. 초기 동기화 또는 재 동기화 프로세스가 데이터베이스를 잠그나요?

(버전 2.4.3을 사용하고 있습니다.)

업데이트 : 내 자신의 질문에 부분적으로 대답했다고 생각합니다. 작은 테스트 문서를 삽입하는 간단한 while 루프를 사용하여 초당 최대 12.000 개의 삽입물을 얻을 수있었습니다. 그러나 qr | qw는 여전히 읽기 및 쓰기 큐가 여전히 비어 있음을 보여줍니다.

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

이것은 인서트만으로도 많은 문제를 일으키지 않을 것이라고 생각합니다. "대량의 제거와 같은 다른 쓰기 작업과 함께 많은 쓰기 작업을 수행하면 큐가 급증하는 경향이 있습니다." ( 여기 에서 찾았 습니다 )

필자가 제기 한 질문 : 쓰기 큐가 장기간 증가하면 데이터는 어떻게됩니까?

여기에 자신의 질문에 대한 답변이 있습니다. 특히 방정식의 쓰기 잠금 측면에 대한 적절한 아이디어가 있습니다-12,000 삽입 / 초는 ~ 60 %의 쓰기 잠금을 제공합니다. 일관성있는 성능을 얻기위한 합리적인 수준입니다. 경합이 발생하고 일부 작전이 약간 느려질 수 있지만 실제로 80 %를 초과 할 때 많은 것들과 같이 약 80 %로 걱정하기를 원합니다. 용량 문제가 자주 발생하기 시작합니다.

다른 병목 현상, 특히 디스크에 얼마나 빨리 기록 할 수 있는지에 따라 문제가 발생할 수 있지만 시간이 지남에 따라 관련 통계 를 확인하려면 munin-node 플러그인으로 MMS를 설치하는 것이 좋습니다. 하드웨어 및 IO 통계를 제공 MongoDB 통계에 추가.

당신이 그것을 볼 때, 당신이 지켜보고 싶은 통계는 다음과 같습니다

• 평균 플러시 시간 (MongoDB의주기적인 디스크 동기화 시간)
• 하드웨어 탭의 IOStats (특히 IOWait)
• 페이지 결함 (디스크가 쓰기 작업 중이고 데이터를 읽어야하는 경우 부족한 리소스를 놓고 경쟁하게됩니다)

그때는 조금 복잡하지만 기본 아이디어는 다음과 같습니다.

• 평균 세척 시간이 증가하기 시작하면 걱정
• 여러 초 범위에 도달하면 한계에 도달했을 수 있습니다 (기록 된 데이터의 양과 디스크 속도에 따라 다르지만)
• 60 초에 도달하면 성능이 심각하게 저하되는 것을 볼 수 있습니다 (60 초마다 플러시가 발생하므로 본질적으로 큐잉됩니다)
• 높은 IOWait은 특히 디스크에서 읽어야 할 경우 특히 성능을 방해합니다.
• 따라서 페이지 결함 레벨을 보는 것도 중요합니다.

우리가 아직 언급하지 않은이 퍼즐의 다른 부분은 저널입니다. 이는 디스크에 데이터를 유지하며 (기본적으로 100ms마다) 동일한 볼륨에있는 경우 디스크로드에 추가됩니다. 따라서 디스크 사용률이 높으면 저널을 다른 디스크로 옮기는 것이 좋습니다.

실제 "마법의 숫자"는 존재하지 않습니다. 대부분의 경우 상대적인 것이므로 정상적인 트래픽에 대한 좋은 기준을 세우고, 추세가 있는지 확인하고, 한계가 무엇인지, 언제 테스트되는지를 테스트하십시오. 성능이 저하되기 시작하면 몸 상태가 좋아집니다.

모든 프리앰블을 마친 후 몇 가지 질문에 대해

mongod가 하드 디스크에 저장할 수있는 것보다 초당 삽입 수가 더 많으면 어떻게됩니까? 경고가 있습니까? 아니면 단순히 자동으로 실패합니까?

디스크를 위에서 설명한 수준으로 스트레스하기 시작하면 결국 모든 것이 느려지고 어느 시점에서 (그리고 이것은 시간 초과, 하드웨어의 강도, 예외 처리 방법에 따라 다름) 쓰기가 실패합니다- 최신 버전의 pymongo를 사용하는 경우 기본적으로 안전한 쓰기를 사용하므로 실패합니다. 좀 더 편집증이되고 싶다면 j : true에 대한 쓰기 문제를 수행 할 수 있습니다 . j : true 는 쓰기가 저널 (예 : 디스크)에이를 때까지 OK를 반환하기를 기다립니다. 물론 이것은 일반적인 안전 쓰기보다 속도가 느리지 만 디스크 용량 관련 문제를 즉시 표시 할 수 있으며 다른 작업을 차단 / 대기하는 데 사용할 수 있으며 기본적으로 데이터베이스가 작동하지 못하게하는 스로틀 역할을 할 수 있습니다 압도적.

하나의 마스터와 하나의 슬레이브를 사용하는 간단한 복제 설정에 대해 생각하고 있습니다. 초기 동기화 또는 재 동기화 프로세스가 데이터베이스를 잠그나요?

처음에는 전체 잠금을 다루었지만이 부분에 구체적으로 대답하려면 먼저 마스터 / 슬레이브가 아닌 복제 세트를 사용하고 있는지 확인하십시오 . 마스터 / 슬레이브 구현은 더 이상 사용되지 않으며 일반적으로 사용하지 않는 것이 좋습니다. 초기 동기화와 관련하여 읽기 측면에서는 기본로드에 약간의로드를 추가하지만 쓰기 측면에서는로드를 추가하지 않으므로 잠금 측면에서는 양호해야합니다.

쓰기 대기열이 장기간 증가하면 데이터는 어떻게됩니까?

위의 설명에서 알 수 있듯이 답변은 응용 프로그램 작성 방법, 쓰기 승인 방법 및 사용 가능한 용량에 따라 크게 달라집니다. 기본적으로 MongoDB의 디스크에 쓸 때 원하는만큼 안전 할 수 있지만 j:true위 의 논의에서 언급했듯이 성능 저하가 있습니다.

일반적으로 제한, 즉 잠금, 디스크 속도 등의 제한 요소를 파악한 후 시간이 지남에 따라 레벨을 추적하고 하드 한계에 도달하고 성능 문제를보기 전에 스케일 아웃 (샤딩) 또는 업 (더 나은 하드웨어)을 원합니다.

마지막으로, db.serverStatus().writeBacksQueued실제로는 샤드 환경에서 0이 아닌 메트릭이며 마이그레이션 중에 청크에 대한 쓰기 가 적절하게 처리되도록해야합니다 ( writeback listener가 처리 ). 따라서 본질적으로 여기에 빨간 청어가 있습니다-일반적인 쓰기 볼륨과 관련이 없습니다.