Change Streams 프로덕션 권장 사항
변경 스트림이 열려 있는 컬렉션 또는 데이터베이스를 제거하거나 이름을 변경하는 경우 변경 스트림 커서는 oplog의 포인트로 이동할 때 닫힙니다. fullDocument :
updateLookup 옵션을 사용하는 변경 스트림 커서의 경우 문서 조회 시 null을 반환할 수 있습니다.
제거된 컬렉션에 대해 변경 스트림을 재개하려고 시도하면 오류가 발생합니다. 변경 스트림이 캡처한 마지막 이벤트와 컬렉션 제거 이벤트 사이에 컬렉션에서 발생한 모든 데이터 변경 사항은 손실됩니다.
변경 스트림 응답 문서는 16MB BSON 문서 제한을 준수해야 합니다. 변경 스트림을 여는 컬렉션의 문서 크기에 따라 결과 알림 문서가 16MB 제한을 초과하면 알림이 실패할 수 있습니다. 업데이트된 전체 문서를 반환하도록 구성된 변경 스트림의 업데이트 작업 또는 한도 이하인 문서로 작업을 삽입하거나 교체가 그 예입니다.
복제본 세트
중재자 멤버가 있는 복제본 세트의 경우, 충분한 데이터 보유 멤버를 사용할 수 없어 작업을 과반수 커밋할 수 없는 경우 변경 스트림이 유휴 상태로 유지될 수 있습니다.
예를 들어 데이터 보유 노드 두 개와 중재자가 있는 3인 복제본 세트를 생각해 보세요.장애나 업그레이드 등으로 인해 보조 서버가 다운되면 쓰기가 다수 커밋될 수 없습니다. 변경 스트림은 계속 열려 있지만 알림을 보내지 않습니다.
이 시나리오에서는 애플리케이션이 마지막으로 수신한 작업이 복제본 세트의 oplog에 남아 있는 한 다운타임 동안 발생한 모든 작업을 따라잡을 수 있습니다.
업그레이드나 심각한 재해 등으로 인해 상당한 다운타임이 예상되는 경우 예상 다운타임보다 더 긴 시간 동안 운영이 유지되도록 oplog의 크기를 늘리는 것이 좋습니다. rs.printReplicationInfo()를 사용하여 oplog의 크기 및 작업 시간 범위 등 oplog 상태에 대한 정보를 검색합니다.
샤딩된 클러스터
변경 스트림은 글로벌 논리 클럭을 활용하여 샤드 전반의 변경 사항을 전체 순서로 제공합니다.MongoDB는 변경 순서가 유지되고 변경 스트림 알림을 수신된 순서대로 안전하게 해석될 수 있도록 보장합니다.예를 들어 샤드 3개로 샤딩된 클러스터에 대해 열린 변경 스트림 커서는 샤드 3개 모두에서 변경된 총 순서에 따른 변경 알림이 반환됩니다.
변경 사항의 전체 순서를 보장하기 위해 mongos는 각 변경 알림에 대해 샤드에 최신 변경 사항이 있었는지 각 샤드를 확인합니다. 컬렉션에 대한 활동이 거의 없거나 전혀 없는 또는 '콜드(cold)' 상태인 하나 이상의 샤드를 가진 샤딩된 클러스터는 변경 스트림의 응답 시간에 부정적인 영향을 미칠 수 있습니다. 왜냐하면 여전히 mongos에서 해당 콜드 샤드를 확인하여 변경의 전체 순서를 보장해야하기 때문입니다. 이 효과는 지리적으로 분산된 샤드 또는 대부분의 작업이 클러스터의 샤드 하위 집합에서 발생하는 워크로드에서 더 분명할 수 있습니다. 콜드 샤드의 지연 시간을 최소화하려면 더 낮은 periodicNoopIntervalSecs 값을 지정할 수 있습니다.
샤딩된 컬렉션의 활동 수준이 높으면 mongos가 전체 샤드의 변경 사항을 따라잡지 못할 수 있습니다. 이러한 유형의 컬렉션에는 알림 필터를 활용하는 것이 좋습니다. insert 작업만 필터링하도록 구성된 $match 파이프라인을 전달하는 것이 한 예입니다.
샤딩된 컬렉션의 경우 multi : true로 업데이트 작업을 하면 해당 컬렉션에 대해 열린 모든 변경 스트림이 고아 문서에 알림을 보낼 수 있습니다.
샤딩되지 않은 컬렉션이 샤딩되는 순간부터 변경 스트림이 첫 번째 청크 마이그레이션을 따라잡을 때까지 변경 스트림 알림 문서의 documentKey는 전체 샤드 키가 아닌 문서의 _id만을 포함합니다.
Indexes
change stream은 인덱스를 사용할 수 없습니다. MongoDB는 oplog 컬렉션에서 인덱스 생성을 지원하지 않습니다. 따라서 서버 성능에 영향을 줄 수 있으므로 특정 대상을 대상으로 하는 변경 스트림을 많이 열지 않도록 합니다.