As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Diferenças funcionais: Amazon DocumentDB e MongoDB
<a name="functional-differences"></a>

Abaixo estão as diferenças funcionais entre o Amazon DocumentDB (compatível com MongoDB) e o MongoDB.

**Topics**
+ [Benefícios funcionais do Amazon DocumentDB](#functional-differences.functional-benefits)
+ [Diferenças funcionais atualizadas](#functional-differences.updated-functional-differences)
+ [Diferenças funcionais com o MongoDB](#functional-differences.with-mongodb)

## Benefícios funcionais do Amazon DocumentDB
<a name="functional-differences.functional-benefits"></a>

### Transações implícitas
<a name="functional-differences.implicit-transactions"></a>

No Amazon DocumentDB, todas as instruções CRUD (`findAndModify`, `update`, `insert`, `delete`) garantem atomicidade e consistência, até mesmo para operações que modificam vários documentos. Agora, com o lançamento do Amazon DocumentDB 4.0, há suporte para transações explícitas que fornecem propriedades ACID para operações com várias instruções e várias coleções. Para obter mais informações sobre o uso de transações no Amazon DocumentDB, consulte [Transações no Amazon DocumentDB](transactions.md).

Veja a seguir exemplos de operações no Amazon DocumentDB que modificam vários documentos que satisfazem ambos os comportamentos atômico e consistente.

```
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 }]
})
```

As operações individuais que compõem operações em massa, como `updateMany` e `deleteMany`, são atômicas, mas a própria operação em massa não é atômica. Por exemplo, a totalidade da operação `insertMany` será atômica se as operações de inserção individuais forem executadas com êxito sem erros. Se um erro for encontrado em uma operação `insertMany`, cada instrução de inserção individual na operação `insertMany` será executada como uma operação atômica. Se você precisar de propriedades ACID para as operações `insertMany`, `updateMany` e `deleteMany`, é recomendável usar uma transação.

## Diferenças funcionais atualizadas
<a name="functional-differences.updated-functional-differences"></a>

O Amazon DocumentDB continua a melhorar a compatibilidade com o MongoDB, trabalhando retroativamente com as capacidades que nossos clientes nos pedem para criar. Esta seção contém as diferenças funcionais removidas do Amazon DocumentDB para facilitar as migrações e a criação de aplicações para nossos clientes. 

**Topics**
+ [Indexação de matriz](#functional-differences.array-indexing)
+ [Índices de várias chaves](#functional-differences.multi-key-indexes)
+ [Caracteres nulos em strings](#functional-differences.strings)
+ [Controle de acesso com base em função](#functional-differences.role_based_access_control)
+ [Indexação de `$regex`](#functional-differences.regex-indexing)
+ [Projeção para documentos aninhados](#functional-differences.nested-docs)

### Indexação de matriz
<a name="functional-differences.array-indexing"></a>

A partir de 23 de abril de 2020, o Amazon DocumentDB passa a oferecer suporte à capacidade de indexar matrizes maiores que 2.048 bytes. O limite para um item individual em uma matriz ainda permanece como 2.048 bytes, o que é consistente com MongoDB.

Se você estiver criando um novo índice, nenhuma ação será necessária para aproveitar a funcionalidade aprimorada. Se tiver um índice existente, você pode aproveitar a funcionalidade aprimorada, eliminando o índice e recriando-o. A versão atual do índice com os recursos aprimorados é `"v" : 3`.

**nota**  
Para clusters de produção, a eliminação do índice pode ter impacto no desempenho da aplicação. Recomendamos que você teste primeiro e prossiga com cuidado ao fazer alterações em um sistema de produção. Além disso, o tempo que levará para recriar o índice será uma função do tamanho geral dos dados da coleção.

É possível consultar a versão dos índices usando o seguinte comando.

```
db.collection.getIndexes()
```

A saída dessa operação é semelhante à seguinte. Nesta saída, a versão do índice é `"v" : 3`, que é a versão mais atual.

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

### Índices de várias chaves
<a name="functional-differences.multi-key-indexes"></a>

A partir de 23 de abril de 2020, o Amazon DocumentDB passa a oferecer suporte à capacidade de criar um índice composto com várias chaves na mesma matriz.

Se você estiver criando um novo índice, nenhuma ação será necessária para aproveitar a funcionalidade aprimorada. Se tiver um índice existente, você pode aproveitar a funcionalidade aprimorada, eliminando o índice e recriando-o. A versão atual do índice com os recursos aprimorados é `"v" : 3`.

**nota**  
Para clusters de produção, a eliminação do índice pode ter impacto no desempenho da aplicação. Recomendamos que você teste primeiro e prossiga com cuidado ao fazer alterações em um sistema de produção. Além disso, o tempo que levará para recriar o índice será uma função do tamanho geral dos dados da coleção.

É possível consultar a versão dos índices usando o seguinte comando.

```
db.collection.getIndexes()
```

A saída dessa operação é semelhante à seguinte. Nesta saída, a versão do índice é `"v" : 3`, que é a versão mais atual.

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

### Caracteres nulos em strings
<a name="functional-differences.strings"></a>

Desde 22 de junho de 2020, o Amazon DocumentDB passou a oferecer suporte a caracteres nulos ( `'\0'` ) em strings.

### Controle de acesso com base em função
<a name="functional-differences.role_based_access_control"></a>

Desde 26 de março de 2020, o Amazon DocumentDB oferece suporte ao controle de acesso baseado em função (RBAC) para funções internas. Para saber mais, consulte [Controle de acesso com base em função](role_based_access_control.md).

### Indexação de `$regex`
<a name="functional-differences.regex-indexing"></a>

Desde 22 de junho de 2020, o Amazon DocumentDB passou a oferecer suporte à capacidade de operadores `$regex` utilizarem um índice.

Para utilizar um índice com o operador `$regex`, é necessário usar o comando `hint()`. Ao usar `hint()`, é necessário especificar o nome do campo no qual você está aplicando o `$regex`. Por exemplo, se você tiver um índice no campo `product` com o nome do índice como `p_1`, `db.foo.find({product: /^x.*/}).hint({product:1})` usará o índice `p_1`, mas não usará o índice `db.foo.find({product: /^x.*/}).hint(“p_1”)`. É possível verificar se um índice é escolhido utilizando o comando `explain()` ou usando o profiler para registrar em log consultas lentas. Por exemplo, .`db.foo.find({product: /^x.*/}).hint(“p_1”).explain()`

**nota**  
O método `hint()` só pode ser usado com um índice de cada vez.

O uso de um índice para uma consulta `$regex` é otimizado para consultas de regex que usam um prefixo e não especificam as opções de regex `i`, `m` ou `o`.

Ao usar um índice com `$regex`, é recomendável criar um índice em campos altamente seletivos onde o número de valores duplicados é inferior a 1% do número total de documentos na coleção. Por exemplo, se sua coleção contiver 100.000 documentos, crie índices somente em campos em que o mesmo valor ocorrer 1000 vezes ou menos.

### Projeção para documentos aninhados
<a name="functional-differences.nested-docs"></a>

Há uma diferença funcional entre o Amazon DocumentDB e o MongoDB com o operador `$project` na versão 3.6 que foi resolvida no Amazon DocumentDB 4.0, mas que permanecerá sem suporte no Amazon DocumentDB 3.6.

O Amazon DocumentDB 3.6 só considera o primeiro campo em um documento aninhado ao aplicar uma projeção e o MongoDB 3.6 também analisará subdocumentos e aplicará a projeção a cada subdocumento. 

Por exemplo: se a projeção for `“a.b.c”: 1`, o comportamento funcionará conforme o esperado no Amazon DocumentDB e no MongoDB. No entanto, se a projeção for `{a:{b:{c:1}}}`, o Amazon DocumentDB 3.6 aplicará a projeção somente a `a` e não a `b` ou `c`. No Amazon DocumentDB 4.0, a projeção `{a:{b:{c:1}}}` será aplicada a `a`, `b` e `c`.

## Diferenças funcionais com o MongoDB
<a name="functional-differences.with-mongodb"></a>

**Topics**
+ [Operador `$vectorSearch`](#functional-differences.vector-search)
+ [`OpCountersCommand`](#functional-differences.op-counter)
+ [Bancos de dados e coleções de administradores](#functional-differences.admin-databases)
+ [`cursormaxTimeMS`](#functional-differences.cursormaxTimeMS)
+ [explain()](#functional-differences.explain)
+ [Compilações de índice](#functional-differences.background-indexes)
+ [Pesquisa com chave vazia no caminho](#functional-differences.lookup-empty)
+ [APIsMongoDB, operações e tipos de dados](#functional-differences.mongo-apis)
+ [Utilitários `mongodump` e `mongorestore`](#functional-differences.mongodump-mongorestore)
+ [Ordenação de resultados](#functional-differences.result-ordering)
+ [Gravações repetíveis](#functional-differences.retryable-writes)
+ [Índice esparso](#functional-differences.sparse-index)
+ [Usar `$elemMatch` dentro de uma expressão `$all`](#functional-differences.elemMatch)
+ [Dólar (\$1) e ponto (.) nos nomes dos campos](#functional-differences-dollardot)
+ [`$lookup`](#functional-differences.lookup)
+ [`$natural` e classificação reversa](#functional-differences.natural)

### Operador `$vectorSearch`
<a name="functional-differences.vector-search"></a>

O Amazon DocumentDB não oferece suporte a `$vectorSearch` como um operador independente. Em vez disso, temos suporte para `vectorSearch` dentro do operador `$search`. Para obter mais informações, consulte [Pesquisa vetorial para Amazon DocumentDB](vector-search.md).

### `OpCountersCommand`
<a name="functional-differences.op-counter"></a>

O comportamento `OpCountersCommand` do Amazon DocumentDB se desvia do `opcounters.command` do MongoDB da seguinte forma:
+ O `opcounters.command` do MongoDB conta todos os comandos, exceto inserir, atualizar e excluir, enquanto que o `OpCountersCommand` do Amazon DocumentDB também exclui o comando `find`.
+ O Amazon DocumentDB considera alguns comandos internos com relação a `OpCountersCommand`.

### Bancos de dados e coleções de administradores
<a name="functional-differences.admin-databases"></a>

O Amazon DocumentDB não oferece suporte ao banco de dados de administrador ou local nem às coleções do MongoDB `system.*` ou `startup_log` respectivamente.

### `cursormaxTimeMS`
<a name="functional-differences.cursormaxTimeMS"></a>

No Amazon DocumentDB, `cursor.maxTimeMS` redefine o contador de cada solicitação `getMore`. Portanto, se for especificado 3.000 ms `maxTimeMS`, a consulta irá demorar 2.800 ms e cada solicitação `getMore` subsequente irá demorar 300 ms, depois, o cursor não atingirá o tempo limite. O cursor só atingirá o tempo limite quando uma única operação, seja a consulta ou uma determinada solicitação `getMore`, demorar mais do que o `maxTimeMS` especificado. Além disso, o varredor que verifica o tempo de execução do cursor é executado em uma granularidade de cinco (5) minutos.

### explain()
<a name="functional-differences.explain"></a>

O Amazon DocumentDB emula o MongoDB 3.6, 4.0, 5.0 e 8.0 APIs em um mecanismo de banco de dados específico que utiliza um sistema de armazenamento distribuído, tolerante a falhas e com autorrecuperação. Como resultado, os planos de consulta e a saída de `explain()` podem diferir entre o Amazon DocumentDB e o MongoDB. Os clientes que desejam ter controle sobre seu plano de consulta podem usar o operador `$hint` para impor a seleção de um índice preferencial.

### Compilações de índice
<a name="functional-differences.background-indexes"></a>

O Amazon DocumentDB permite que apenas uma compilação de índice ocorra em uma coleção a qualquer momento. Seja em primeiro plano ou em segundo plano. Se operações como `createIndex()` ou `dropIndex()` ocorrerem na mesma coleção quando uma compilação de índice estiver em andamento no momento, ocorrerá uma falha na operação que você tentou executar recentemente.

Por padrão, as construções de índices no Amazon DocumentDB e na versão 4.0 do MongoDB ocorrem em segundo plano. As versões 4.2 e posteriores do MongoDB ignoram a opção de construção do índice em segundo plano se especificada para createIndexes ou seus auxiliares de shell `createIndex()` e `createIndexes()`. 

Um índice de Tempo de vida (TTL) começará a extinguir a validade de documentos depois que o índice de compilação for concluído.

### Pesquisa com chave vazia no caminho
<a name="functional-differences.lookup-empty"></a>

Quando você pesquisa com uma chave que inclui uma string vazia como parte do caminho (por exemplo, `x.`, `x..b`) e o objeto tem um caminho de chaves de string vazio (por exemplo, `{"x" : [ { "" : 10 }, { "b" : 20 } ]}`) dentro de uma matriz, o Amazon DocumentDB retornará resultados diferentes do que se você executasse a mesma pesquisa no MongoDB.

No MongoDB, a pesquisa do caminho de chaves vazio dentro da matriz funciona conforme o esperado quando a chave de string vazia não está no final da pesquisa do caminho. No entanto, quando a chave de string vazia está no final da pesquisa do caminho, ela não examina a matriz.

No entanto, no Amazon DocumentDB, somente o primeiro elemento dentro da matriz é lido, pois `getArrayIndexFromKeyString` converte uma string vazia em `0`, e, então, a pesquisa por chaves de string é tratada como uma pesquisa de índice de matriz.

### APIsMongoDB, operações e tipos de dados
<a name="functional-differences.mongo-apis"></a>

O Amazon DocumentDB é compatível com o MongoDB 3.6, 4.0, 5.0 e 8.0. APIs Para obter uma up-to-date lista das funcionalidades suportadas, consulte[APIsMongoDB, operações e tipos de dados compatíveis no Amazon DocumentDB](mongo-apis.md). 

### Utilitários `mongodump` e `mongorestore`
<a name="functional-differences.mongodump-mongorestore"></a>

O Amazon DocumentDB não oferece suporte a um banco de dados de administrador e, portanto, não despeja nem restaura o banco de dados de administrador ao usar os utilitários `mongodump` ou `mongorestore`. Ao criar um novo banco de dados no Amazon DocumentDB usando `mongorestore`, é necessário recriar as funções de usuário, além da operação de restauração.

**nota**  
Recomendamos o MongoDB Database Tools até a versão 100.6.1, inclusive, para o Amazon DocumentDB. É possível acessar os downloads do MongoDB Database Tools [aqui](https://www.mongodb.com/download-center/database-tools/releases/archive).

### Ordenação de resultados
<a name="functional-differences.result-ordering"></a>

O Amazon DocumentDB não garante a ordenação de resultados implícita dos conjuntos de resultados. Para garantir a ordenação de um conjunto de resultados, especifique explicitamente uma ordem de classificação usando `sort()`.

O exemplo a seguir classifica os itens na coleção de inventário em ordem decrescente com base no campo de estoque.

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

Ao usar o estágio de agregação `$sort`, a ordem de classificação não é preservada, a menos que o estágio `$sort` seja o último estágio no pipeline de agregação. Ao usar o estágio de agregação `$sort` em combinação com o estágio de agregação `$group`, o estágio de agregação `$sort` só é aplicado aos acumuladores `$first` e `$last`. No Amazon DocumentDB 4.0, foi adicionado suporte para `$push` para respeitar a ordem de classificação do estágio `$sort` anterior.

### Gravações repetíveis
<a name="functional-differences.retryable-writes"></a>

A partir dos drivers compatíveis com o MongoDB 4.2, as gravações repetíveis são habilitadas por padrão. No entanto, o Amazon DocumentDB atualmente não oferece suporte a gravações repetíveis. A diferença funcional se manifestará em uma mensagem de erro semelhante à seguinte.

```
{"ok":0,"errmsg":"Unrecognized field: 'txnNumber'","code":9,"name":"MongoError"} 
```

As gravações repetitivas podem ser desativadas por meio da cadeia de conexão (por exemplo,`MongoClient("mongodb://my.mongodb.cluster/db?retryWrites=false")`) ou do argumento da palavra-chave do MongoClient construtor (por exemplo,). `MongoClient("mongodb://my.mongodb.cluster/db", retryWrites=False)`

Veja a seguir um exemplo de Python que desabilita gravações repetíveis na string de conexão.

```
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) 
```

### Índice esparso
<a name="functional-differences.sparse-index"></a>

Para usar um índice esparso que você criou em uma consulta, é necessário usar a cláusula `$exists` nos campos que abrangem o índice. Se você omitir `$exists`, o Amazon DocumentDB não usará o índice esparso.

Veja um exemplo do a seguir:

```
db.inventory.count({ "stock": { $exists: true }})
```

Para índices esparsos de várias chaves, o Amazon DocumentDB não oferecerá suporte a uma restrição de chave exclusiva se a pesquisa de um documento resultar em um conjunto de valores e apenas um subconjunto dos campos indexados estiver ausente. Por exemplo, `createIndex({"a.b" : 1 }, { unique : true, sparse :true })` não tem suporte, dada a entrada de `"a" : [ { "b" : 2 }, { "c" : 1 } ]`, já que `"a.c"` é armazenado no índice.

### Usar `$elemMatch` dentro de uma expressão `$all`
<a name="functional-differences.elemMatch"></a>

No momento, o Amazon DocumentDB não oferece suporte ao uso do operador `$elemMatch` dentro de uma expressão `$all`. Como solução alternativa, é possível usar o operador `$and` com `$elemMatch` da seguinte forma.

Operação original:

```
db.col.find({
  qty: {
    $all: [
      { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } },
      { "$elemMatch": { num: 40, size: "XL" } }
    ]
  }
})
```

Operação atualizada:

```
db.col.find({
  $and: [
    { qty: { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } } },
    { qty: { "$elemMatch": { qty: 40, size: "XL" } } }
  ]
})
```

### Dólar (\$1) e ponto (.) nos nomes dos campos
<a name="functional-differences-dollardot"></a>

O Amazon DocumentDB não oferece suporte à consulta de campos prefixados com dólar (\$1) em \$1in, \$1nin e \$1all em objetos aninhados. Por exemplo, a consulta a seguir não é válida no Amazon DocumentDB: 

```
coll.find({"field": {"$all": [{ "$a": 1 }]}})
```

### `$lookup`
<a name="functional-differences.lookup"></a>

O Amazon DocumentDB oferece suporte a correspondências de igualdade (por exemplo, junção externa esquerda) e também a subconsultas não correlacionadas, mas não oferece suporte a subconsultas correlacionadas.

#### Utilizando um índice com `$lookup`
<a name="functional-differences.lookup-index"></a>

Agora você pode utilizar um índice com o operador de estágio `$lookup`. Com base no seu caso de uso, há vários algoritmos de indexação que você pode usar para otimizar o desempenho. Esta seção explicará os diferentes algoritmos de indexação para `$lookup` e ajudará você a escolher o melhor para sua workload.

Por padrão, o Amazon DocumentDB utilizará o algoritmo de hash quando `allowDiskUse:false` for usado e a mesclagem de classificação quando `allowDiskUse:true` for usado .

**nota**  
No momento, a opção `allowDiskUse` não recebem suporte para o comando `find`. A opção só tem suporte como parte da agregação. Recomendamos usar a estrutura de agregação com `allowDiskUse:true` para lidar com consultas grandes que possam exceder os limites de memória.

Para alguns casos de uso, pode ser melhor forçar o otimizador de consultas a usar um algoritmo diferente. Abaixo, estão os diferentes algoritmos de indexação que o operador de agregação `$lookup` pode utilizar:
+ **Loop aninhado**: um plano de loop aninhado geralmente é benéfico para uma workload se a coleção externa tiver menos de 1 GB e o campo na coleção externa tiver um índice. Se o algoritmo de loop aninhado estiver sendo usado, o plano de explicação mostrará o estágio como `NESTED_LOOP_LOOKUP`.
+ **Mesclagem de classificação**: um plano de mesclagem de classificação geralmente é benéfico para uma workload se a coleção externa não tiver um índice no campo usado na pesquisa e o conjunto de dados de trabalho não couber na memória. Se o algoritmo de mesclagem de classificação estiver sendo usado, o plano de explicação mostrará o estágio como `SORT_LOOKUP`.
+ **Hash**: um plano de hash geralmente é benéfico para uma workload se a coleção externa for < 1 GB e o conjunto de dados de trabalho couber na memória. Se o algoritmo de hash estiver sendo usado, o plano de explicação mostrará o estágio como `HASH_LOOKUP`.

É possível identificar o algoritmo de indexação que está sendo usado pelo operador `$lookup` usando `explain` na consulta. Abaixo está um exemplo:

```
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
}
```

Como alternativa ao uso do método `explain()`, é possível usar o criador de perfil para revisar o algoritmo que está sendo utilizado com o uso do operador `$lookup`. Para obter mais informações sobre o criador de perfil, consulte . [Definir o perfil das operações do Amazon DocumentDB](profiling.md).

#### Uso de uma `planHint`
<a name="functional-differences.lookup-plan"></a>

Se você quiser forçar o otimizador de consultas a usar um algoritmo de indexação diferente com `$lookup`, você pode usar um `planHint`. Para fazer isso, use o comentário nas opções do estágio de agregação para forçar um plano diferente. Abaixo, está um exemplo de sintaxe do comentário:

```
comment : {
    comment :  "<string>",
    lookupStage : { planHint : "SORT" | "HASH" | "NESTED_LOOP" }
}
```

Abaixo, está um exemplo de uso do `planHint` para forçar o otimizador de consultas a usar o algoritmo de indexação `HASH`: 

```
db.foo.aggregate(
   [                           
      {   
         $lookup:
            {   
               from: "foo",
               localField: "_id",
               foreignField: "_id",
               as: "joined"
            },
      }
   ]
),
{
   comment : "{ \"lookupStage\" : { \"planHint\": \"HASH\" }}"
```

Para testar qual algoritmo é melhor para sua workload, você pode usar o parâmetro `executionStats` do método `explain` para medir o tempo de execução do estágio `$lookup` enquanto modifica o algoritmo de indexação (ou seja, `HASH`/`SORT`/`NESTED_LOOP`). 

O exemplo a seguir mostra como usar `executionStats` para medir o tempo de execução do estágio `$lookup` usando o algoritmo `SORT`.

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

### `$natural` e classificação reversa
<a name="functional-differences.natural"></a>

O Amazon DocumentDB oferece suporte somente a `$natural` para varreduras de coleções à frente. As varreduras de coleções reversas (`{$natural: -1}`) levarão a um `MongoServerError`.