AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

제한 사항

Atlas Stream Processing에는 다음과 같은 제한 사항이 적용됩니다.

  • Atlas Stream Processing 최소 한 번 처리 만 지원합니다.

  • Atlas Stream Processing 수평 확장 지원 하지 않습니다.

  • Atlas Stream Processing은 parallelism 값을 지정할 수 있는 단계를 제외하고 변환 파이프라인 단계에 대해 단일 코어를 사용합니다.

  • 수직 자동 확장을 활성화 경우 maxTier 프로세서 또는 스트림 처리 작업 공간 최대 계층 크기로 를 설정하다 해야 합니다. 둘 다 설정하다 되지 않으면 프로세서는 오류를 반환하고 시작되지 않습니다.

  • 수직 자동 확장을 트리거하다 CPU 및 메모리 임계값은 구성할 수 없습니다. Atlas Stream Processing 이러한 임계값을 내부적으로 관리합니다.

  • 스트림 프로세서의 state.stateSize 는 해당 파드에서 사용 가능한 RAM 의 80%를 초과할 수 없습니다. 예시 들어 8GB 의 RAM 있는 SP30 계층 에서 스트림 프로세서의 최대 크기는 6.4GB 입니다. 스트림 프로세서의 state.stateSize 용량이 사용 가능한 RAM 의 80%에 가까워지면 프로세서를 중지하고 상위 계층 에서 다시 시작하는 것이 좋습니다. 스트림 프로세서가 이미 stream processing 작업 공간에 활성화된 최대 계층에서 실행 중인 경우, 상위 계층 스트림 프로세서를 활성화 하도록 stream processing 작업 공간 구성을 조정하는 것이 좋습니다.

    80% RAM 임계값을 초과하면 스트림 프로세서가 Worker out of memory 오류와 함께 실패합니다. sp.processor.stats() 명령을 사용하면 각 스트림 프로세서의 state.stateSize 값을 볼 수 있습니다. 자세한 내용을 알아보려면 스트림 프로세서의 통계 보기를 참조하세요.

  • Atlas Stream Processing 파이프라인 정의는 16 MB를 초과할 수 없습니다.

  • ,, Project OwnerProject Stream Processing Owner또는 Organization Stream Processing Admin Atlas admin 역할을 가진 사용자만 Atlas Stream Processing 사용할 수 있습니다.

  • 메서드를 사용하여 기존 스트림 프로세서에서 옵션을 재정의하려면 mongosh 23버전..4 mongosh 이상을 사용해야 합니다. 예시 들어 를 sp.processor.start() 사용하여 시작하려는 프로세서의 계층 지정합니다.

    를 사용하여 스트림 프로세서를 관리하는 mongosh 방법에 대해 자세히 학습 스트림 프로세서 개발을 참조하세요.

  • Atlas Stream Processing은 Atlas에서 사용할 수 있는 집계 파이프라인 단계의 하위 집합을 지원하므로, 저장 데이터에서 수행할 수 있는 것과 동일한 작업을 스트리밍 데이터에 대해 많이 수행할 수 있습니다. 지원되는 집계 파이프라인 단계의 전체 목록은 스트림 집계 문서를 참조하세요.

  • Atlas Stream Processing은 집계 변수 $$NOW, $$CLUSTER_TIME, $$USER_ROLES, $SEARCH_META를 지원하지 않습니다.

  • Atlas Stream Processing $emit 단계를 사용하여 AWS S3 버킷에 125 MB보다 큰 BSON 문서를 쓰는 것을 지원 하지 않습니다.

  • initialSync는 _id 값이 배열, 정규 표현식 또는 정의되지 않은 컬렉션( MongoDB _id 값으로 지원 하지 않는 컬렉션)을 지원 하지 않습니다.

  • If your collection's _id values are default generated ObjectId values or ordered int or long values, initialSync achieves optimal performance. For other _id types, initialSync might take longer to complete because the values aren't stored in a predictable order. If the resume token is no longer on the oplog when initialSync completes, the processor enters a failed state to prevent data loss. To recover, restart the processor with resumeFromCheckpoint=false, which causes initialSync to run again. To learn more, see Checkpoints.

  • Atlas Stream Processing은 initialSync이 복사하는 동안 파티션에 새 문서를 삽입할 수 있습니다. 확장 중인 파티션에서 쿼리를 방해하는 네트워크 장애는 컬렉션 복사 단계를 연장시킬 수 있습니다.

  • initialSync 컬렉션 복사 또는 따라잡기 단계에서 변경 이벤트 읽으면 중복 문서를 삽입할 수 있습니다. Atlas Stream Processing의 최소 한 번 처리 보장이 이러한 동작을 다룹니다. 컬렉션의 _id 값이 ObjectId 값이나 정렬된 int 또는 long 값이 아닌 경우 컬렉션-복사 단계가 더 오래 실행되고 더 많은 변경 이벤트에 걸쳐 있기 때문에 중복이 발생할 가능성이 더 높습니다.

  • Atlas Stream Processing은 다음 구성의 프로세서에 대해서만 페일오버 프로세서 를 지원합니다.

  • Atlas Stream Processing은 계층 이상의 프로세서에 대해서만 페일오버 프로세서를 SP10 지원합니다.

  • 페일오버 프로세서로 구성된 프로세서의 경우 한 프로세서만 언제든 시점에 활성화될 수 있습니다. 활성 프로세서만 편집할 수 있습니다.