기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기능적 차이: Amazon DocumentDB 및 MongoDB

다음은 Amazon DocumentDB(MongoDB 호환)과 MongoDB 간의 기능적 차이입니다.

Amazon DocumentDB의 기능적 이점

암시적 트랜잭션

Amazon DocumentDB에서 모든 CRUD 문(findAndModify, update, insert, delete)은 여러 문서를 수정하는 작업의 경우에도 원자성과 일관성을 보장합니다. Amazon DocumentDB 4.0이 출시되면서, 이제 다중 명령문 및 다중 컬렉션 작업에 대한 ACID 속성을 제공하는 명시적 트랜잭션이 지원됩니다. Amazon DocumentDB에서의 트랜잭션 사용에 대한 자세한 내용은 Amazon DocumentDB의 트랜잭션을 참조하세요.

다음은 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에서 제거한 기능적 차이가 포함되어 있습니다.

배열 인덱싱

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(역할 기반 액세스 제어)를 지원합니다. 자세한 내용은 역할 기반 액세스 제어을 참조하세요.

$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().

$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와 기능적 차이

$vectorSearch 연산자

Amazon DocumentDB는 독립 연산자로 $vectorSearch 항목을 지원하지 않습니다. 대신 $search 연산자 내에서 vectorSearch 항목을 지원합니다. 자세한 내용은 Amazon DocumentDB에 대한 벡터 검색 섹션을 참조하세요.

OpCountersCommand

Amazon DocumentDB의 OpCountersCommand 동작은 다음과 같이 MongoDB의 opcounters.command에서 벗어납니다.

관리자 데이터베이스 및 컬렉션

Amazon DocumentDB는 각각 관리자 또는 로컬 데이터베이스, MongoDB system.* 또는 startup_log 컬렉션을 지원하지 않습니다.

cursormaxTimeMS

Amazon DocumentDB에서 cursor.maxTimeMS은 각 getMore 요청에 대해 카운터를 재설정합니다. 따라서 3000MS maxTimeMS을 지정하면 쿼리에 2800MS가 걸리고 이후의 각 getMore 요청에는 300MS가 걸리므로, 커서가 타임아웃되지 않습니다. 쿼리 또는 개별 getMore 요청 중 단일 작업에 지정된 maxTimeMS보다 많은 시간이 걸리는 경우에만 커서가 시간 초과됩니다. 또한, 커서 실행 시간을 확인하는 스위퍼는 5분 단위로 실행됩니다.

explain()

Amazon DocumentDB는 분산, 내결함성, 자가 치유 스토리지 시스템을 활용하는 목적으로 만들어진 목적별 데이터베이스 엔진에서 MongoDB 4.0 API를 에뮬레이션합니다. 그 결과, 쿼리 계획과 explain()의 출력은 Amazon DocumentDB와 MongoDB 간에 다를 수 있습니다. 쿼리 계획을 제어하려는 고객은 $hint 연산자를 사용하여 기본 인덱스를 선택할 수 있습니다.

필드 이름 제한 사항

Amazon DocumentDB는 점(‘.’)을 지원하지 않습니다. 문서 필드 이름에서, 예를 들면, db.foo.insert({‘x.1’:1})입니다.

또한 Amazon DocumentDB는 필드 이름에 $ 접두사를 지원하지 않습니다.

예를 들어, Amazon DocumentDB 또는 MongoDB에서 다음 명령을 시도해 보세요.

rs0:PRIMARY< db.foo.insert({"a":{"$a":1}})

MongoDB는 다음을 반환합니다.

WriteResult({ "nInserted" : 1 })

Amazon DocumentDB는 다음과 같은 오류를 반환합니다.

WriteResult({
"nInserted" : 0,
"writeError" : {
"code" : 2,
"errmsg" : "Document can't have $ prefix field names: $a"
}
})
         

인덱스 빌드

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는 몽고DB 3.6 및 4.0 API와 호환됩니다. 지원되는 기능의 최신 목록을 보려면 Amazon DocumentDB에서 지원되는 MongoDB APIs, 작업 및 데이터 유형 섹션을 참조하세요.

mongodump및 mongorestore 유틸리티

Amazon DocumentDB는 관리자 데이터베이스를 지원하지 않으며, 따라서 mongodump 또는 mongorestore 유틸리티를 사용할 때 관리자 데이터베이스를 덤프하거나 복원하지 않습니다. Amazon DocumentDB에서 mongorestore을 사용하여 새 데이터베이스를 생성할 경우 복원 작업 이외에 사용자 역할을 다시 생성해야 합니다.

결과 주문

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://<username>:<password>@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" } } }
  ]
})
         

$ne, $nin, $nor, $not, $exists, 및 $elemMatch 인덱싱

Amazon DocumentDB는 현재 $ne, $nin, $nor, $not $exists 및 $distinct 연산자와 함께 인덱스를 사용하는 기능을 지원하지 않습니다. 따라서 이러한 연산자를 사용하면 수집 스캔이 발생합니다. 이러한 연산자 중 하나를 사용하기 전에 필터 또는 일치를 수행하면 스캔해야 하는 데이터의 양이 줄어들어 성능이 향상될 수 있습니다.

Amazon DocumentDB는 Amazon DocumentDB 5.0 및 엘라스틱 클러스터에서 $elemMatch 운영자를 통한 인덱스 스캔에 대한 지원을 추가했습니다. 쿼리 전용 필터에 한 레벨의 $elemMatch 필터가 있는 경우 인덱스 스캔이 지원되지만 중첩된 $elemMatch 쿼리가 포함된 경우에는 필터가 지원되지 않습니다.

$elemMatchAmazon DocumentDB 5.0의 인덱스 스캔을 지원하는 쿼리 셰이프:

db.foo.find( { "a": {$elemMatch: { "b": "xyz", "c": "abc"} } })

$elemMatchAmazon DocumentDB 5.0의 인덱스 스캔을 지원하지 않는 쿼리 셰이프:

db.foo.find( { "a": {$elemMatch: { "b": {$elemMatch: { "d": "xyz", "e": "abc"} }} } })

$lookup

Amazon DocumentDB는 균등 일치(예: 왼쪽 외부 조인)를 수행할 수 있는 기능을 지원하고 상관 관계가 없는 하위 쿼리를 지원하지만, 상관 관계가 있는 하위 쿼리를 지원하지 않습니다.

$lookup과 인덱스를 활용하면

이제 $lookup 스테이지 연산자를 사용하여 인덱스를 활용할 수 있습니다. 사용 사례에 따라 성능을 최적화하는 데 사용할 수 있는 여러 인덱싱 알고리즘이 있습니다. 이 섹션에서는 $lookup을 위한 다양한 인덱싱 알고리즘을 설명하고 워크로드에 가장 적합한 알고리즘을 선택하는 데 도움이 됩니다.

기본적으로 Amazon DocumentDB는 allowDiskUse:false을 사용할 때는 해시 알고리즘을 활용하고, allowDiskUse:true를 사용할 때는 정렬 병합을 사용합니다.

일부 사용 사례의 경우 쿼리 최적화 프로그램이 다른 알고리즘을 사용하도록 강제하는 것이 바람직할 수 있습니다. $lookup 집계 연산자가 이용할 수 있는 다양한 인덱싱 알고리즘은 다음과 같습니다.

쿼리에서 설명을 사용하여 $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 작업 프로파일링 섹션을 참조하세요.

planHint 사용

쿼리 최적화 프로그램에서 $lookup에 다른 인덱싱 알고리즘을 사용하도록 하려면 planHint를 사용할 수 있습니다. 이렇게 하려면 집계 단계 옵션의 설명을 사용하여 다른 계획을 적용하세요. 다음은 주석 구문의 예시입니다.

comment : {
    comment :  “<string>”,
    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\\" }}"