이 페이지에서는 Kubernetes 클러스터에서 MongoDB Search 및 벡터 검색을 제공하는 mongot 팝의 크기를 저정하는 방법을 설명합니다. 이를 사용하여 MongoDBSearch 리소스에서 spec.clusters[].resourceRequirements, spec.clusters[].jvmFlags 및 spec.clusters[].persistence 의 초기 값을 선택하고 인덱스 증가를 위한 영구 볼륨 용량을 계획합니다.
mongot의 크기를 조정하기 전에 실행할 계획인 배포서버 모델과 토폴로지를 검토합니다.
MongoDB Search 배포서버 모델에 대한 자세한 내용은 MongoDB Search 아키텍처를 참조하십시오.
벡터 검색 배포서버 모델에 대해서는 MongoDB Vector Search Architecture를 참조하세요.
이 페이지에서 참조되는 각 설정의 전체 스키마는 MongoDB Search 및 벡터 검색 설정을 참조하십시오.
리소스 크기 조정
워크로드 클래스 선택
할당하는 CPU 대 메모리 비율은 검색 워크로드 프로필에 따라 달라집니다.
워크로드 클래스 | RAM대 CPU 비율 | 다음 경우 사용: |
|---|---|---|
높은 CPU | 2:1 | 쿼리 성능이 CPU 집중적인 경우 일반 목적 전문 검색을 실행합니다. |
낮은 CPU | 8:1 | 메모리가 원시 CPU보다 더 중요한 데이터 볼륨이 낮은 경우 벡터 검색 워크로드를 실행합니다. |
대부분의 일반적인 사용 사례에서는 작은 거나 중간 고성능 CPU 구성이 균형 있는 시작 점입니다.
시작 크기 선택
예상 되는 벡터 데이터 볼륨(저사양 CPU) 또는 초당 쿼리 수(고사양 CPU)로 mongot 팝의 크기를 조정합니다.
size | 저사용 CPU(벡터 검색) | 고성능 CPU(전문) |
|---|---|---|
소형 | 최대 10 GB의 벡터 | 20 에서 40 QPS, 간단한 인덱싱 |
중간 | 10 GB에서 50 GB까지의 벡터 | 80 에서 160 까지 QPS |
대형 | 50 GB 이상의 벡터 | 320 부터 480 QPS, 중량 인덱싱 |
예시들어 전체 텍스트 검색 애플리케이션에 대해 초당 100 쿼리를 처리할 예정인 경우 중간 고성능 CPU 구성으로 시작합니다.
CPU 및 메모리 구성
spec.clusters[].resourceRequirements에서 mongot 팝의 CPU 및 메모리를 설정합니다. requests 필드는 노드의 용량을 예약하고 limits 필드는 팝이 소비할 수 있는 최대 양을 제한합니다.
spec: clusters: - resourceRequirements: requests: cpu: "2" memory: 4Gi limits: cpu: "3" memory: 5Gi
spec.clusters[].resourceRequirements을 생략하면 Kubernetes Operator는 다음 기본값을 사용합니다.
requests.cpu:2requests.memory:4Gilimits이 없으면 팟은 노드의 사용 가능한 모든 리소스를 사용할 수 있습니다.
워크로드에 맞게 limits 을 설정합니다. 제한이 없는 팟은 노드를 포화시켜 다른 워크로드에 영향을 줄 수 있습니다.
JVM Heap 구성
spec.clusters[].jvmFlags에서 -Xms 또는 -Xmx 을 지정하지 않은 경우 Kubernetes 연산자는 두 플래그를 spec.clusters[].resourceRequirements.requests.memory의 절반으로 설정하여 JVM 힙을 자동으로 계산합니다.
힙을 명시적으로 재정의하려면 spec.clusters[].jvmFlags에 -Xms 과 -Xmx 을 설정합니다. Kubernetes Operator는 제공하는 플래그를 수정하지 않으며 연산자 계산 플래그 뒤에 추가합니다.
spec: clusters: - jvmFlags: - -Xms2g - -Xmx2g
영구 볼륨 크기 조정
각 mongot 팝에는 검색 및 벡터 인덱스를 유지하는 고유한 영구 볼륨이 있습니다. 인덱스와 재구축을 위한 여유 공간을 유지핕 볼륨을 계획합니다.
인덱스 크기 추정
컬렉션 크기와 그에 따른 검색 인덱스 크기가 항상 상관관계를 가지는 것은 아닙니다. 인덱스 크기는 매핑하는 필드와 인덱스에서 활성화하는 기능(예: 자동 완성) 에 따라 달라집니다. 워크로드의 인덱스 크기를 추정하려면 다음과 같이 합니다.
대표 샘플을 삽입합니다.
1 ~ 2 GB의 데이터를 삽입하거나 $out를 사용하여 작은 컬렉션을 만듭니다.
배포될 영구 볼륨 크기 조정
인덱스에 필요한 디스크 공간의 double을 할당합니다. 예비 공간을 활용하여 mongot 는 필요할 때 인덱스를 다시 만들 수 있습니다. 디스크 사용량이 90%에 도달하면 mongot 은 읽기 전용이 됩니다.
이진 수량 접미사를 사용하여 spec.clusters[].persistence.single.storage 에서 볼륨 크기를 설정합니다.
spec: clusters: - persistence: single: storage: 60Gi storageClass: local-nvme
spec.clusters[].persistence를 생략하면 Kubernetes Operator는 16 GB의 기본 볼륨을 프로비저닝합니다. 30 GB 인덱스의 경우 인덱스 재구축을 위한 공간을 남겨두려면 spec.clusters[].persistence.single.storage 을 60Gi 로 설정합니다.
저장 클래스 선택
spec.clusters[].persistence.single.storageClass의 볼륨에 대한 StorageClass 을 참조합니다. 다음 지침을 충족하는 클래스를 선택합니다.
디스크 유형: 일반용 SSD 기반 저장장치를 사용합니다. 읽기 및 쓰기 IOPS 모두
mongot성능에 중요합니다. 복제는 새 인덱스 세그먼트에 대한 디스크 쓰기를 포함합니다. 그리고mongot이 오래된 세그먼트를 더 큰 세그먼트로 병합할 때 디스크를 읽습니다.읽기 전용 임계값: 볼륨 사용량이 90%에 도달하면
mongot은 읽기 전용 모드로 전환되고 쓰기 (write) 작업이 중지됩니다. 쓰기 (write) 작업을 다시 시작하려면 인덱스 데이터를 삭제하여 사용량을 85%미만으로 낮추세요.
리소스 사용량 모니터
배포 후 다음 같은 임계값을 모니터하여 초기 사이징이 적절한지 확인하고 확장해야 할 시기를 알아봅니다.
Resource | 임계값 | 작업 |
|---|---|---|
중앙처리장치 | 80% 이상 사용량 유지 |
|
메모리 |
|
|
Disk | 90% 이상 사용 | 인덱스 크기를 줄여 사용량을 임계값 아래로 낮추십시오. |