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