Condividi tramite

Ottimizzare il costo delle richieste in Azure Cosmos DB

  • Articolo

SI APPLICA A: NoSQL MongoDB Cassandra Gremlin Tabella

Questo articolo descrive come le richieste di lettura e scrittura si traducono in unità richiesta e come ottimizzare il costo di tali richieste. Le operazioni di lettura includono letture di punti e query. Le operazioni di scrittura includono inserimento, sostituzione, eliminazione e upsert degli elementi.

Azure Cosmos DB offre un ampio set di operazioni di database che agiscono sugli elementi all'interno di un contenitore. Il costo associato a ognuna di queste operazioni dipende da CPU, I/O e memoria necessari per il completamento dell'operazione. Invece di occuparsi della pianificazione e della gestione delle risorse hardware, sarà possibile usare un'Unità richiesta (UR) come singola misura per le risorse necessarie a eseguire le diverse operazioni di database e rispondere a una richiesta.

Misurazione dell'addebito di UR di una richiesta

Per comprendere il costo effettivo e valutare anche l'efficacia delle ottimizzazioni, è importante misurare l'addebito di UR delle richieste. Questo costo è recuperabile usando il portale di Azure o esaminando la risposta inviata da Azure Cosmos DB tramite un SDK. Per istruzioni dettagliate su come ottenere questo risultato, vedere Trovare l'addebito unità richiesta in Azure Cosmos DB.

Lettura dei dati: letture di punti e query

Le operazioni di lettura in Azure Cosmos DB vengono in genere ordinate dalla più veloce/più efficiente alla più lenta/meno efficiente in termini di consumo di UR, come indicato di seguito:

  • Letture di punti (ricerca chiave/valore su un singolo ID elemento e chiave di partizione).
  • Query con una clausola di filtro in una singola chiave di partizione.
  • Query senza una clausola di filtro di uguaglianza o intervallo su qualsiasi proprietà.
  • Query senza filtri.

Ruolo del livello di coerenza

Quando si usano i livelli di coerenza con decadimento sicuro o ristretto, il costo ur di qualsiasi operazione di lettura (lettura punto o query) viene raddoppiata.

Letture di punti

L'unico fattore che influisce sull'addebito di UR di una lettura punto (oltre al livello di coerenza usato) è la dimensione dell'elemento recuperato. La tabella seguente mostra il costo di UR delle letture di punti per gli elementi con dimensioni pari a 1 KB e 100 KB.

Dimensioni elemento Costo di una lettura punto
1 KB 1 UR
100 kB 10 UR

Poiché le letture dei punti (ricerche chiave/valore nell'ID elemento e nella chiave di partizione) sono il tipo di lettura più efficiente, è consigliabile assicurarsi che l'ID elemento abbia un valore significativo, così da poter recuperare gli elementi con una lettura punto (anziché una query) quando possibile.

Nota

Nell'API per NoSQL, le letture dei punti possono essere eseguite solo usando API REST o SDK. Le query che eseguono il filtro su ID e chiave di partizione di un elemento non vengono considerate una lettura punto. Per un esempio di uso di .NET SDK, vedere leggere un elemento in Azure Cosmos DB for NoSQL.

Query

Le unità richiesta per le query dipendono da numerosi fattori. Ad esempio, il numero di elementi di Azure Cosmos DB caricati/restituiti, il numero di ricerche in base all'indice, il tempo di compilazione di query e così via. Azure Cosmos DB assicura che la stessa query, se eseguita sugli stessi dati, consumi sempre lo stesso numero di UR, anche con esecuzioni ripetute. Il profilo di query mediante le metriche di esecuzione di query offre una buona idea di come vengano impiegate le unità richiesta.

In alcuni casi è possibile visualizzare una sequenza di 200 e 429 risposte e unità di richiesta di variabili in un'esecuzione di paging di query, poiché le query verranno eseguite il più velocemente possibile in base alle unità richiesta disponibili. È possibile che l'esecuzione di query venga suddivisa in più pagine/round trip tra client e server. Ad esempio, 10.000 elementi possono essere restituiti come più pagine e addebitati in base al calcolo eseguito per la rispettiva pagina. Quando si esegue la somma tra queste pagine, si otterrà lo stesso numero di unità richiesta dell'intera query.

Metriche per la risoluzione delle query

Le prestazioni e la velocità effettiva usata principalmente dalle query (incluse le funzioni definite dall'utente) dipendono dal corpo della funzione. Il modo più semplice per scoprire quanto tempo viene impiegato dall'esecuzione della query per la UDF e il numero di UR consumate, consiste nell'abilitare le metriche di query. Se si usa .NET SDK, ecco le metriche di query di esempio restituite da SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Procedure consigliate per ottimizzare il costo delle query

Per l'ottimizzazione del costo delle query, prendere in considerazione le procedure consigliate seguenti:

  • Condividere il percorso per più tipi di entità

    Provare a usare la condivisione percorso per più tipi di entità all'interno di un contenitore singolo o di un numero più piccolo di contenitori. Questo metodo offre vantaggi non solo dal punto di vista dei prezzi, ma anche per le transazioni e l'esecuzione di query. Le query sono limitate a un singolo contenitore; le transazioni atomiche su più record mediante stored procedure/trigger sono limitate a una chiave di partizione all'interno di un singolo contenitore. La condivisione percorso per entità all'interno dello stesso contenitore consente di ridurre il numero di round trip di rete per risolvere le relazioni tra i record, aumentando così le prestazioni end-to-end, abilitando transazioni atomiche su più record per un set di dati più grande e, di conseguenza, riducendo i costi. Nel caso in cui la condivisione percorso per più tipi di entità all'interno di un singolo contenitore o di un numero più piccolo di contenitori sia difficile per il proprio scenario, in genere perché si esegue la migrazione di un'applicazione esistente e non si desidera apportare modifiche al codice, è necessario considerare il provisioning della velocità effettiva a livello di database.

  • Misurare e ottimizzare per ottenere un utilizzo minore di unità richiesta al secondo

    La complessità di una query influisce sulla quantità di unità richiesta usate per un'operazione. Il numero di predicati, la natura dei predicati, il numero di funzioni definite dall'utente e le dimensioni del set di dati di origine sono tutti fattori che incidono sul costo delle operazioni di query.

Azure Cosmos DB offre prestazioni prevedibili in termini di latenza e velocità effettiva tramite un modello di velocità effettiva con provisioning. La velocità effettiva di cui è stato effettuato il provisioning viene rappresentata in termini di unità richieste al secondo, o UR/sec. Un'unità richiesta (UR) è un'astrazione logica sulle risorse di calcolo (CPU, memoria, I/O e così via) necessarie per eseguire una richiesta. La velocità effettiva di cui è stato effettuato il provisioning (UR) viene riservata e dedicata al contenitore o al database perché questo possa garantire latenza e velocità effettiva prevedibili. La velocità effettiva di cui è stato effettuato il provisioning consente ad Azure Cosmos DB di offrire prestazioni coerenti e prevedibili, di garantire una bassa latenza e una disponibilità elevata su qualsiasi scala. Le unità richiesta rappresentano la valuta normalizzata che semplifica il calcolo della quantità di risorse necessaria per un'applicazione.

Il costo di una richiesta restituito nell'intestazione della richiesta indica il costo di una determinata query. Ad esempio, se una query restituisce 1000 elementi da 1 KB ciascuno, il costo dell'operazione è 1000. Entro un secondo, il server rispetterà quindi solo due richieste di questo tipo prima di limitare la velocità delle richieste successive. Per altre informazioni, vedere l'articolo Unità richiesta e il calcolatore di unità richiesta.

Scrittura dei dati

Il costo UR di scrittura di un articolo dipende da:

Inserimento di un elemento da 1 KB senza indicizzare i costi circa 5,5 UR. La sostituzione di un articolo costa due volte l'addebito necessario per inserire lo stesso elemento.

Ottimizzazione delle scritture

Il modo migliore per ottimizzare il costo UR delle operazioni di scrittura consiste nel dimensionare correttamente gli elementi e il numero di proprietà indicizzate.

  • L'archiviazione di elementi di grandi dimensioni in Azure Cosmos DB comporta addebiti UR elevati e può essere considerata un anti-pattern. In particolare, non archiviare contenuto binario o grandi blocchi di testo su cui non è necessario eseguire query. Una procedura consigliata consiste nell'inserire questo tipo di dati in Archiviazione BLOB di Azure e archiviare un riferimento (o un collegamento) al BLOB nell'elemento scritto in Azure Cosmos DB.
  • L'ottimizzazione dei criteri di indicizzazione per indicizzare solo le proprietà di filtro dalle query può rappresentare una differenza enorme nelle UR utilizzate dalle operazioni di scrittura. Quando si crea un nuovo contenitore, i criteri di indicizzazione predefiniti indicizzano ogni proprietà presente negli elementi. Anche se si tratta di un'impostazione predefinita ottimale per le attività di sviluppo, è consigliabile rivalutare e personalizzare i criteri di indicizzazione quando si passa alla produzione o quando il carico di lavoro inizia a ricevere traffico significativo.

Quando si esegue l'inserimento bulk dei dati, è inoltre consigliabile usare la libreria dell'esecuzione bulk di Azure Cosmos DB perché è progettata per ottimizzare il consumo di UR di tali operazioni. Facoltativamente, è anche possibile usare Azure Data Factory basato sulla stessa libreria.

Passaggi successivi

È ora possibile passare ad altre informazioni sull'ottimizzazione dei costi in Azure Cosmos DB con gli articoli seguenti: