Differenze funzionali: Amazon DocumentDB e MongoDB

Di seguito sono riportate le differenze funzionali tra Amazon DocumentDB (con compatibilità MongoDB) e MongoDB.

Vantaggi funzionali di Amazon DocumentDB

Transazioni implicite

In Amazon DocumentDB, tutte le istruzioni CRUD (findAndModify,, updateinsert,delete) garantiscono atomicità e coerenza, anche per le operazioni che modificano più documenti. Con il lancio di Amazon DocumentDB 4.0, sono ora supportate le transazioni esplicite che forniscono proprietà ACID per operazioni con più dichiarazioni e raccolte multiple. Per ulteriori informazioni sull'utilizzo delle transazioni in Amazon DocumentDB, consulta. Transazioni in Amazon DocumentDB

Di seguito sono riportati alcuni esempi di operazioni in Amazon DocumentDB che modificano più documenti che soddisfano comportamenti sia atomici che coerenti.

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

Le singole operazioni che compongono operazioni di massa come updateMany e deleteMany sono atomiche, ma la totalità dell'operazione di massa non è atomica. Ad esempio, la totalità dell'operazione insertMany è atomica se le singole operazioni di inserimento vengono eseguite correttamente senza errori. Se si verifica un errore con un'operazione insertMany, ogni singola istruzione insert all'interno dell'operazione insertMany verrà eseguita come operazione atomica. Se sono necessarie proprietà ACID per insertMany e deleteMany operazioni, si consiglia di utilizzare una transazione. updateMany

Differenze funzionali aggiornate

Amazon DocumentDB continua a migliorare la compatibilità con MongoDB sfruttando le funzionalità che i nostri clienti ci chiedono di creare. Questa sezione contiene le differenze funzionali che abbiamo rimosso in Amazon DocumentDB per semplificare le migrazioni e la creazione di applicazioni per i nostri clienti.

Argomenti

• Indicizzazione degli array

• Multi-key indici

• Caratteri nulli nelle stringhe

• Role-based controllo degli accessi

• indicizzazione $regex

• Proiezione per documenti annidati

Indicizzazione degli array

A partire dal 23 aprile 2020, Amazon DocumentDB supporta ora la possibilità di indicizzare array di dimensioni superiori a 2.048 byte. Il limite per un singolo elemento in un array rimane di 2.048 byte, il che è coerente con MongoDB.

Se si sta creando un nuovo indice, non è necessaria alcuna operazione per sfruttare le funzionalità migliorate. Se si dispone di un indice esistente, è possibile sfruttare le funzionalità migliorate rilasciando l'indice e quindi ricreandolo. La versione dell'indice corrente con le funzionalità migliorate è "v" : 3.

Nota

Per i cluster di produzione, l'eliminazione dell'indice potrebbe avere un impatto sulle prestazioni dell'applicazione. Effettua prima i test e procedi con cautela quando apporti modifiche a un sistema di produzione. Inoltre, il tempo necessario per ricreare l'indice dipende dalla dimensione complessiva dei dati della raccolta.

È possibile eseguire una query per la versione degli indici utilizzando il seguente comando.

db.collection.getIndexes()

L'aspetto dell'output di questa operazione è simile al seguente. In questo output, la versione dell'indice è "v" : 3, che è quella più recente.

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

Multi-key indici

A partire dal 23 aprile 2020, Amazon DocumentDB supporta ora la possibilità di creare un indice composto con più chiavi nello stesso array.

Se si sta creando un nuovo indice, non è necessaria alcuna operazione per sfruttare le funzionalità migliorate. Se si dispone di un indice esistente, è possibile sfruttare le funzionalità migliorate rilasciando l'indice e quindi ricreandolo. La versione dell'indice corrente con le funzionalità migliorate è "v" : 3.

Nota

Per i cluster di produzione, l'eliminazione dell'indice potrebbe avere un impatto sulle prestazioni dell'applicazione. Effettua prima i test e procedi con cautela quando apporti modifiche a un sistema di produzione. Inoltre, il tempo necessario per ricreare l'indice dipende dalla dimensione complessiva dei dati della raccolta.

È possibile eseguire una query per la versione degli indici utilizzando il seguente comando.

db.collection.getIndexes()

L'aspetto dell'output di questa operazione è simile al seguente. In questo output, la versione dell'indice è "v" : 3, che è quella più recente.

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

Caratteri nulli nelle stringhe

A partire dal 22 giugno 2020, Amazon DocumentDB ora supporta i caratteri nulli () '\0' nelle stringhe.

Role-based controllo degli accessi

A partire dal 26 marzo 2020, Amazon DocumentDB supporta il controllo degli accessi basato sui ruoli (RBAC) per i ruoli integrati. Per ulteriori informazioni, consulta Role-Based Controllo degli accessi.

indicizzazione $regex

A partire dal 22 giugno 2020, Amazon DocumentDB ora supporta la possibilità per $regex gli operatori di utilizzare un indice.

Per utilizzare un indice con l'operatore $regex, è necessario utilizzare il comando hint(). Quando si utilizza hint(), è necessario specificare il nome del campo in cui si sta applicando $regex. Ad esempio, se si dispone di un indice nel campo product con il nome dell'indice come p_1, db.foo.find({product: /^x.*/}).hint({product:1}) utilizzerà l'indice p_1, ma db.foo.find({product: /^x.*/}).hint(“p_1”) non utilizzerà l'indice. È possibile verificare se viene scelto un indice utilizzando il comando explain() o utilizzando il profiler per la registrazione di query lente. Ad esempio, db.foo.find({product: /^x.*/}).hint(“p_1”).explain().

Nota

Il metodo hint() può essere utilizzato solo con un indice alla volta.

L'utilizzo di un indice per una query $regex è ottimizzato per le query regex che utilizzano un prefisso e non specificano le opzioni regex i, m o o.

Quando si utilizza un indice con $regex, si consiglia di creare un indice in campi altamente selettivi in cui il numero di valori duplicati è inferiore all'1% del numero totale di documenti nella raccolta. Ad esempio, se la raccolta contiene 100.000 documenti, creare solo indici nei campi in cui lo stesso valore si verifica al massimo 1000 volte.

Proiezione per documenti annidati

Esiste una differenza funzionale con $project l'operatore tra Amazon DocumentDB e MongoDB nella versione 3.6 che è stata risolta in Amazon DocumentDB 4.0 ma rimarrà non supportata in Amazon DocumentDB 3.6.

Amazon DocumentDB 3.6 considera solo il primo campo in un documento annidato quando applica una proiezione, mentre MongoDB 3.6 analizzerà i documenti secondari e applicherà la proiezione anche a ciascun documento secondario.

Ad esempio: se la proiezione è, il comportamento funziona come previsto sia in Amazon DocumentDB che in “a.b.c”: 1 MongoDB. Tuttavia, se la proiezione è{a:{b:{c:1}}}, Amazon DocumentDB 3.6 applicherà la proiezione solo a e non a or. a b c In Amazon DocumentDB 4.0, la proiezione {a:{b:{c:1}}} verrà applicata a, e. a b c

Differenze funzionali con MongoDB

Argomenti

• Operatore $vectorSearch

• OpCountersCommand

• Database e raccolte di amministrazione

• CursorMaxTimeMS

• explain()

• Costruzioni di indici

• Ricerca con chiave vuota nel percorso

• API, operazioni e tipi di dati MongoDB

• Utilità mongodump e mongorestore

• Ordinamento dei risultati

• Retryable scrive

• Indice Sparse

• Utilizzo di $elemMatch all'interno di un'espressione $all

• Dollaro ($) e punto (.) nei nomi dei campi

• $lookup

• $natural e ordinamento inverso

Operatore $vectorSearch

Amazon DocumentDB non supporta $vectorSearch come operatore indipendente. Supportiamo invece, vectorSearch all'interno dell'$searchoperatore. Per ulteriori informazioni, consulta Ricerca vettoriale per Amazon DocumentDB.

OpCountersCommand

Il OpCountersCommand comportamento di Amazon DocumentDB si discosta da quello di MongoDB come segue: opcounters.command

• MongoDB opcounters.command conta tutti i comandi tranne insert, update ed delete, mentre Amazon DocumentDB esclude anche il comando. OpCountersCommand find

• Amazon DocumentDB conta alcuni comandi interni verso. OpCountersCommand

Database e raccolte di amministrazione

Amazon DocumentDB non supporta rispettivamente il database di amministrazione o locale né MongoDB system.* o startup_log le raccolte.

CursorMaxTimeMS

In Amazon DocumentDB, cursor.maxTimeMS reimposta il contatore per ogni richiesta. getMore Pertanto, se maxTimeMS viene specificato un valore di 3000 MS, la query richiede 2800 MS e ogni getMore richiesta successiva richiede 300 MS, il cursore non scadrà. Il cursore scade solo quando una singola operazione, la query o una singola richiesta, richiede più di quanto specificato. getMore maxTimeMS Inoltre, lo sweeper che controlla il tempo di esecuzione del cursore viene eseguito con una granularità di cinque (5) minuti.

explain()

Amazon DocumentDB emula le API MongoDB 3.6, 4.0, 5.0 e 8.0 su un motore di database appositamente progettato che utilizza un sistema di storage distribuito, tollerante ai guasti e autoriparante. Di conseguenza, i piani di interrogazione e l'output di possono differire tra Amazon DocumentDB e MongoDB. explain() I clienti che desiderano il controllo sul piano di query possono utilizzare l'operatore $hint per applicare la selezione di un indice preferito.

Costruzioni di indici

Amazon DocumentDB consente la creazione di un solo indice su una raccolta alla volta. In primo piano o sullo sfondo. Se operazioni come createIndex() o dropIndex() si verificano nella stessa raccolta quando è in corso una creazione di indice, l'operazione appena tentata avrà esito negativo.

Per impostazione predefinita, le compilazioni degli indici in Amazon DocumentDB e MongoDB versione 4.0 sono in primo piano. MongoDB versione 4.2 e successive ignora l'opzione di creazione dell'indice in background se specificata su createIndexes o sui relativi helper di shell e. createIndex() createIndexes()

Un indice Time to Live (TTL) inizia a far scadere i documenti dopo il completamento della creazione dell'indice.

Ricerca con chiave vuota nel percorso

Quando esegui la ricerca con una chiave che include una stringa vuota come parte del percorso (ad esempio x.x..b) e l'oggetto ha un percorso chiave di stringa vuoto (ad esempio{"x" : [ { "" : 10 }, { "b" : 20 } ]}) all'interno di un array, Amazon DocumentDB restituirà risultati diversi rispetto a quelli ottenuti se eseguissi la stessa ricerca in MongoDB.

In MongoDB, la ricerca di un percorso chiave vuoto all'interno dell'array funziona come previsto quando la chiave di stringa vuota non si trova alla fine della ricerca del percorso. Tuttavia, quando la chiave di stringa vuota si trova alla fine della ricerca del percorso, non esamina l'array.

Tuttavia, in Amazon DocumentDB, viene letto solo il primo elemento all'interno dell'array, perché getArrayIndexFromKeyString converte una stringa vuota in0, quindi la ricerca della chiave di stringa viene considerata come ricerca dell'indice dell'array.

API, operazioni e tipi di dati MongoDB

Amazon DocumentDB è compatibile con le API MongoDB 3.6, 4.0, 5.0 e 8.0. Per l'elenco aggiornato delle funzionalità supportate, vedi API, operazioni e tipi di dati MongoDB supportati in Amazon DocumentDB.

Utilità mongodump e mongorestore

Amazon DocumentDB non supporta un database di amministrazione e pertanto non esegue il dump o il ripristino del database di amministrazione quando si utilizzano le utilità or. mongodump mongorestore Quando si crea un nuovo database in Amazon DocumentDB utilizzandomongorestore, è necessario ricreare i ruoli utente oltre all'operazione di ripristino.

Requisiti di versione di MongoDB Database Tools

Usa MongoDB Database Tools fino alla versione 100.11.0 inclusa per Amazon DocumentDB. Per scaricarlo, consulta le versioni di MongoDB Database Tools sul sito Web di MongoDB.

Ordinamento dei risultati

Amazon DocumentDB non garantisce l'ordinamento implicito dei set di risultati. Per garantire l'ordinamento di un set di risultati, specifica in modo esplicito un ordinamento utilizzando sort().

L'esempio seguente ordina gli elementi della raccolta dell'inventario in ordine decrescente in base al campo del magazzino.

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

Quando si utilizza la fase di $sort aggregazione, l'ordinamento non viene mantenuto a meno che la $sort fase non sia l'ultima fase della pipeline di aggregazione. Quando si utilizza la fase di $sort aggregazione in combinazione con la fase di $group aggregazione, la fase di $sort aggregazione viene applicata solo agli accumulatori e. $first $last In Amazon DocumentDB 4.0, è stato aggiunto il supporto per $push rispettare l'ordinamento della fase precedente. $sort

Retryable scrive

A partire dai driver compatibili con MongoDB 4.2, le scritture riutilizzabili sono abilitate per impostazione predefinita. Tuttavia, Amazon DocumentDB attualmente non supporta le scritture riutilizzabili. La differenza funzionale si manifesterà in un messaggio di errore simile al seguente.

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

Le scritture riutilizzabili possono essere disabilitate tramite la stringa di connessione (ad esempioMongoClient("mongodb://my.mongodb.cluster/db?retryWrites=false")) o l'argomento della parola chiave del MongoClient costruttore (ad esempio). MongoClient("mongodb://my.mongodb.cluster/db", retryWrites=False)

Di seguito è riportato un esempio Python che disabilita le scritture ripetibili nella stringa di connessione.

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) 

Indice Sparse

Per utilizzare un indice Sparse creato in una query, devi utilizzare la clausola $exists nei campi che coprono l'indice. Se ometti$exists, Amazon DocumentDB non utilizzerà l'indice sparse.

Di seguito è riportato un esempio di :

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

Per gli indici sparsi a più chiavi, Amazon DocumentDB non supporta un vincolo di chiave univoco se la ricerca di un documento dà come risultato un set di valori e manca solo un sottoinsieme dei campi indicizzati. Ad esempio, createIndex({"a.b" : 1 }, { unique : true, sparse :true }) non è supportato, dato che l'input di "a" : [ { "b" : 2 }, { "c" : 1 } ], come "a.c" è memorizzato nell'indice.

Utilizzo di $elemMatch all'interno di un'espressione $all

Amazon DocumentDB attualmente non supporta l'uso dell'$elemMatchoperatore all'interno di un'espressione. $all Come soluzione alternativa, è possibile utilizzare l'operatore $and con $elemMatch come segue.

Funzionamento originale:

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

Funzionamento aggiornato:

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

Dollaro ($) e punto (.) nei nomi dei campi

Amazon DocumentDB non supporta l'interrogazione dei campi con prefisso Dollar ($) in $in, $nin e $all negli oggetti annidati. Ad esempio, la seguente query non è valida in Amazon DocumentDB:

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

$lookup

Amazon DocumentDB supporta la capacità di eseguire corrispondenze di uguaglianza (ad esempio, left outer join) e supporta anche sottoquery non correlate, ma non supporta sottoquery correlate.

Utilizzo di un indice con $lookup

È ora possibile utilizzare un indice con l'operatore stage. $lookup In base al caso d'uso, sono disponibili diversi algoritmi di indicizzazione che è possibile utilizzare per ottimizzare le prestazioni. Questa sezione spiegherà i diversi algoritmi di indicizzazione $lookup e ti aiuterà a scegliere quello migliore per il tuo carico di lavoro.

Per impostazione predefinita, Amazon DocumentDB utilizza l'algoritmo hash quando viene utilizzato e sort merge quando allowDiskUse:false viene utilizzato. allowDiskUse:true

Nota

L'allowDiskUseopzione non è attualmente supportata per il comando. find L'opzione è supportata solo come parte dell'aggregazione. Usa il framework di aggregazione con allowDiskUse:true per gestire query di grandi dimensioni che potrebbero superare i limiti di memoria.

In alcuni casi d'uso, potrebbe essere opportuno forzare l'ottimizzatore di query a utilizzare un algoritmo diverso. Di seguito sono riportati i diversi algoritmi di indicizzazione che l'operatore di $lookup aggregazione può utilizzare:

• Ciclo annidato: un piano di ciclo annidato è in genere utile per un carico di lavoro se la raccolta esterna è <1 GB e il campo della raccolta esterna ha un indice. Se viene utilizzato l'algoritmo del ciclo annidato, il piano di spiegazione mostrerà lo stage come. NESTED_LOOP_LOOKUP

• Sort merge: un piano di ordinamento unificato è in genere utile per un carico di lavoro se la raccolta esterna non ha un indice nel campo utilizzato nella ricerca e il set di dati di lavoro non è contenuto nella memoria. Se viene utilizzato l'algoritmo di ordinamento unito, il piano di spiegazione mostrerà la fase come. SORT_LOOKUP

• Hash: un piano hash è in genere utile per un carico di lavoro se la raccolta esterna è < 1 GB e il set di dati di lavoro è contenuto nella memoria. Se viene utilizzato l'algoritmo hash, il piano di spiegazione mostrerà la fase come. HASH_LOOKUP

È possibile identificare l'algoritmo di indicizzazione utilizzato per l'$lookupoperatore utilizzando explain sulla query. Di seguito è riportato un esempio:

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
}
         

In alternativa all'utilizzo del explain() metodo, è possibile utilizzare il profiler per esaminare l'algoritmo utilizzato con l'utilizzo dell'$lookupoperatore. Per ulteriori informazioni sul profiler, vedere. Profilazione delle operazioni di Amazon DocumentDB

Utilizzo di un PlanHint

Se desideri forzare l'ottimizzatore di query a utilizzare un algoritmo di indicizzazione diverso con$lookup, puoi utilizzare un. planHint Per farlo, usa le opzioni del commento nella fase di aggregazione per forzare un piano diverso. Di seguito è riportato un esempio della sintassi del commento:

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

Di seguito è riportato un esempio di utilizzo di planHint per forzare l'ottimizzatore di query a utilizzare l'algoritmo di HASH indicizzazione:

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

Per verificare quale algoritmo è più adatto al carico di lavoro, puoi utilizzare il executionStats parametro del explain metodo per misurare il tempo di esecuzione della $lookup fase modificando al contempo l'algoritmo di indicizzazione (ad esempio,//). HASH SORT NESTED_LOOP

L'esempio seguente mostra come utilizzare l'algoritmo executionStats per misurare il tempo di esecuzione della $lookup fase. SORT

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

$natural e ordinamento inverso

Amazon DocumentDB supporta solo $natural le scansioni dirette delle raccolte. Le scansioni di raccolta inversa ({$natural: -1}) porteranno a un. MongoServerError