Atlas Search 인덱스 성능

인덱스 크기 및 구성

Atlas Search 인덱스를 생성할 때 필드 매핑은 기본적으로 동적으로 설정되며, 컬렉션에서 동적으로 인덱싱할 수 있는 모든 데이터 유형이 인덱싱됩니다. 강조 표시 활성화와 같은 다른 옵션을 사용하면 인덱스가 더 많은 디스크 공간을 차지할 수도 있습니다. 다음과 같은 방법으로 Atlas Search 인덱스의 크기와 성능 공간을 줄일 수 있습니다:

• 사용자 지정 인덱스 정의 를 통해 인덱싱되는 데이터의 양과 유형을 제한합니다.

• 인덱스 정의에서 문자열 유형을 지정할 때 store 옵션을 false 로 설정합니다.

{
  "_id": 0,
  "name": "Springfield High",
  "mascot": "Pumas",
  "teachers": [
    {
      "first": "Jane",
      "last": "Smith",
      "classes": [
        {
          "subject": "art of science",
          "grade": "12th"
        },
        ... // 2 more embedded documents
      ]
    },
    ... // 1 more embedded document
  ],
  "clubs": {
    "stem": [
      {
        "club_name": "chess",
        "description": "provides students opportunity to play the board game of chess informally and competitively in tournaments."
      },
      ... // 1 more embedded document
    ],
    ... // 1 more embedded document
  }
}

Atlas Search 인덱스 생성 및 업데이트

Atlas Search 인덱스를 만드는 데는 많은 리소스가 필요합니다. 인덱스가 빌드되는 동안 Atlas 클러스터의 성능이 영향을 받을 수 있습니다.

Atlas는 컬렉션의 모든 쓰기를 복제합니다. 즉, Atlas Search 인덱스가 있는 각 컬렉션에 대해 해당 컬렉션에 정의된 Atlas Search 인덱스의 양만큼 쓰기가 증폭됩니다.

경우에 따라 Atlas Search 인덱스를 다시 작성해야 하는 경우도 있습니다. Atlas Search 인덱스를 재구축하는 것도 리소스를 소비하며 데이터베이스 성능에 영향을 미칠 수 있습니다. Atlas Search는 다음과 같은 경우에만 인덱스를 자동으로 다시 작성합니다:

• 인덱스 정의 변경

• 호환성이 손상되는 변경이 포함된 Atlas Search 버전 업데이트

• 인덱스 손상과 같은 하드웨어 관련 문제

궁극적 일관성 및 인덱싱 지연 시간

Atlas Search는 궁극적 일관성을 지원하지만 더 강력한 일관성을 보장하지는 않습니다. 이는 MongoDB 컬렉션에 삽입되고 Atlas Search에 의해 인덱싱된 데이터를 $search 쿼리에 즉시 사용할 수 없음을 의미합니다.

Atlas Search는 MongoDB 변경 스트림에서 데이터를 읽고 비동기 프로세스에서 해당 데이터를 인덱스합니다. 이 프로세스는 일반적으로 매우 빠르지만 복제 지연 시간, 시스템 리소스 가용성, 인덱스 정의의 복잡성에 의해 영향을 받을 수 있습니다. Atlas Search 인덱스가 많으면 Atlas Search 인덱스의 복제 지연 및 지연 시간 발생의 원인이 될 수 있습니다.

문서 매핑 폭발

Atlas Search가 임의의 키로 문서를 인덱싱하고 동적 매핑을 사용할 때 매핑 폭발이 발생할 수 있습니다. mongot 프로세스는 메모리를 점점 더 많이 소모하게 되어 충돌할 수 있습니다. 인덱스에 너무 많은 필드를 추가하면 매핑 폭발이 발생할 수 있습니다. 이 문제를 해결하려면 클러스터를 업그레이드하거나 데이터의 모든 필드를 인덱싱하지 않는 정적 매핑 을 사용할 수 있습니다.

와일드카드 경로를 사용하여 필드를 검색할 때는 튜플과 유사한 스키마를 사용하도록 검색을 설계하세요. 키-값 스키마를 사용하는 와일드카드 경로 검색을 수행하는 경우 Atlas Search는 각 키를 자체 필드로 인덱스하므로 매핑이 폭발적으로 증가할 수 있습니다.

ruleBuilder: {
  ruleName1: <data>,
  ruleName2: <data>,
  .....
  ruleName1025: <data>
}

{
  ruleBuilder: [
    {name: ruleName1, data: <data>},
    {name: ruleName2, data: <data>},
    ...
    {name: ruleName1025, data: <data>}
  ]
}

소스 필드 저장

$sort, $match, $group, $skip과 같은 후속 집계 파이프라인 단계의 성능을 개선하고 Atlas Search에 저장할 필드를 구성할 수 있습니다. 원본 문서와 일치하는 데이터 세트가 너무 커서 전체 데이터 조회가 비효율적인 경우 이 최적화를 사용합니다. Atlas Search에 특정 필드를 저장하고 저장된 필드만 반환하는 방법에 대해 자세히 알아보려면 Atlas Search 인덱스에서 저장된 소스 필드 정의 및 저장된 소스 필드 반환을 참조하세요.

후속 단계에 필요한 최소한의 필드만 저장하는 것이 좋습니다. 필요한 경우, 파이프라인 단계의 마지막에 $lookup를 사용하여 예시와 같이 전체 문서를 검색할 수 있습니다. 불필요한 필드를 저장하면 디스크 사용률이 증가하고 인덱싱 및 쿼리 중 성능에 부정적인 영향을 줄 수 있습니다.

Atlas Search 업그레이드

Atlas Search는 Atlas 클러스터에 배포됩니다. 새 버전의 Atlas Search를 배포할 때, Atlas 클러스터는 쿼리 결과를 반환하는 과정에서 잠시 네트워크 오류를 경험할 수 있습니다. 배포 중 문제를 완화하고 애플리케이션에 미치는 영향을 최소화하기 위해 다음 사항들을 고려하세요:

• 애플리케이션에 재시도 로직을 구현하세요.

• Atlas 유지 관리 기간을 구성합니다.

  참고

  Atlas Search 업그레이드는 유지 관리 기간 중에만 시작되며 유지 관리 기간 이후에도 계속될 수 있습니다.

각 릴리스의 변경 사항에 대해 자세히 알아보려면 Atlas Search 변경 로그(Changelog)를 참조하세요.

인덱싱 성능 확장

Atlas Search 인덱스의 초기 동기화 및 정상 상태 인덱싱을 확장하기 위해 cluster를 더 많은 코어를 가진 상위 티어로 업그레이드할 수 있습니다. Atlas Search는 초기 동기화 및 정상 상태 인덱싱을 실행하기 위해 사용 가능한 모든 코어의 일정 비율을 사용합니다. cluster를 업그레이드하여 새로운 코어를 사용할 수 있게 되면 성능이 향상됩니다.

Atlas 클러스터 구성 변경

로컬 NVMe 스토리지 유형을 사용하도록 배포를 재구성하거나 NVMe 기반 클러스터를 업스케일링하는 경우, 각 노드가 기본 구성 또는 업스케일 작업을 완료한 후 Atlas Search는 구성된 모든 Atlas Search 인덱스의 초기 동기화를 수행합니다. Atlas Search 인덱스 초기 동기화가 클러스터 구성 변경을 완료하는 데 걸린 시간보다 오래 걸리는 경우 Atlas 클러스터의 모든 노드에서 초기 동기화가 완료될 때까지 $search 쿼리를 실행할 수 없습니다.

Atlas 클러스터와 $search 워크로드를 독립적으로 확장하려면 전용 검색 노드를 배포하는 것이 좋습니다. 전용 검색 노드는 mongot 프로세스만 실행하며 mongot 프로세스의 가용성과 워크로드 밸런싱을 개선합니다.