생산을위한 MongoDB writeConcern

Question

내 질문에 너무 일반적인 것 같지만 누락 된 데이터를 제공 할 준비가되었습니다.

우리는 소셜 네트워크와 같은 것을 만듭니다. 더 나은 읽기 성능을하고 마스터 인스턴스의 생활을 쉽게하기 위해, 우리는 우리의 replicaSet에

readPreference=secondaryPreferred 

을 설정했습니다. 하지만 여기에서 데이터를 읽으려면 보조 인스턴스에 데이터가 기록된다는 보장이 없으므로

w=3 

옵션을 설정해야했습니다. 지금까지 모든 것이 작동하는 것처럼 보였지만 내 로컬 replicaSet의 측정 값은 다음 삽입 통계를 보여줍니다.

Inserting 300 objects: 
w=1 - 0.10s 
w=3 - 1.31s 
Insertion 5000 objects: 
w=1 - 0.6s 
w=3 - 14.6s 

질문이 차이가 예상됩니까? 아니면 잘못된 것입니까?

Answer 1

w = 3은 기본 (w = 1)의 확인 응답 외에 보조 서버 중 두 개 이상에 데이터가 성공적으로 복제되었다는 확인을 기다리고 있기 때문에 성능 차이가 예상됩니다.

간단히 말해 w = 1은 기본 동작의 작업이 완료되었음을 알리기 만하면됩니다. 발생하는 중복 키 오류 또는 네트워크 오류와 같은 오류는 승인의 일부로보고됩니다.

http://docs.mongodb.org/manual/reference/write-concern/

은 위의 링크를 참조하십시오, 당신은 당신이 낮은 지연의 안전 거래를하게 낮은 쓰기 우려가 볼 수 있습니다.

높은 수준의 내구성 또는 안전성을 원한다면 j = 1을 사용하여 작업이 저널에 기록되었다는 확인을 기다릴 수 있습니다 (장애 복구 가능). w> N은 작업이 다른 구성원에게 성공적으로 복제되었는지 확인하기 위해> N 복제 구성원으로부터의 승인을 기다려 안전성을 높입니다. 분명히하기 위해 w> 1은 드라이버에게 복제본에 쓰도록 지시 할 필요가 없습니다. w = N을 사용하기로 결정했다면 복제 세트 구성원이 실패하고 N 미만이되면 나쁜 상황에 처할 수 있다는 점에 유의하십시오. w = majority는보다 유연한 옵션입니다.

마지막으로, 보조를 읽는 이유를 다시 평가할 수 있습니다. MongoDB가 비동기 복제를 사용하기 때문에 보조 데이터베이스는 결국 일관성이 있습니다. 일관된 읽기가 필요하다면, 기본 읽기를 읽는 것이 더 합리적입니다. 2 차에서 읽는 이유가 스케일링이라면 스케일링을위한 기본 메커니즘이므로 샤딩을 고려해야합니다. 2 차 서버에로드를 분산 시키면 확장 성이 거의 향상되지 않습니다. 작업은 복제본으로 복제되므로 쓰기로드가 적어 지므로 많은 이점을 얻을 수 없습니다. 때로는 다른 유형의 작업 부하를 분산하는 것이 좋습니다 (메모리 사용률이 향상 될 수 있음). 예를 들어 2 차에서 MR 작업을 실행하는 것이 적합 할 수 있습니다. 복제본 세트는 주로 고 가용성을위한 것입니다. 자동 장애 조치 및 네트워크 파티션 문제를 제공하는 내결함성이 있습니다.