Amazon DocumentDB 的功能優勢已更新功能差異與 MongoDB 的功能差異

功能差異：Amazon DocumentDB 和 MongoDB

以下是 Amazon DocumentDB （具有 MongoDB 相容性）和 MongoDB 之間的功能差異。

主題

Amazon DocumentDB 的功能優勢
已更新功能差異
與 MongoDB 的功能差異

Amazon DocumentDB 的功能優勢

隱含交易

在 Amazon DocumentDB 中，所有CRUD陳述式（findAndModify、updateinsert、、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 個位元組的陣列。陣列中個別項目的限制仍維持 2，048 個位元組，與 MongoDB 一致。

如果您要建立新索引，則不需要採取任何動作來利用改進的功能。如果您有現有的索引，您可以刪除索引再重新建立，以利用改進的功能。具有改進功能的最新索引版本為 "v" : 3。

注意

對於生產叢集，刪除索引可能會影響您的應用程式效能。建議您在對生產系統變更時先加以測試並小心進行。此外，重新建立索引所需的時間，將是集合整體資料大小的函數。

您可以使用以下命令查詢索引的版本。


db.collection.getIndexes()

此操作的輸出將會如下所示。在此輸出中，索引的版本是 "v" : 3，這是最新的索引版本。


[
    {
        "v" : 3,
        "key" : {
        "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.test"
    }
]

多金鑰索引

截至 2020 年 4 月 23 日，Amazon DocumentDB 現在支援建立具有相同陣列中多個索引鍵的複合索引。

注意

您可以使用以下命令查詢索引的版本。


db.collection.getIndexes()

此操作的輸出將會如下所示。在此輸出中，索引的版本是 "v" : 3，這是最新的索引版本。


[
    {
        "v" : 3,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.test"
    }
]

字串中的空字元

截至 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()。

注意

hint() 方法一次只能與一個索引一起使用。

$regex 查詢的索引使用已針對使用字首且未指定 I, 、m 或 o 規則運算式選項的查詢進行最佳化。

將 $regex 搭配索引使用時，建議您在有高度選擇性的欄位上建立索引，其中重複值的數目會小於集合中文件總數的 1%。例如，如果您的集合包含 100,000 份文件，則只在相同值出現 1000 次或更少的欄位上建立索引。

巢狀文件的投影

Amazon DocumentDB 和 MongoDB 3.6 版中的運算$project子存在功能差異，該差異已在 Amazon DocumentDB 4.0 中解決，但在 Amazon DocumentDB 3.6 中仍不受支援。

Amazon DocumentDB 3.6 只會在套用投影時考慮巢狀文件中的第一個欄位，而 MongoDB 3.6 也會剖析子文件，並將投影套用至每個子文件。

例如：如果投影為 “a.b.c”: 1，則行為在 Amazon DocumentDB 和 MongoDB 中都會如預期般運作。但是，如果投影是 Amazon DocumentDB 3.6{a:{b:{c:1}}}，則只會將投影套用至 a ，而不是 b或 c。在 Amazon DocumentDB 4.0 中，投影{a:{b:{c:1}}}將套用至 a、 b和 c。

與 MongoDB 的功能差異

主題

$vectorSearch運算子
OpCountersCommand
管理員資料庫和集合
cursormaxTimeMS
explain()
欄位名稱限制
索引建置
路徑中具有空索引鍵的查詢
MongoDB APIs、操作和資料類型
mongodump 和 mongorestore 公用程式
結果排序
可重試寫入
稀鬆索引
在$all表達式$elemMatch內使用
$ne、$nin、$nor、$not、 $exists和 $elemMatch索引
$lookup

`$vectorSearch`運算子

Amazon DocumentDB 不支援$vectorSearch作為獨立運算子。相反地，我們在$search運算子vectorSearch內部支援。如需詳細資訊，請參閱矢量搜索 Amazon DocumentDB。

`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 中，會為每個getMore請求cursor.maxTimeMS重設計數器。因此，如果maxTimeMS指定 3000MS，則查詢需要 2800MS而每個後續getMore請求需要 300MS，則游標將不會逾時。游標只會在查詢或個別getMore請求的單一操作花費超過指定的時逾時maxTimeMS。此外，檢查游標執行時間的掃描程式會以五（5）分鐘的精細度執行。

explain()

Amazon DocumentDB 在利用分散式、容錯、自我修復儲存系統的專用資料庫引擎API上模擬 MongoDB 4.0。因此，Amazon DocumentDB 和 MongoDB 之間的查詢計劃和的輸出explain()可能不同。想要控制其查詢計劃的客戶可以使用 $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 ：$id、$ref 和 $db 中成功使用。

索引建置

Amazon DocumentDB 僅允許在任何指定時間在集合上發生一個索引建置。在前景或背景中。當索引建置目前正在進行時，如果在相同的集合上進行如 createIndex() 或 dropIndex() 等操作，最新嘗試進行的操作將會失敗。

根據預設，Amazon DocumentDB 和 MongoDB 4.0 版中的索引建置會在背景中發生。MongoDB 4.2 版及更新版本會在指定給 createIndexes 或其 Shell 協助程式 createIndex() 和時忽略背景索引建置選項。 createIndexes()

存留時間（TTL）索引會在索引建置完成後啟動過期文件。

路徑中具有空索引鍵的查詢

當您使用包含空白字串作為路徑一部分的索引鍵（例如 x.、x..b）進行查詢，且物件在陣列內具有空白字串索引鍵路徑（例如 {"x" : [ { "" : 10 }, { "b" : 20 } ]}）時，Amazon DocumentDB 會傳回與在 MongoDB 中執行相同查詢時不同的結果。

在 MongoDB 中，當空白字串金鑰不在路徑查詢結尾時，陣列內的空白金鑰路徑查詢會如預期運作。但是，當空白字串索引鍵位於路徑查詢結尾時，它不會尋找陣列。

不過在 Amazon DocumentDB 中，只會讀取陣列中的第一個元素，因為會將空字串getArrayIndexFromKeyString轉換為 0，因此字串金鑰查詢會被視為陣列索引查詢。

MongoDB APIs、操作和資料類型

Amazon DocumentDB 與 MongoDB 3.6 和 4APIs.0 相容。如需 up-to-date支援的功能清單，請參閱 Amazon DocumentDB 中支援的 MongoDB、APIs操作和資料類型。

`mongodump` 和 `mongorestore` 公用程式

Amazon DocumentDB 不支援管理員資料庫，因此在使用或 mongorestore公用程式時不會傾印mongodump或還原管理員資料庫。當您使用在 Amazon DocumentDB 中建立新資料庫時mongorestore，除了還原操作之外，還需要重新建立使用者角色。

注意

對於 Amazon DocumentDB ，我們建議使用 MongoDB 資料庫工具，包括 100.6.1 版。您可以在此處存取 MongoDB 資料庫工具下載。 https://www.mongodb.com/download-center/database-tools/releases/archive

結果排序

Amazon DocumentDB 不保證結果集的隱含結果排序順序。為確保結果集的排序，請使用 sort() 明確指定排序順序。

以下範例會根據庫存欄位以遞減順序排序庫存集合中的項目。


db.inventory.find().sort({ stock: -1 })

使用$sort彙總階段時，除非$sort階段是彙總管道中的最後一個階段，否則不會保留排序順序。將$sort彙總階段與$group彙總階段搭配使用時，$sort彙總階段只會套用至 $last $first和累積器。在 Amazon DocumentDB 4.0 中，新增了的支援$push，以尊重上一個$sort階段的排序順序。

可重試寫入

從與 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" : [ { "b" : 2 }, { "c" : 1 } ] 則不支援 createIndex({"a.b" : 1 }, { unique : true, sparse :true })，因為 "a.c" 會儲存在索引中。

在`$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、、$exists、和 $nor $not$distinct運算子搭配使用。因此，使用這些運算子會導致集合掃描。使用這些運算子的其中一個之前執行篩選條件或比對，將減少需要掃描的資料量，因此可以改善效能。

Amazon DocumentDB 新增了對 Amazon DocumentDB 5.0 和彈性叢集中運算$elemMatch子進行索引掃描的支援。當查詢僅篩選條件具有一個層級的$elemMatch篩選條件時，支援索引掃描，但如果包含巢狀$elemMatch查詢，則不支援。

$elemMatch 支援 Amazon DocumentDB 5.0 中索引掃描的查詢形狀：


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

$elemMatch 不支援 Amazon 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使用時排序合併。

注意

find 命令目前不支援allowDiskUse此選項。僅支援選項做為彙總的一部分。我們建議您使用彙總架構搭配 allowDiskUse:true 來處理可能超過記憶體限制的大型查詢。

對於某些使用案例，可能需要強制查詢最佳化工具使用不同的演算法。以下是$lookup彙總運算子可以使用的不同索引演算法：

巢狀迴圈 ：如果外部集合 <1 GB，且外部集合中的欄位具有索引，巢狀迴圈計畫通常有利於工作負載。如果使用巢狀迴圈演算法，解釋計畫將顯示階段為 NESTED_LOOP_LOOKUP。
排序合併 ：如果外部集合在查詢中使用的欄位上沒有索引，且工作資料集不適合記憶體，則排序合併計畫通常有利於工作負載。如果正在使用排序合併演算法，則說明計畫會將階段顯示為 SORT_LOOKUP。
雜湊：如果外部集合 < 1GB，且工作資料集適合記憶體，雜湊計畫通常有利於工作負載。如果使用雜湊演算法，解釋計畫會將階段顯示為 HASH_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）。

下列範例示範如何使用 executionStats 來測量使用SORT演算法的$lookup階段執行時間。


db.foo.explain(“executionStats”).aggregate(
  [    
    {   
        $lookup:
        {   
            from: "foo",
            localField: "_id",
            foreignField: "_id",
            as: "joined"
        },
    }
  ],
  {
    comment : "{ \\"lookupStage\\" : { \\"planHint\": \\"SORT\\" }}"

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

最佳實務

支援的 MongoDB、APIs操作和資料類型