이 섹션에서는 mongot 배포서버 대한 중요한 계획 관련 질문에 답변하고 검색 아키텍처를 설계하기 위한 실행 가능한 단계를 제공합니다. 포괄적인 개요를 보려면 이 섹션을 선형적으로 읽으세요. 또는 이 섹션을 참조로 사용하고 필요에 따라 관련 섹션으로 건너뛸 수 있습니다. 이 섹션의 목표는 리소스 요구 사항을 정확하게 추정하고 강력한 배포서버 빌드 도움이 되는 것입니다.
데이터 특성 및 인덱스
데이터의 구조와 인덱스 정의는 디스크 사용량 과 RAM 요구 사항의 프라이머리 동인입니다. 이 섹션을 사용하여 인덱스를 효율적으로 관리 데 필요한 최종 인덱스 크기와 메모리를 추정합니다.
기준 인덱스 크기 계산
디스크 공간 추정을 위한 점 으로 다음 공식을 사용합니다.
Estimated Index Size = (Number of Documents) x (Avg. Size of Indexed Text per Doc) x (Expansion Factor)
확장 계수 는 매우 중요하며 토큰화 전략에 따라 크게 달라집니다. 다음 승수를 가이드 로 사용하세요.
사용 사례 | 승수 |
|---|---|
표준/언어 토큰화 |
|
키워드/단순 토큰화 |
|
edgeGram (자동 완성) |
|
nGram(부분 일치) |
|
참고
위의 확장 계수 승수는 일반화된 예시 나타내며 모든 텍스트 기반 콘텐츠에 적용 않을 수 있습니다. 자체 데이터로 테스트하여 배포서버 대한 인덱스 계산을 결정해야 합니다.
메모리 사용량을 관리하여 불안정성 방지
- 정적 매핑 사용
- 문서 구조를 예측할 수 없는 경우 동적 매핑을 비활성화합니다. 동적 매핑은 의도하지 않은 수천 개의 필드가 생성되어 과도한 RAM 소비하고 불안정을 유발하는 "매핑 폭발"로 이어질 수 있습니다.
dynamic: false를 사용하여 인덱스 명시적으로 정의합니다. 자세히 학습 정적 및 동적 매핑을 참조하세요. - 저장된 소스 필드 제한
- 검색 결과에 필요한 최소한의 필드 설정하다 만
mongot인덱스 자체 내에 저장 . 프라이머리 MongoDB 컬렉션 에서 필드를 가져오는 것이 더 효율적이고 인덱스 에서 사용하는 디스크 공간을 줄이는 경우가 많습니다. 자세한 학습 은 MongoDB 검색 인덱스에 저장된 소스 필드 정의를 참조하세요. - 대용량 메모리 기능 고려
- 동의어 컬렉션 과 깊게 중첩된 embeddedDocuments 는 상당한 메모리 아티팩트를 생성한다는 점에 유의하세요. 이러한 기능을 많이 사용하는 경우
mongot프로세스 에 더 많은 Java 힙 공간을 할당해야 합니다.
인덱싱 워크로드
쓰기(삽입, 업데이트, 삭제)의 속도와 유형에 따라 검색 인덱스 데이터베이스 와 동기화된 상태로 유지하는 데 필요한 CPU 및 디스크 IOPS 가 결정됩니다.
쓰기 (write) 처리량 및 유지 관리를 위해 프로비저닝하려면 다음을 수행합니다.
복제 지연 최소화
- 인덱스 통합
- 단일 컬렉션 에 여러 개의 별도 검색 인덱스를 정의하지 마세요. 각 인덱스 오버헤드 추가합니다. 대신 포괄적인 단일 인덱스 정의를 만듭니다.
- 복합 뷰 구체화
- 복잡한 뷰를 인덱싱 하는 경우 변경 스트림 성능에 제약이 있을 수 있습니다. 에 대한 간단한 사전 집계 데이터 소스 인덱스 할 수 있도록 구체화된 뷰를 생성하는
mongot것이 좋습니다.
쿼리 워크로드
쿼리 성능은 주로 처리 위한 CPU와 캐싱을 위한 RAM 의 함수입니다. 쿼리의 복잡성과 볼륨에 따라 지연 시간 목표를 충족하는 데 필요한 리소스가 결정됩니다.
쿼리 성능에 필요한 배포서버 크기를 추정하려면 다음을 수행합니다.
짧은 지연 시간 위한 RAM 할당
RAM 빠른 쿼리에서 가장 중요한 요소입니다.
- 전문 검색
- 목표는 운영 체제의 파일 시스템 캐시 에 가능한 한 많은 인덱스 맞추는 것입니다. 최적의 성능을 위해 디스크에 있는 인덱스 의 총 크기와 일치하도록
mongot노드 에 충분한 RAM 프로비저닝합니다. 이렇게 하면 느린 디스크 읽기가 최소화됩니다. - Vector Search
- 지연 시간이 짧은 벡터 검색 의 경우 HNSW 그래프 인덱스 메모리에 존재해야 합니다. 필요한 최소 RAM 계산하려면 인덱스 크기 추정 절차 의 단계를 사용하여 오버헤드를 위한 20~25%의 버퍼를 추가합니다. 벡터 인덱스 RAM 에 맞지 않으면 쿼리 지연 시간 늘어납니다.
참고
RAM 요구 사항을 줄이려면 벡터 양자화를 사용하는 것이 좋습니다. 벡터 양자화는 벡터 임베딩을 압축할 수 있으며, 이는 리콜이나 정밀도에 영향 최소화하면서 메모리 사용량(및 이를 저장하는 데 필요한 RAM )을 종종 낮춥니다.