기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 기능적 차이: Amazon DocumentDB 및 MongoDB 다음은 Amazon DocumentDB(MongoDB 호환)과 MongoDB 간의 기능적 차이입니다. **Topics** + [Amazon DocumentDB의 기능적 이점](#functional-differences.functional-benefits) + [업데이트된 기능적 차이](#functional-differences.updated-functional-differences) + [MongoDB와 기능적 차이](#functional-differences.with-mongodb) ## Amazon DocumentDB의 기능적 이점 ### 암시적 트랜잭션 Amazon DocumentDB에서 모든 CRUD 문(`findAndModify`, `update`, `insert`, `delete`)은 여러 문서를 수정하는 작업의 경우에도 원자성과 일관성을 보장합니다. Amazon DocumentDB 4.0이 출시되면서, 이제 다중 명령문 및 다중 컬렉션 작업에 대한 ACID 속성을 제공하는 명시적 트랜잭션이 지원됩니다. Amazon DocumentDB에서의 트랜잭션 사용에 대한 자세한 내용은 [Amazon DocumentDB의 트랜잭션](transactions.md)을 참조하세요. 다음은 Amazon DocumentDB에서 원자성 동작과 일관성 동작을 모두 충족하는 여러 문서를 수정하는 작업의 예입니다. ``` db.miles.update( { "credit_card": { $eq: true } }, { $mul: { "flight_miles.$[]": NumberInt(2) } }, { multi: true } ) ``` ``` db.miles.updateMany( { "credit_card": { $eq: true } }, { $mul: { "flight_miles.$[]": NumberInt(2) } } ) ``` ``` db.runCommand({ update: "miles", updates: [ { q: { "credit_card": { $eq: true } }, u: { $mul: { "flight_miles.$[]": NumberInt(2) } }, multi: true } ] }) ``` ``` db.products.deleteMany({ "cost": { $gt: 30.00 } }) ``` ``` db.runCommand({ delete: "products", deletes: [{ q: { "cost": { $gt: 30.00 } }, limit: 0 }] }) ``` `updateMany` 및 `deleteMany`와 같은 대량 작업을 구성하는 개별 작업은 원자성이지만 전체 대량 작업은 원자성이 아닙니다. 예를 들어, 개별 삽입 작업이 오류 없이 성공적으로 실행되면 전체 `insertMany` 작업이 원자성입니다. `insertMany` 작업에 오류가 발생하면 `insertMany` 작업 내의 각 개별 삽입 명령문이 원자성 작업으로 실행됩니다. `insertMany`, `updateMany` 및 `deleteMany` 작업에 대한 ACID 속성이 필요한 경우 트랜잭션을 사용하는 것이 좋습니다. ## 업데이트된 기능적 차이 Amazon DocumentDB에서는 고객이 빌드하도록 요청한 기능에서 거꾸로 작업함으로써 MongoDB와의 호환성을 지속적으로 개선하고 있습니다. 이 섹션에는 고객이 더 쉽게 마이그레이션하고 애플리케이션을 빌드할 수 있도록 Amazon DocumentDB에서 제거한 기능적 차이가 포함되어 있습니다. **Topics** + [배열 인덱싱](#functional-differences.array-indexing) + [다중 키 인덱스](#functional-differences.multi-key-indexes) + [문자열의 null 문자](#functional-differences.strings) + [역할 기반 액세스 제어](#functional-differences.role_based_access_control) + [`$regex` 인덱싱](#functional-differences.regex-indexing) + [중첩된 문서에 대한 프로젝션](#functional-differences.nested-docs) ### 배열 인덱싱 2020년 4월 23일 현재 Amazon DocumentDB에서는 2,048바이트보다 큰 배열을 인덱싱하는 기능을 지원합니다. 배열의 개별 키에 대한 제한은 여전히 MongoDB와 일치하는 2,048바이트로 유지됩니다. 새 인덱스를 생성하는 경우, 향상된 기능을 활용하기 위해 아무런 작업도 필요하지 않습니다. 기존 인덱스가 있는 경우, 인덱스를 삭제한 다음, 다시 생성하여 향상된 기능을 활용할 수 있습니다. 향상된 기능을 갖춘 현재 인덱스 버전은 `"v" : 3`입니다. **참고** 프로덕션 클러스터의 경우 인덱스를 삭제하면 애플리케이션 성능에 영향을 줄 수 있습니다. 프로덕션 시스템을 변경할 때는 먼저 테스트하고 주의해서 진행하는 것이 좋습니다. 또한 인덱스를 다시 생성하는 데 걸리는 시간은 컬렉션의 전체 데이터 크기의 함수입니다. 다음 명령을 사용하여 인덱스의 버전을 쿼리할 수 있습니다. ``` db.collection.getIndexes() ``` 이 작업의 출력은 다음과 같이 표시됩니다. 이 출력에서 인덱스의 버전은 가장 최신 인덱스 버전인 `"v" : 3`입니다, ``` [ { "v" : 3, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "test.test" } ] ``` ### 다중 키 인덱스 2020년 4월 23일 현재 Amazon DocumentDB에서는 동일한 배열에 여러 키가 있는 복합 인덱스를 만드는 기능을 지원합니다. 새 인덱스를 생성하는 경우, 향상된 기능을 활용하기 위해 아무런 작업도 필요하지 않습니다. 기존 인덱스가 있는 경우, 인덱스를 삭제한 다음, 다시 생성하여 향상된 기능을 활용할 수 있습니다. 향상된 기능을 갖춘 현재 인덱스 버전은 `"v" : 3`입니다. **참고** 프로덕션 클러스터의 경우 인덱스를 삭제하면 애플리케이션 성능에 영향을 줄 수 있습니다. 프로덕션 시스템을 변경할 때는 먼저 테스트하고 주의해서 진행하는 것이 좋습니다. 또한 인덱스를 다시 생성하는 데 걸리는 시간은 컬렉션의 전체 데이터 크기의 함수입니다. 다음 명령을 사용하여 인덱스의 버전을 쿼리할 수 있습니다. ``` db.collection.getIndexes() ``` 이 작업의 출력은 다음과 같이 표시됩니다. 이 출력에서 인덱스의 버전은 가장 최신 인덱스 버전인 `"v" : 3`입니다, ``` [ { "v" : 3, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "test.test" } ] ``` ### 문자열의 null 문자 2020년 6월 22일부터 Amazon DocumentDB는 문자열에서 null 문자(`'\0'`)를 지원합니다. ### 역할 기반 액세스 제어 2020년 3월 26일부터 Amazon DocumentDB는 기본 제공 역할에 대한 RBAC(역할 기반 액세스 제어)를 지원합니다. 자세한 내용은 [역할 기반 액세스 제어](role_based_access_control.md)을 참조하세요. ### `$regex` 인덱싱 2020년 6월 22일부터 Amazon DocumentDB는 `$regex` 연산자가 인덱스를 활용하는 기능을 지원합니다. `$regex` 연산자와 함께 인덱스를 활용하려면 `hint()` 명령을 사용해야 합니다. `hint()`를 사용할 때 `$regex`를 적용할 필드의 이름을 지정해야 합니다. 예를 들어 `product` 필드에 인덱스 이름이 `p_1`인 인덱스가 있으면 `db.foo.find({product: /^x.*/}).hint({product:1})`은 `p_1` 인덱스를 사용하지만 `db.foo.find({product: /^x.*/}).hint(“p_1”)`은 인덱스를 사용하지 않습니다. `explain()` 명령을 사용하거나 느린 쿼리를 로깅하는 프로파일러를 사용하여 인덱스가 선택되었는지 확인할 수 있습니다. 예를 들어 `db.foo.find({product: /^x.*/}).hint(“p_1”).explain()`입니다. **참고** `hint()` 메서드는 한 번에 하나의 인덱스에만 사용할 수 있습니다. `$regex` 쿼리에 대한 인덱스 사용은 접두사를 사용하고 `i`, `m` 또는 정규식 옵션을 지정하지 않는 `o` 정규식 쿼리에 최적화됩니다. `$regex`와 함께 인덱스를 사용하는 경우 중복 값 수가 컬렉션에 있는 총 문서 수의 1% 미만인 매우 선택적인 필드에 인덱스를 생성하는 것이 좋습니다. 예를 들어 컬렉션에 100,000개의 문서가 포함되어 있는 경우, 동일한 값이 1000회 이하로 나타나는 필드에만 인덱스를 생성하세요. ### 중첩된 문서에 대한 프로젝션 버전 3.6의 Amazon DocumentDB와 MongoDB 간에는 `$project` 연산자와의 기능적 차이가 있습니다. 이 차이는 Amazon DocumentDB 4.0에서는 해결되었지만 Amazon DocumentDB 3.6에서는 지원되지 않습니다. Amazon DocumentDB 3.6은 프로젝션을 적용할 때 중첩 문서의 첫 번째 필드만 고려하는 반면, MongoDB 3.6은 하위 문서를 구문 분석하여 각 하위 문서에도 프로젝션을 적용합니다. 예를 들어, 프로젝션이 `“a.b.c”: 1`이면, Amazon DocumentDB와 MongoDB 모두에서 동작이 예상대로 작동합니다. 그러나 프로젝션이 `{a:{b:{c:1}}}`이면, Amazon DocumentDB 3.6은 프로젝션을 `a`에만 적용하고 `b` 또는 `c`에는 적용하지 않습니다. Amazon DocumentDB 4.0에서는 프로젝션 `{a:{b:{c:1}}}`, `a`, `b`, 및 `c`에 적용됩니다. ## MongoDB와 기능적 차이 **Topics** + [`$vectorSearch` 연산자](#functional-differences.vector-search) + [`OpCountersCommand`](#functional-differences.op-counter) + [관리자 데이터베이스 및 컬렉션](#functional-differences.admin-databases) + [`cursormaxTimeMS`](#functional-differences.cursormaxTimeMS) + [explain()](#functional-differences.explain) + [인덱스 빌드](#functional-differences.background-indexes) + [경로에 빈 키를 사용하여 조회](#functional-differences.lookup-empty) + [MongoDB API, 작업 및 데이터 형식](#functional-differences.mongo-apis) + [`mongodump`및 `mongorestore` 유틸리티](#functional-differences.mongodump-mongorestore) + [결과 주문](#functional-differences.result-ordering) + [재시도 가능한 쓰기](#functional-differences.retryable-writes) + [희소 인덱스](#functional-differences.sparse-index) + [`$all` 표현식 내에서 `$elemMatch` 사용](#functional-differences.elemMatch) + [필드 이름의 달러(\$1) 및 점(.)](#functional-differences-dollardot) + [`$lookup`](#functional-differences.lookup) + [`$natural` 및 역 정렬](#functional-differences.natural) ### `$vectorSearch` 연산자 Amazon DocumentDB는 독립 연산자로 `$vectorSearch` 항목을 지원하지 않습니다. 대신 `$search` 연산자 내에서 `vectorSearch` 항목을 지원합니다. 자세한 내용은 [Amazon DocumentDB에 대한 벡터 검색](vector-search.md) 단원을 참조하십시오. ### `OpCountersCommand` Amazon DocumentDB의 `OpCountersCommand` 동작은 다음과 같이 MongoDB의 `opcounters.command`에서 벗어납니다. + MongoDB `opcounters.command` 개수는 삽입, 업데이트 및 삭제를 제외한 모든 명령을 계산하는 반면, Amazon DocumentDB의 `OpCountersCommand`는 해당 `find` 명령도 제외합니다. + Amazon DocumentDB는 내부 명령을 `OpCountersCommand`로 계산합니다. ### 관리자 데이터베이스 및 컬렉션 Amazon DocumentDB는 각각 관리자 또는 로컬 데이터베이스, MongoDB `system.*` 또는 `startup_log` 컬렉션을 지원하지 않습니다. ### `cursormaxTimeMS` Amazon DocumentDB에서 `cursor.maxTimeMS`은 각 `getMore` 요청에 대해 카운터를 재설정합니다. 따라서 3000MS `maxTimeMS`을 지정하면 쿼리에 2800MS가 걸리고 이후의 각 `getMore` 요청에는 300MS가 걸리므로, 커서가 타임아웃되지 않습니다. 쿼리 또는 개별 `getMore` 요청 중 단일 작업에 지정된 `maxTimeMS`보다 많은 시간이 걸리는 경우에만 커서가 시간 초과됩니다. 또한, 커서 실행 시간을 확인하는 스위퍼는 5분 단위로 실행됩니다. ### explain() Amazon DocumentDB는 분산된 내결함성 자가 복구 스토리지 시스템을 활용하는 목적별 데이터베이스 엔진에서 MongoDB 3.6, 4.0, 5.0 및 8.0 APIs를 에뮬레이션합니다. 그 결과, 쿼리 계획과 `explain()`의 출력은 Amazon DocumentDB와 MongoDB 간에 다를 수 있습니다. 쿼리 계획을 제어하려는 고객은 `$hint` 연산자를 사용하여 기본 인덱스를 선택할 수 있습니다. ### 인덱스 빌드 Amazon DocumentDB는 특정 시간에 모음에서 발생하는 배경 인덱스 빌드를 하나만 허용합니다. 포그라운드 또는 백그라운드 둘 다에서. 인덱스 빌드가 현재 진행 중일 때 같은 컬렉션에서 `createIndex()` 또는 `dropIndex()`와 같은 작업이 발생하면 새로 시도한 작업이 실패합니다. 기본적으로 Amazon DocumentDB 및 MongoDB 버전 4.0의 인덱스 빌드는 포그라운드에서 실행됩니다. MongoDB 버전 4.2 이상에서는 createIndexes 또는 해당 쉘 도우미 `createIndex()` 및 `createIndexes()`에 지정된 경우, 백그라운드 인덱스 빌드 옵션을 무시합니다. TTL(Time to Live) 인덱스는 배경 인덱스 빌드가 완료된 이후에 문서 만료를 시작합니다. ### 경로에 빈 키를 사용하여 조회 경로의 일부로 빈 문자열이 포함된 키(예: `x.`, `x..b`)를 찾고, 객체의 배열 내에 빈 문자열 키 경로가 있는 경우(예: `{"x" : [ { "" : 10 }, { "b" : 20 } ]}`), Amazon DocumentDB는 MongoDB에서 동일한 검색을 실행한 경우와 다른 결과를 반환합니다. MongoDB에서, 배열 내 빈 키 경로 조회는 빈 문자열 키가 경로 조회의 끝에 있지 않을 때 예상대로 작동합니다. 하지만 경로 조회 끝에 빈 문자열 키가 있으면 배열을 들여다보지 않습니다. 하지만 Amazon DocumentDB에서는 `getArrayIndexFromKeyString`은 빈 문자열을 `0`로 변환하므로 배열 내의 첫 번째 요소만 읽습니다. 따라서 문자열 키 조회는 배열 인덱스 검색으로 취급됩니다. ### MongoDB API, 작업 및 데이터 형식 Amazon DocumentDB는 MongoDB 3.6, 4.0, 5.0 및 8.0 APIs. 지원되는 기능의 최신 목록을 보려면 [Amazon DocumentDB에서 지원되는 MongoDB API, 작업 및 데이터 형식](mongo-apis.md) 섹션을 참조하세요. ### `mongodump`및 `mongorestore` 유틸리티 Amazon DocumentDB는 관리자 데이터베이스를 지원하지 않으며, 따라서 `mongodump` 또는 `mongorestore` 유틸리티를 사용할 때 관리자 데이터베이스를 덤프하거나 복원하지 않습니다. Amazon DocumentDB에서 `mongorestore`을 사용하여 새 데이터베이스를 생성할 경우 복원 작업 이외에 사용자 역할을 다시 생성해야 합니다. **참고** Amazon DocumentDB의 경우 버전 100.6.1까지의 MongoDB 데이터베이스 도구를 사용하는 것이 좋습니다. [여기](https://www.mongodb.com/download-center/database-tools/releases/archive)에서 MongoDB 데이터베이스 도구 다운로드에 액세스할 수 있습니다. ### 결과 주문 Amazon DocumentDB는 결과 집합의 암시적 결과 정렬 순서를 보장하지 않습니다. 결과 집합의 순서를 보장하려면 `sort()`를 사용하여 정렬 순서를 명시적으로 지정합니다. 다음 예에서는 재고 수집의 항목을 재고 필드를 기준으로 내림차순으로 정렬합니다. ``` db.inventory.find().sort({ stock: -1 }) ``` `$sort` 집계 단계를 사용할 경우 해당 단계가 집계 파이프라인의 마지막 `$sort` 단계가 아니면 정렬 순서가 보존되지 않습니다. `$sort` 집계 단계를 `$group`집계 단계와 함께 사용하는 경우 `$sort` 집계 단계는 `$first` 및 `$last` 누적기에만 적용됩니다. Amazon DocumentDB 4.0에서는 이전 `$sort` 단계의 정렬 순서를 준수하기 위한 지원이 `$push`에 추가되었습니다. ### 재시도 가능한 쓰기 MongoDB 4.2 호환 드라이버부터는 기본적으로 재시도 가능한 쓰기가 활성화되어 있습니다. 그러나 Amazon DocumentDB는 현재 재시도 가능한 쓰기는 지원하지 않습니다. 기능상의 차이점은 다음과 유사한 오류 메시지로 나타납니다. ``` {"ok":0,"errmsg":"Unrecognized field: 'txnNumber'","code":9,"name":"MongoError"} ``` 재시도 가능한 쓰기는 연결 문자열(예: `MongoClient("mongodb://my.mongodb.cluster/db?retryWrites=false")`) 또는 MongoClient 생성자의 키워드 인수(예: `MongoClient("mongodb://my.mongodb.cluster/db", retryWrites=False)`)를 통해 비활성화할 수 있습니다. 다음은 연결 문자열에서 재시도 가능한 쓰기를 비활성화하는 Python 예제입니다. ``` client = pymongo.MongoClient('mongodb://:@docdb-2019-03-17-16-49-12.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0',w='majority',j=True,retryWrites=False) ``` ### 희소 인덱스 쿼리에서 생성된 희소 인덱스를 사용하려면 인덱스를 포함하는 필드에서 `$exists` 절을 사용해야 합니다. `$exists`를 생략하면 Amazon DocumentDB는 희소 인덱스를 사용하지 않습니다. 다음은 예입니다. ``` db.inventory.count({ "stock": { $exists: true }}) ``` 스파스 다중 키 인덱스의 경우 Amazon DocumentDB는 문서 조회 결과로 값 집합이 생성되고 인덱싱된 필드의 하위 집합만 누락된 경우 고유 키 제약 조건을 지원하지 않습니다. 예를 들어, `"a.c"`가 인덱스에 저장되므로 `"a" : [ { "b" : 2 }, { "c" : 1 } ]`의 입력이 주어지면 `createIndex({"a.b" : 1 }, { unique : true, sparse :true })`는 지원되지 않습니다. ### `$all` 표현식 내에서 `$elemMatch` 사용 Amazon DocumentDB는 현재 `$all` 표현식 내에서 `$elemMatch` 연산자 사용을 지원하지 않습니다. 차선책으로 다음과 같이 `$elemMatch`와 함께 `$and` 연산자를 사용할 수 있습니다. 원래 작업: ``` db.col.find({ qty: { $all: [ { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } }, { "$elemMatch": { num: 40, size: "XL" } } ] } }) ``` 업데이트된 작업: ``` db.col.find({ $and: [ { qty: { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } } }, { qty: { "$elemMatch": { qty: 40, size: "XL" } } } ] }) ``` ### 필드 이름의 달러(\$1) 및 점(.) Amazon DocumentDB는 중첩 객체에서 \$1in, \$1nin 및 \$1all의 달러(\$1) 접두사 필드 쿼리를 지원하지 않습니다. 예를 들어 다음 쿼리는 Amazon DocumentDB에서 유효하지 않습니다. ``` coll.find({"field": {"$all": [{ "$a": 1 }]}}) ``` ### `$lookup` Amazon DocumentDB는 균등 일치(예: 왼쪽 외부 조인)를 수행할 수 있는 기능을 지원하고 상관 관계가 없는 하위 쿼리를 지원하지만, 상관 관계가 있는 하위 쿼리를 지원하지 않습니다. #### `$lookup`과 인덱스를 활용하면 이제 `$lookup` 스테이지 연산자를 사용하여 인덱스를 활용할 수 있습니다. 사용 사례에 따라 성능을 최적화하는 데 사용할 수 있는 여러 인덱싱 알고리즘이 있습니다. 이 섹션에서는 `$lookup`을 위한 다양한 인덱싱 알고리즘을 설명하고 워크로드에 가장 적합한 알고리즘을 선택하는 데 도움이 됩니다. 기본적으로 Amazon DocumentDB는 `allowDiskUse:false`을 사용할 때는 해시 알고리즘을 활용하고, `allowDiskUse:true`를 사용할 때는 정렬 병합을 사용합니다. **참고** 이 `allowDiskUse` 옵션은 현재 `find` 명령에 지원되지 않습니다. 옵션은 집계의 일부로만 지원됩니다. 메모리 제한을 초과할 수 있는 대규모 쿼리를 처리하려면 `allowDiskUse:true` 항목과 함께 집계 프레임워크를 사용하는 것이 좋습니다. 일부 사용 사례의 경우 쿼리 최적화 프로그램이 다른 알고리즘을 사용하도록 강제하는 것이 바람직할 수 있습니다. `$lookup` 집계 연산자가 이용할 수 있는 다양한 인덱싱 알고리즘은 다음과 같습니다. + **중첩 루프**: 외부 컬렉션이 1GB 미만이고 외부 컬렉션의 필드에 인덱스가 있는 경우, 일반적으로 중첩 루프 계획이 워크로드에 유용합니다. 중첩 루프 알고리즘을 사용하는 경우 계획 설명에는 단계가 `NESTED_LOOP_LOOKUP`로 표시됩니다. + **정렬 병합**: 외부 컬렉션에 조회에 사용되는 필드에 대한 색인이 없고 작업 데이터셋이 메모리에 맞지 않는 경우 일반적으로 정렬 병합 계획이 워크로드에 유용합니다. 정렬 병합 알고리즘을 사용하는 경우 설명 계획에는 단계가 `SORT_LOOKUP`로 표시됩니다. + **해시**: 일반적으로 해시 계획은 외부 컬렉션이 1GB 미만이고 작업 데이터셋이 메모리에 들어갈 수 있는 경우 워크로드에 유용합니다. 해시 알고리즘을 사용하는 경우 설명 계획에는 단계가 `HASH_LOOKUP`로 표시됩니다. 쿼리에서 `explain`을 사용하여 `$lookup` 연산자에 사용되는 인덱싱 알고리즘을 식별할 수 있습니다. 아래는 하나의 예제입니다. ``` db.localCollection.explain().aggregate( [ { $lookup: { from: "foreignCollection", localField: "a", foreignField: "b", as: "joined" } } ] ) output { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.localCollection", "winningPlan" : { "stage" : "SUBSCAN", "inputStage" : { "stage" : "SORT_AGGREGATE", "inputStage" : { "stage" : "SORT", "inputStage" : { "stage" : "NESTED_LOOP_LOOKUP", "inputStages" : [ { "stage" : "COLLSCAN" }, { "stage" : "FETCH", "inputStage" : { "stage" : "COLLSCAN" } } ] } } } } }, "serverInfo" : { "host" : "devbox-test", "port" : 27317, "version" : "3.6.0" }, "ok" : 1 } ``` `explain()` 메서드를 사용하는 대신 프로파일러를 사용하여 `$lookup` 연산자 사용 시 사용 중인 알고리즘을 검토할 수 있습니다. 이 프로파일에 대한 자세한 정보는 [Amazon DocumentDB 작업 프로파일링](profiling.md) 섹션을 참조하세요. #### `planHint` 사용 쿼리 최적화 프로그램에서 `$lookup`에 다른 인덱싱 알고리즘을 사용하도록 하려면 `planHint`를 사용할 수 있습니다. 이렇게 하려면 집계 단계 옵션의 설명을 사용하여 다른 계획을 적용하세요. 다음은 주석 구문의 예시입니다. ``` comment : { comment : "", lookupStage : { planHint : "SORT" | "HASH" | "NESTED_LOOP" } } ``` 다음은 `planHint`을 사용하여 쿼리 최적화 프로그램이 `HASH` 인덱싱 알고리즘을 사용하도록 강제하는 예입니다. ``` db.foo.aggregate( [ { $lookup: { from: "foo", localField: "_id", foreignField: "_id", as: "joined" }, } ] ), { comment : "{ \"lookupStage\" : { \"planHint\": \"HASH\" }}" ``` 워크로드에 가장 적합한 알고리즘을 테스트하려면 `explain` 메서드의 `executionStats` 파라미터를 사용하여 `$lookup` 스테이지의 실행 시간을 측정하고 인덱싱 알고리즘을 수정할 수 있습니다(즉, `HASH`/`SORT`/`NESTED_LOOP`). 다음 예제는 `SORT` 알고리즘을 사용하여 `$lookup` 스테이지의 실행 시간을 측정하는 데 `executionStats`을 사용하는 방법을 보여줍니다. ``` db.foo.explain("executionStats").aggregate( [ { $lookup: { from: "foo", localField: "_id", foreignField: "_id", as: "joined" }, } ] ), { comment : "{ \"lookupStage\" : { \"planHint\": \"SORT\" }}" ``` ### `$natural` 및 역 정렬 Amazon DocumentDB는 포워드 컬렉션 스캔에만 `$natural`을 지원합니다. 역수집 스캔(`{$natural: -1}`)은 `MongoServerError`로 이어집니다.