FAQ
이 페이지의 내용
이 페이지에는 자주 묻는 질문(FAQ)과 해당 답변이 포함되어 있습니다.
팁
이 페이지에서 문제에 대한 답변 을 찾을 수 없는 경우 문제 및 도움말 페이지에서 다음 단계와 추가 리소스를 참조하세요.
MongoDB에 연결하는 동안 오류가 발생하는 이유는 무엇인가요?
MongoDB deployment에 연결하는 데 문제가 있는 경우 연결 문제 해결 가이드에서 가능한 해결 방법을 참조하세요.
.NET/C# 드라이버에서 연결 풀링은 어떻게 작동하나요?
모든 MongoClient
인스턴스에는 MongoDB 토폴로지의 각 서버에 대한 기본 제공 연결 풀이 있습니다. 연결 풀은 필요에 따라 소켓을 열어 멀티스레드 애플리케이션에서 동시 MongoDB 작업을 지원합니다.
각 연결 풀의 최대 크기는 MaxConnectionPoolSize
옵션으로 설정되며 기본값은 100
입니다. 서버에 대한 사용 중인 연결 수가 MaxConnectionPoolSize
값에 도달하면 해당 서버에 대한 다음 요청은 연결을 사용할 수 있을 때까지 대기합니다. 다음 다이어그램은 MongoClient
가 연결 풀을 관리하는 방법에 대한 높은 수준의 보기를 보여줍니다.
애플리케이션의 스레드를 지원하는 데 필요한 소켓 외에도 각 MongoClient
인스턴스는 MongoDB 토폴로지에서 서버당 두 개의 추가 소켓을 열어 서버 상태를 모니터링합니다. 예를 들어, 3노드 복제본 세트에 연결된 클라이언트는 6개의 모니터링 소켓을 엽니다. 애플리케이션이 MaxConnectionPoolSize
에 대한 기본 설정을 사용하고 프라이머리(기본) 노드만 쿼리하는 경우, 사용 중인 총 연결은 최대 106
개일 수 있습니다. 애플리케이션이 읽기 설정 을 사용하여 세컨더리 노드를 쿼리하는 경우 이러한 연결 풀이 커져 총 연결 수가 306
개가 될 수 있습니다.
한 프로세스 내에서 많은 수의 동시 MongoDB 스레드를 지원하려면 MaxConnectionPoolSize
를 늘리면 됩니다.
드라이버에는 연결을 기다릴 수 있는 스레드 수를 제한하는 대기열이 있습니다. 대기열의 크기는 WaitQueueMultiple
옵션에 의해 결정되며 기본값은 5
입니다. 드라이버는 최대 대기열 크기를 계산하기 위해 WaitQueueMultiple
에 MaxConnectionPoolSize
를 곱합니다. 각 옵션에 기본값을 사용하는 경우 대기열 크기는 500
입니다. 다른 설정을 재정의하는 WaitQueueSize
옵션을 지정하여 대기열 크기를 설정할 수도 있습니다. 그러나 대기열 크기를 기본값에서 변경하지 않는 것이 좋습니다.
연결 풀은 속도 제한이 있습니다. MaxConnecting
설정은 풀이 언제든지 병렬로 생성할 수 있는 연결 수를 결정합니다. 예를 들어 MaxConnecting
값이 2
인 경우 연결을 동시에 체크아웃하려고 시도하는 세 번째 스레드는 다음 중 하나의 경우에만 성공합니다.
처음 두 스레드 중 하나가 연결 만들기를 완료합니다.
기존 연결이 풀로 다시 확인됩니다.
연결 생성에 대한 속도 제한으로 인해 기존 연결을 재사용하는 드라이버의 기능이 향상됩니다.
MinConnectionPoolSize
옵션(기본값 0
)을 사용하여 각 서버에 대한 최소 동시 연결 수를 설정할 수 있습니다. 연결 풀은 이 수의 소켓으로 초기화됩니다. 오류로 인해 소켓이 닫히고 총 소켓 수(사용 중인 소켓과 유휴 상태 모두)가 최소값 아래로 떨어지면 드라이버는 해당 수가 최소값에 도달할 때까지 소켓을 추가로 엽니다.
MaxConnectionIdleTime
옵션을 사용하여 연결이 풀에서 유휴 상태로 유지될 수 있는 최대 시간(밀리초)을 설정할 수 있습니다. MaxConnectionIdleTime
에 대한 연결이 유휴 상태가 되면 드라이버가 연결을 제거합니다. 이 옵션의 기본값은 10분입니다. 풀 크기가 MinConnectionPoolSize
미만으로 떨어지면 드라이버가 유휴 연결을 제거하고 대체합니다.
MongoClient
에는 MaxConnectionLifeTime
옵션도 있습니다. 이 옵션은 만료되기 전에 연결을 풀링할 수 있는 시간(기본적으로 30분)을 지정합니다.
MongoClient
에 대한 다음 기본 구성은 대부분의 애플리케이션에서 작동합니다.
var client = new MongoClient("<connection string>");
각 프로세스에 대해 한 번씩 클라이언트를 생성하고 모든 작업에 재사용합니다. 각 요청에 대해 새 클라이언트를 생성하는 것은 흔한 실수이며 이는 매우 비효율적입니다.
드라이버에서 MongoClient
를 종료하기 위해 지원되는 방법은 없습니다.
서버 선택 중에 드라이버가 시간 초과를 발생시키는 이유는 무엇인가요?
각 운전자 작업을 수행하려면 서버 선택 기준을 충족하는 정상 서버 를 선택해야 합니다. 서버 선택 제한 시간 내에 적절한 서버 를 선택하지 않으면 운전자 에서 서버 선택 제한 시간 예외가 발생합니다. 예외는 다음과 유사합니다.
A timeout occurred after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 }, OperationsCountServerSelector }. Client view of cluster state is { ClusterId : "1", Type : "Unknown", State : "Disconnected", Servers : [{ ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/localhost:27017" }", EndPoint: "Unspecified/localhost:27017", ReasonChanged: "Heartbeat", State: "Disconnected", ServerVersion: , TopologyVersion: , Type: "Unknown", HeartbeatException: "<exception details>" }] }.
오류 메시지는 여러 부분으로 구성됩니다.
서버 선택 제한 시간(30000밀리초).
고려된 서버 선택기(
AreSessionsSupportedServerSelector
,LatencyLimitingServerSelector
,OperationsCountServerSelector
가 포함된CompositeServerSelector
).클러스터 토폴로지에 대한 드라이버의 현재 뷰. 드라이버가 인식하는 서버 목록은 이 뷰의 핵심 부분입니다. 각 서버 설명에는 엔드포인트, 서버 버전, 서버 유형, 현재 상태에 대한 정보를 비롯하여 현재 상태에 대한 전체 설명이 포함됩니다. 서버의 상태를 보고하는 데 문제가 발생하는 경우
HeartbeatException
에는 마지막으로 실패한 하트비트의 예외가 포함됩니다. 각 클러스터 노드에서HeartbeatException
을 분석하면 대부분의 서버 선택 문제를 진단하는 데 도움이 될 수 있습니다. 다음과 같은 하트비트 예외가 일반적입니다.No connection could be made because the target machine actively refused it
: 드라이버가 이 클러스터 노드를 볼 수 없습니다. 클러스터 노드가 충돌했거나, 방화벽으로 인해 네트워크 트래픽이 클러스터 노드 또는 포트에 도달하지 못하도록 차단되었거나, 기타 네트워크 오류로 인해 트래픽이 클러스터 노드로 라우팅되지 못하기 때문일 수 있습니다.Attempted to read past the end of the stream
: 이 오류는 네트워크 오류, 잘못 구성된 방화벽 또는 기타 네트워크 문제로 인해 드라이버가 클러스터 노드에 연결할 수 없을 때 발생합니다. 이 예외를 해결하려면 모든 클러스터 노드에 연결할 수 있는지 확인하세요. 이 오류는 일반적으로 클라이언트 머신의 IP 주소가 Atlas 프로젝트의 Network Access 탭 아래에 있는 Atlas IP 액세스 목록에 구성되어 있지 않을 때 발생합니다.The remote certificate is invalid according to the validation procedure
: 이 오류는 일반적으로 만료되었거나 유효하지 않은 인증서 또는 신뢰할 수 없는 루트 CA와 같은 TLS/SSL 관련 문제를 나타냅니다.openssl s_client
와 같은 도구를 사용하여 TLS/SSL 관련 인증서 문제를 디버깅할 수 있습니다.
문서를 쿼리할 때 LINQ 또는 빌더 클래스를 사용해야 하나요?
C#으로 프로그래밍하는 데 익숙하다면 기본 C#으로 프로그래밍하는 것과 비슷한 느낌을 주는 LINQ를 사용하는 것이 좋습니다. 다른 MongoDB 드라이버를 사용해 본 경험이 있다면 다른 드라이버와의 일관성을 위해 빌더 클래스를 사용하는 것이 좋습니다.
두 가지 접근 방식을 모두 실험해보고 목적에 가장 적합한 메커니즘을 결정하는 것이 좋습니다.
특정 LINQ 또는 빌더 표현식이 지원되지 않는 이유는 무엇인가요?
각 LINQ 또는 빌더 표현식은 Query API에서 사용할 수 있어야 합니다. 다음과 같은 이유로 항상 가능한 것은 아닙니다.
이에 해당하는 MongoDB 표현이 없는 .NET/C# 기능을 사용하려고 합니다. 예를 들어 .NET/C#과 MongoDB는 데이터 정렬과 관련하여 서로 다른 의미를 가집니다.
드라이버는 LINQ 또는 빌더 표현식에서 MQL(MongoDB 쿼리 언어)로의 특정 변환을 지원하지 않습니다. 이는 제공된 쿼리에 MQL 변환이 없거나 드라이버에 기능이 아직 구현되지 않았기 때문에 발생할 수 있습니다.
Unsupported filter ...
또는 Expression not
supported ...
예외 메시지가 표시되면 다음 단계를 시도해 보세요.
MongoDB C# 분석기 를 사용하여 표현식을 분석합니다.
가능하면 쿼리를 단순화합니다.
쿼리를
BsonDocument
또는 JSON 문자열로 제공합니다.FilterDefinition
,ProjectionDefinition
,PipelineDefinition
과 같은 모든 드라이버 정의 클래스는BsonDocument
또는 JSON 문자열로부터의 암시적 변환을 지원합니다. 예를 들어 다음 필터는 쿼리 또는 집계에 사용될 때 동일합니다.
FilterDefinition<Entity> typedFilter = Builders<Entity>.Filter.Eq(e => e.A, 1); FilterDefinition<Entity> bsonFilter = new BsonDocument {{ "a", 1 }}; FilterDefinition<Entity> jsonFilter = "{ a : 1 }";
참고
또는 을 사용하는 BsonDocument
JSON string 경우 BsonClassMap, BSON 직렬화 속성 및 직렬화 규칙은 Query API 에서 고려되지 않습니다. 필드 이름은 서버에 저장된 이름 및 대소문자와 일치해야 합니다. 예를 들어, _id
필드를 참조하는 경우 BsonDocument
또는 JSON string 정의에서 _id
를 사용하여 참조해야 합니다. 마찬가지로, 문서에 [BsonElement("first_name")]
로 주석이 달린 FirstName
필드가 있는 경우 BsonDocument
또는 JSON string 정의에서 이를 first_name
로 참조해야 합니다.
다음 코드에서 보여 주는 것처럼 동일한 쿼리에 원시 양식과 유형 지정된 양식을 결합할 수 있습니다.
FilterDefinition<Entity> filter = Builders<Entity>.Filter .And(Builders<Entity>.Filter .Eq(e => e.A, 1), BsonDocument .Parse("{ b : 2 }"));
직렬화할 수 있는 객체 유형은 무엇인가요?
ObjectSerializer
는 안전하다고 간주되는 유형의 직렬화 및 역직렬화만 허용합니다. ObjectSerializer
를 구성할 때 Func<Type, bool>
유형의 위임을 전달할 수 있습니다. 이 위임은 객체 유형을 수락하고 해당 형식이 직렬화에 안전한지 여부를 나타내는 부울 값을 반환합니다.
대부분의 경우 ObjectSerializer.DefaultAllowedTypes()
위임을 전달해야 합니다. 이 메서드는 안전하다고 판단한 잘 알려진 여러 프레임워크 유형에 대해 true를 반환합니다. 사용자 지정 유형을 직렬화하려면 포함하려는 유형에 대해 true
로 평가하는 부울 표현식을 만듭니다. 그런 다음 ObjectSerializer
생성자에 전달하는 위임의 끝에 이 표현식을 추가합니다.
다음 예에서는 ObjectSerializer
가 ObjectSerializer.DefaultAllowedTypes()
에서 허용되거나 전체 이름이 "MyNamespace"
로 시작하는 모든 유형을 직렬화 및 역직렬화합니다.
var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type) || type.FullName.StartsWith("MyNamespace")); BsonSerializer.RegisterSerializer(objectSerializer);
익명 유형을 직렬화하도록 허용하려면 다음 예와 같이 부울 표현식 type.FullName.StartsWith("<>f__AnonymousType"))
을 위임에 추가합니다.
var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type) || type.FullName.StartsWith("<>f__AnonymousType")); BsonSerializer.RegisterSerializer(objectSerializer);
다른 작업을 수행하기 전에 프로그램 시작 시 ObjectSerializer
를 만들고 등록해야 합니다.
.NET/ C# 드라이버 와 MongoDB 엔티티 프레임워크 코어 제공자의 차이점은 무엇인가요?
.NET/ C# 드라이버 는 MongoDB 기능을 직접 노출하는 라이브러리이며 프로젝션, 그룹 작업 및 유연한 매핑을 제공하는 LINQ 제공자 를 포함합니다. 운전자 에는 다음과 같은 기능이 포함되어 있습니다.
트랜잭션
대량 작업
LINQ 쿼리
데이터베이스 를 직접 수정하는 작업
집계 작업
사용자 지정 매핑
Entity Framework Core Provider 를 사용하면 .NET/ C# 애플리케이션에서 Microsoft의 Entity Framework Core를 MongoDB 와 함께 사용할 수 있습니다. Entity Framework Core Provider는 변경 추적, 엔터티 기반 LINQ 작업 및 Entity Framework Core 사용자에게 친숙한 모델링을 지원합니다. 제공자 에는 다음과 같은 기능이 포함되어 있습니다.
지능형 객체 추적
엔터티 기반 LINQ 작업
Fluent API 를 사용한 Entity Framework 모델링 및 매핑
변경 사항 추적을 통한 자동 데이터베이스 업데이트